Mordeth Posted September 23, 2003 Urgent question: what are the maximum limits of the Eternity engine for the number of vertices, linedefs, sidedefs, sectors, etc etc ? 0 Share this post Link to post
Fredrik Posted September 23, 2003 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. 0 Share this post Link to post
Anders Posted September 23, 2003 those are limits of the .wad-format btw. that's why they're still there. 0 Share this post Link to post
Fredrik Posted September 23, 2003 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. 0 Share this post Link to post
Anders Posted September 23, 2003 strictly speaking, yes. but for simplicity i would say that the format of the LINES lump is a part of the .wad format. 0 Share this post Link to post
Cyb Posted September 23, 2003 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) 0 Share this post Link to post
Anders Posted September 23, 2003 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. 0 Share this post Link to post
Cyb Posted September 23, 2003 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 0 Share this post Link to post
Graf Zahl Posted September 23, 2003 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! 0 Share this post Link to post
Anders Posted September 23, 2003 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. 0 Share this post Link to post
Mordeth Posted September 24, 2003 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 :( 0 Share this post Link to post
Graf Zahl Posted September 24, 2003 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. 0 Share this post Link to post
Mordeth Posted September 25, 2003 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. 0 Share this post Link to post
Quasar Posted October 4, 2003 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. 0 Share this post Link to post
Lüt Posted October 5, 2003 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 0 Share this post Link to post
DooMBoy Posted October 5, 2003 Lüt said:Or, I could just release them for ZDoom :P Good idea. 0 Share this post Link to post
Mordeth Posted October 5, 2003 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! 0 Share this post Link to post
Quasar Posted October 7, 2003 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). 0 Share this post Link to post
Cyb Posted October 7, 2003 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 0 Share this post Link to post