Sign in to follow this  
Followers 0

URGENT: what are the limits

Urgent question: what are the maximum limits of the Eternity engine for the number of vertices, linedefs, sidedefs, sectors, etc etc ?

Share this post


Link to post

Last time I checked, Quasar had not changed anything about the original limits, which are all at 32768 except for the blockmap which is at 65536.

Share this post


Link to post

those are limits of the .wad-format btw. that's why they're still there.

Share this post


Link to post
schepe said:

those are limits of the .wad-format btw. that's why they're still there.

No, they're limits of Doom's internal level format. WADs can be used as containers for any map formats.

Share this post


Link to post

strictly speaking, yes. but for simplicity i would say that the format of the LINES lump is a part of the .wad format.

Share this post


Link to post

all structures in wads are limited to 65536 in amount by the stock format (unless you can have negative lindefs etc or something), 32k is an engine limit

it wouldn't be overly hard to expand the format slightly so that the numbers of structures within other structures were stored in 3 or 4 bytes instead of just 2 (4 would probably be better) and make the engine (and map editors) read from it, as far as I know zdoom can already do that in memory (I know it can build more segs than the wad limit allows)

Share this post


Link to post

no, since the format is define such that some things should be a signed word, and not an unsigned, it's a limitation of the format.

Share this post


Link to post

well that makes sense as to why the limits are all 32k, but at the same time it doesn't make any sense to store the amount of something (lines, sidedefs, verts etc) in a signed number

Share this post


Link to post
schepe said:

no, since the format is define such that some things should be a signed word, and not an unsigned, it's a limitation of the format.



That's utter nonsense because these values cannot be negative anyway (except the sidedef index -1 but that special case can be easily take care of.) The fields are 2 bytes and there is absolutely nothing except the dumb definition of these values as 'signed' in the code that keeps the engine from reading larger numbers correctly. Storing them is no problem whatsoever. Without changing anything about the format it is shockingly easy to expand the size of most of these structures (excluding subsectors and nodes) to 65535 (which should be more than enough for the time being - after all it doubles the potential level size!) All that has to be done is change a few short definitions to unsigned short (or int for internal structures) in the source and you are done!

Share this post


Link to post
Graf Zahl said:

That's utter nonsense because these values cannot be negative anyway (except the sidedef index -1 but that special case can be easily take care of.) The fields are 2 bytes and there is absolutely nothing except the dumb definition of these values as 'signed' in the code that keeps the engine from reading larger numbers correctly. Storing them is no problem whatsoever. Without changing anything about the format it is shockingly easy to expand the size of most of these structures (excluding subsectors and nodes) to 65535 (which should be more than enough for the time being - after all it doubles the potential level size!) All that has to be done is change a few short definitions to unsigned short (or int for internal structures) in the source and you are done!


I know.

Share this post


Link to post

Ok, seems I just hit the SEGS upper limit :( Also, are you sure about the blockmap limit? I seem to remember I bumped that one up to 114K without problem... I'll have to check at home for the exact numbers.

I really REALLY hate restrictions and/or limits :(

Share this post


Link to post
Mordeth said:

Also, are you sure about the blockmap limit? I seem to remember I bumped that one up to 114K without problem... I'll have to check at home for the exact numbers.

I really REALLY hate restrictions and/or limits :(


Eternity is able to rebuild the blockmap if it gets too large (more than 128k) so that shouldn't be a problem at all.

Share this post


Link to post

Ok, I'm now pretty sure it was the SEGS limit. The sidedef count was also dangerously close to 32K as well. Anyway, guess I'm forced to split that level up.

Share this post


Link to post

I would have to find (or preferably be given) information on what editors are available that can support this. There's not much use to removing the limits if to use it, you need a half-done editor and are restricted to a single node builder.

Share this post


Link to post

DeepSea and DoomBuilder both support large maps (thus far), but even more than that, two of the biggest projects using the engine would make good use of it :) There's a few Millennium levels I suppose I could split and rework, but it would be nice to keep them intact. Or, I could just release them for ZDoom :P * watches Quasar frantically add large map support

Share this post


Link to post
Lüt said:

Or, I could just release them for ZDoom :P

Good idea.

Share this post


Link to post

Lüt said:
DeepSea and DoomBuilder both support large maps (thus far), but even more than that, two of the biggest projects using the engine would make good use of it :) There's a few Millennium levels I suppose I could split and rework, but it would be nice to keep them intact. Or, I could just release them for ZDoom :P * watches Quasar frantically add large map support


YAY!

Share this post


Link to post

That's a pretty limited choice of editors. Do none of the external node builders support it? I grimace to think of people being forced to use internal ones which are USUALLY vastly inferior (maybe this has changed recently, but it was once a golden rule).

I will consider it. It definitely will not be in the beta 4 release, as I still have a pageful of EDF features to implement, not to mention ExtraData and Small, which have been on the backburner for so long that they're starting to smell burned.

Also, keep in mind that Eternity has latent capability for seamless travel between maps, which was part of the SMMU hub system. Once Small scripting is more fleshed out, this capability should re-emerge, and possibly in a more flexible manner (I don't see why it should be limited to hub exits, for instance). This might would cover *some* instances where large maps would be used (like taking a long one-way tunnel across to another large portion).

Share this post


Link to post

I'm pretty sure deepbsp supports large map nodes, and zdbsp (the external version of zdoom's internal builder) does as well. I doubt zennode, warm, bsp etc do though since those haven't really been updated since large maps have been made possible

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0