Questions about the "32768 SEG-limit"

1. What does the 32768 Seglimit means? Is it the maximal numbers of vertexes+linedefs+sectors+things? Or something else?

2. What source ports are contain this limit? I'm looking for ports WITHOUT limit removing.

1. The SEGS static limit here. And from this page - "BSP divides the level up into a binary tree: each location in the tree is a node which represents a particular area of the level (with the root node representing the entire level). At each branch of the tree there is a dividing line which splits the area of the node into two subnodes. At the same time, the dividing line divides linedefs into line segments called segs. "

Someone else may want to elaborate a bit more, but I think SEGS are just essentially the parts of a line that are split up by the nodebuilder. In Vanilla only 256 segs can be in view at one time. If you go over that, you'll get a HOM at whatever is attempting to be rendered the farthest away from the player's view. The limit your asking about, though, has to do with the SEGS lump size. If you open your map up in XWE/SLADE and take a look at it's SEGS lump, the number of bytes the lump takes up is what you want to watch. In my experience, you'll reach the SEGS limit before hitting a sidedef, linedef, etc limit.

2. I may be wrong here, but I believe any port that advertises itself as "limit removing" really just doubles the SEGS limit (so it would be 65535). I ran into this issue not that long ago with a Boom compatible map I was making. Certain ports recently obtained support for ZDoom's node format, which did away with the SEGS limit. Those ports, that I'm aware of, are PrBoom+, Eternity, and of course ZDoom.

Wow, that's more difficult than I expected.

Thank you, Mechadon!

Historically, "limit-removing" ports have not extended the segs limit past 32768, and wads such as Deus Vult II that require it to be doubled to 65535 have at times been said to require a "strong limit-removing" port.

It's now possible in some ports to use ZDBSP's extended nodes format, by using the -X parameter with a recent enough version of ZDBSP; in addition to allowing for higher precision to limit the possibility of slime trails, it effectively removes the segs limit. ZDoom (and its related ports), PrBoom-Plus, and Eternity all support this. With the segs limit removed, when mapping in one of the standard binary map formats (i.e. not UDMF), you are still limited to 65535 sidedefs, but with the automatic compression of any identical sidedefs, done by Doom Builder 2 when a map exceeds this limit, it's actually possible to exceed it by a pretty significant amount. The actual amount depends on how many identical sidedefs your map has to be compressed.