Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
mikenet2007

Is there a sector wall or sprite limit for doom builder

Recommended Posts

I have an area thats big with many sectors, and my map will have other areas I plan on making so if there is a limit of any kind regarding how many walls, sectors, or sprites you can have in a map it would be good to know about before I get carried away, thanks. Also is there a limit to how much can be displayed on screen at once?

Share this post


Link to post

Doombuilder (and most modern editors) as a program surely has some internal limits, but it's unlikely you will even hit them, as they are probably in the 32-bit integer range, so unless you need more than 2 billion sprites/linedefs/sectors you're probably OK. Oh or until RAM runs out :-)

The vanilla DOOM engine itself is another matter though: you could read the unofficial doom specs for that, but in general try keeping less than 100 sectors and 100 (double sided) linedefs visible at any time. Visible Sprites > 128 just don't get drawn, but won't generally break the vanilla engine if there is enough RAM.

Exceeding visible sectors will case a visplane_overflow error which is fatal and crashes vanilla doom. Exceeding SSEGS (too many visible linedefs) will cause HOM and slime, but won't crash. It's very hard to predict how many sectors/linedefs will be visible from each possible players perspective at every possible game resolution, and no editor has a "per position" limit check.

You can only run it, and tone down the detail if it seems to break the engine, or if you don't want to compromise, keep the detail and recommend a "limit removing port" for your map (A.K.A. Boom compatible)

Share this post


Link to post

As of now my map consist of 1210 verticies, 332 sectors, and 133 things, with an open area similar in size to Downtown, lev13, in Doom2. However it looks nothing like Downtown, the area in my map is wide open with few obstructions, so the editor is going to be calculating a lot here because the area will be full of bad guys. So far so good though, I hope I can pull it off. The map is roughly 20% complete and my understanding of Doom Builder is improving although there are still problems I'm running into here and there.
I like the undo feature in this program as well as the flexibility of selecting multiple walls and sectors for editing.

Share this post


Link to post

I did a quick test and DoomBuilder crashed after 64k sidedefs. Looks like you don't have to worry about reaching that limit any time soon.

Share this post


Link to post
chopkinsca said:

I did a quick test and DoomBuilder crashed after 64k sidedefs.


Thats it?!?!

Does Slade have this same limitation?

EDIT: Its not an editor limitation, the map format literally cannot handle more than 64 sidedefs.

Share this post


Link to post
Dr. Zin said:

EDIT: Its not an editor limitation, the map format literally cannot handle more than 64 sidedefs.



If sidedef compression was used you could use a lot more.
I did some tests with a few very large maps and even the most detailed ones could be shrunk down to less than 70%. So if an editor was able to natively support this you could create maps with 80000-90000 sidedefs, provided you have an engine that is capable of handling such large maps properly.

Share this post


Link to post
Dr. Zin said:

EDIT: Its not an editor limitation, the map format literally cannot handle more than 64 sidedefs.


@Graf Zahl:
I think we had that some times ago........ we need a new map format :)

Share this post


Link to post

We need an editor developer willing to implement a new map format.
The sad thing is, without support from DoomBuilder as the currently most popular one this is a dead issue and I haven't even heard one hint from CodeImp.

Defining a new map format is easy, supporting it in a source port is also - but as long as everyone is still forced to use editors that can't handle it it's going nowhere.

Share this post


Link to post

I might as well bugger a friend of mine, he has an original VB6.
Or if i can find a cheap VB6 on eBay i do it myself :)

EDIT: w00t? All around 100 to 150 Euro? Are these people nuts?

Share this post


Link to post
Graf Zahl said:

If sidedef compression was used you could use a lot more.
I did some tests with a few very large maps and even the most detailed ones could be shrunk down to less than 70%. So if an editor was able to natively support this you could create maps with 80000-90000 sidedefs, provided you have an engine that is capable of handling such large maps properly.

Problem is that segs is often the 32k/64k limit to be hit before sidedefs, and packing sides does nothing to reduce segs :\

Share this post


Link to post
Lüt said:

Problem is that segs is often the 32k/64k limit to be hit before sidedefs, and packing sides does nothing to reduce segs :\



ZDoom/ZDBSP have solved thid with its compressed node format. It's the other ports' problem if they don't want to implement it.

Share this post


Link to post

Is there a published spec available for Zdoom's compressed node format? Please tell me there is sane way of determining if the nodes are compressed. Is it compression or packing (like sidedefs)?

I didn't even know the format existed.

Share this post


Link to post
DaniJ said:

Is there a published spec available for Zdoom's compressed node format? Please tell me there is sane way of determining if the nodes are compressed. Is it compression or packing (like sidedefs)?

I didn't even know the format existed.



If you want it I can write it. It's easy enough to understand just from reading ZDoom's code.
There are 2 formats: regular compressed nodes or compressed GL nodes. Regular nodes are stored in the NODES lump, GL Nodes in the SSECTORS lump so they can coexist.
The format is marked by a special signature in the first 4 bytes of the NODES/SSECTORS lump (either ZNOD or ZGLN) and the chance of valid valid node/subsector data being misinterpreted as the signature is practically zero because no sane map could have such values there.
Compressed in this case really means compressed with ZLIB.

Share this post


Link to post

A specification would be preferable as I'm sure others might want to implement support (or at the very least check for existence) of these new formats.

I'm not going to commit to supporting them in Doomsday just yet though.

Share this post


