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 ?

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.

you can have unlimited things though :P

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

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.

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

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)

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.

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

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!

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.

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 :(

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.

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.

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.

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

Lüt said:

Or, I could just release them for ZDoom :P

Good idea.

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!

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).

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