Geometry limits of vanilla Doom map format

[Bauul]

As I was building a very large map recently in vanilla Doom, I kept bumping into the various limits of the map format, and being a newbie took some time to work out what the actual limit was, and how to address each one.

While the information is out there, I couldn't find it all in one place, so in the name of helping other people in the future, here's a compilation of what I learned are the typical limits you're going to reach as you expand the geometry of a map, and what's required to successfully compile and run a map of that size.

1. Up to 32,768 SEGS: Any modern Node Builder to compile, and any source port to run (notwithstanding other limits like Visplanes). Note: you don't know the number of SEGS a map has until you've compiled it.
   
   
2. 32,768 to 65,536 SEGS: Any modern Node Builder to compile, but requires limit-removing source port to run, so excludes the really hardcore vanilla ports like Chocolate
   
   
3. 65,537 or more SEGS, but 65,536 or fewer Sidedefs: Requires Node Builder that supports extended nodes to compile, i.e. ZDBSP or DeepBSP. Source port compatible with those Node Builders required to run (must be also limit-removing, but AFAIK all are).
   
   
4. 65,536 Sidedefs + a varying amount (depends on map), but 65,536 or fewer Linedefs: If you use GZDoom Builder, upon saving it automatically implements Sidedef compression to try to keep the final number under 65,536 (the Sidedef count in GZDB turns red to indicate you've past the limit). The effectiveness of the compression depends on the variety of Sidedefs in the map, but in my (limited) experience it's pretty effective - up to a 50% reduction in the number of Sidedefs. AFAIK the only way to check exactly how effective is to open the WAD in something like Slade after the compression and look how many Sidedefs there are - the final figure must be under 65,536. Same requirements as above needed to compile and run. This is absolutely pushing the limits of BSP.
   
   
5. 65,537 or more Linedefs, or 65,537 or more Sidedefs even after compression: Vanilla Doom format no longer works. The only option is to use the UDMF map format instead, and the node builders and source ports that support it. If you've already started building in vanilla map format, check out this thread on how to convert it to UDMF. Generally though, if you know you're creating a map this big, it's better to start with UDMF, as it effectively removes all limits on everything. The downside is the relatively fewer list of compatible source ports.
   

Note, these are not the only limits: things like Tags, Things, moving Sectors etc. also all have limits that you may hit before the above ones, but the ones listed are the typical pure geometry related ones.

I'm sure most regulars here know all this stuff already (and indeed if I have any of this wrong, please let me know so I can correct it!). I'm more putting this here because it's the kind of thread I was I had been able to find when searching around for this information, and I hope someone down the line who is also struggling with this discovers it and finds it useful.

[Gez]

https://doomwiki.org/wiki/Static_limits

Also keep in mind that the dimensions of the map can cause problems, too. Distance between two points is measured in signed units, so you should avoid getting into situations where the distance between two points could be more than 32767. Since coordinates can be negative, you could have a distance greater than that -- for example between a point at [-32000, 0] and another at [+32000, 0], the distance is 64000, which will overflow to a distance of -1536, which is absurd.

[Quineotio]

Thank you so much Bauul :) Even though this and other information is already out there, it's good to have it in multiple places and multiple forms because sometimes things can be hard to find.

I've been working on a big map and have been concerned about these limits, so it's great to have them here as a reminder :)

[BigDickBzzrak]

BTW, what's the tag limit in vanilla? My map is around 90 right now, is that anything to be concerned about?
Anyway, thanks for the helpful post, even though I'll never need it (I've never made an area with >128 visplanes, heh)

[scifista42]

Tag numbers can go up to 65535, limited only by the map format (where they're stored as 16-bit values), not any static limit of the engine (though the engine stores them as 16-bit values too).

EDIT: Since vanilla engine stores tags as signed values, I'm not sure whether tags in range 32768 to 65535, interpreted as -32768 to -1, would work correctly.

[Empyre]

Aren't tags in vanilla stored as unsigned 8-bits? That would make the maximum 255.

[esselfortium]

Nope, scifista is correct.

Hexen-format args go from 0-255 though.

[scifista42]

Empyre said:

That would make the maximum 255.

It's a known fact that there are tags 666 and 667. How could they exist if 255 was maximum?

[ryg]

On ‎06‎/‎10‎/‎2016 at 3:52 PM, bzzrak said:

BTW, what's the tag limit in vanilla? My map is around 90 right now, is that anything to be concerned about?
Anyway, thanks for the helpful post, even though I'll never need it (I've never made an area with >128 visplanes, heh)

Don't worry, I am close to 1000 tags without a problem.

[ryg]

On ‎05‎/‎10‎/‎2016 at 11:10 PM, Gez said:

https://doomwiki.org/wiki/Static_limits

Also keep in mind that the dimensions of the map can cause problems, too. Distance between two points is measured in signed units, so you should avoid getting into situations where the distance between two points could be more than 32767. Since coordinates can be negative, you could have a distance greater than that -- for example between a point at [-32000, 0] and another at [+32000, 0], the distance is 64000, which will overflow to a distance of -1536, which is absurd.

Thank you for pointing this out. My map is well within these limits. Max. distance between any two vertices is around 12000. Max x or y is around 8700 (absolute).

Edited December 14, 2017 by ryg