Link to post
DaniJ said:

A specification would be preferable as I'm sure others might want to implement support (or at the very least check for existence) of these new formats.

You can look at glBSP source which can write the compressed ZNOD format. Search for "ZDBSP" in level.c.

JDoom uses GL nodes and the V5 format removes all the limits, so I recommend you simply implemented read support for V5 GL nodes (if you haven't already done so).

Share this post


Link to post

Is is possible at this point in time to write to this ZNOD format? Is this only glBSP that does this, or can rgular BSP too? If it is only glBSP, can the nodes be used by regular ZDoom?

Sorry for all the questions.

Share this post


Link to post

JDoom uses GL nodes and the V5 format removes all the limits, so I recommend you simply implemented read support for V5 GL nodes (if you haven't already done so).

So the (offical, standard) V5 GL node format has obsoleted ZDBSP's (proprietary) compressed node format. Ah, that changes things somewhat. Thanks for the heads up.

In that case, I'm now unsure whether I will implement support for ZDBSP's compressed format since we've already implemented V1, V2, V3 and V5 support in Doomsday for 1.9.0

However, now that supporting all the map data lump formats is so trivial to do in Doomsday I might just implement support for these anyway.

Share this post


Link to post

Ok so number of walls, sectors, and things in zdoom has no limit that can be practically reached "64k sidedefs." I'm supposing thats 64 thousand sidedefs, stupid question, duh. lol

My Duke3d map currently has about 18,000 sidedefs and I'm estimating a total of 25,000 when all is finished. That is pushing it IMO for any map, and Ive never found it necessary to have that many walls until I started my most recent Duke3d map, so 64,000 sidedefs could make an episode of normal sized maps.

A couple questions though, What about size and shape of sectors? Can a sector be to large, or too narrow? "narrow like hairline cracks around an explosion hole"?

Also just to confirm what was said earlier, the original Doom engine has a limit to how many sectors or walls can be on screen at once, but ports like boom and zdoom help eliminate this problem by allowing more walls and sectors the engine can tolerate at once. Correct?? Here I'm talking strictly what can be on screen at once, not what can be in the map total.

Share this post


Link to post
DaniJ said:

So the (offical, standard) V5 GL node format has obsoleted ZDBSP's (proprietary) compressed node format.

I'm not sure one can say that. I presume ZDoom and derivatives will stick to using the ZDBSP compressed formats, whereas GL-Node using ports are better off using the official/standard V5 GL nodes, as adding support for it is fairly easy, mostly a matter of cut-paste-modify of the V2-reading code.

The reason glBSP creates the ZNOD compressed (normal) nodes is because otherwise the normal nodes would be invalid (the limits have overflowed), and something valid is better than something invalid.

Share this post


Link to post
mikenet2007 said:

Also just to confirm what was said earlier, the original Doom engine has a limit to how many sectors or walls can be on screen at once, but ports like boom and zdoom help eliminate this problem by allowing more walls and sectors the engine can tolerate at once. Correct?? Here I'm talking strictly what can be on screen at once, not what can be in the map total.


Yeah, that's the main issue with vanilla doom. Many older otherwise correctly constructed maps that had non-eliminable HOM or visplane overflow errors, would, by modern standards, be classified as "requiring a limit removing port".

About minimum maximum sector sizes....in theory the minimum distance between vertexes should be 1 pixel, but some editors won't let you edit at such a small scale. Linedefs, when curved, may have smaller distances yet. Anyway, there's a thread about "the most detailed PWAD ever" if you want to take a look at the discussions that took place there.

Share this post


Link to post
mikenet2007 said:

Ok so number of walls, sectors, and things in zdoom has no limit that can be practically reached "64k sidedefs." I'm supposing thats 64 thousand sidedefs, stupid question, duh. lol

My Duke3d map currently has about 18,000 sidedefs and I'm estimating a total of 25,000 when all is finished. That is pushing it IMO for any map, and Ive never found it necessary to have that many walls until I started my most recent Duke3d map, so 64,000 sidedefs could make an episode of normal sized maps.


With 25000 sidedefs you should be way on the safe side. This can be handled by any port in existence. BTW, the biggest map I have seen so far contains more than 62000 sidedefs. ;)

A couple questions though, What about size and shape of sectors? Can a sector be to large, or too narrow? "narrow like hairline cracks around an explosion hole"?


Theoretically the only limit is imposed by the map format which only uses integer coordinates for vertices. However, if your geometry gets too small the standard node format will no longer be able to handle it due to precision problems. The node builder has to split linedefs and insert new vertices but id also used integer coordinates here causing serious precision issues. When the geometry gets too small this can cause major visual glitches and I have seen maps that got completely broken by this. The only thing that might prevent this is to use a node format that is capable of having vertices with fixed point precision. That means, either ZDoom's compressed nodes or GL nodes - but this will of course limit your map to specific ports. When mapping for Vanilla/Boom it is always recommended not to use non-orthogonal geometry on anything smaller than an 8x8 grid. That alone will reduce the danger of rendering glitches a lot.

Also just to confirm what was said earlier, the original Doom engine has a limit to how many sectors or walls can be on screen at once, but ports like boom and zdoom help eliminate this problem by allowing more walls and sectors the engine can tolerate at once. Correct?? Here I'm talking strictly what can be on screen at once, not what can be in the map total.


Correct. Most modern source ports remove all the existing mapping limits that aren't a direct result of the map format.

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
×