maximum single level size

How big can a single wad for doom be,before you run into errors.
That is i you build them for a source port like zdoom or legacy.
My wad is now about 2megs in size,so i want to know how much further i can expand my wad.

dutch devill said:

How big can a single wad for doom be,before you run into errors.
That is i you build them for a source port like zdoom or legacy.
My wad is now about 2megs in size,so i want to know how much further i can expand my wad.

For most source ports the first limit to be reached is 32767 segs. The problem with this one is that it heavily depends on the node builder's work and can't be expressed in something that can be easily checked in an editor.
Some source ports increase he limit to 65535 segs which is the largest size that can be handled without changing the map format. With this you can already build huge maps (the 2 biggest ones I know of are the ZDoom Community map and Map02 of RTC-3057.) If you use an enhanced node format you can go above that. ZDoom doesn't have a seg limit and the first absolute limit to be reached in a map will always be 65534 sidedefs.

Another limit you have to look for is the area the map uses. Doom allows coordinates from -32768 to 32767 but if the map spans an ara larger than 32767 units on one axis you may get internal overflow errors which result in odd behavior.

If you are at 2 MB right now you will most likely still be below the 32767 segs limit. To check the amount of segs you have to look at the node builder's output which should report the amount of segs it created.

Graf Zahl said:

For most source ports the first limit to be reached is 32767 segs. The problem with this one is that it heavily depends on the node builder's work and can't be expressed in something that can be easily checked in an editor.

Various node builders don't differ all that much. Currently there are only 2 ports that allow one to exceed the 32k limit, RISEN3D and ZDOOM (and derived ZDOOMGL). There is a seg limit though but for all practical purposes it's unlimited in that it can never be reached.

the first absolute limit to be reached in a map will always be 65534 sidedefs.

With sidedef packing that's not the case. The linedefs or vertices instead become the absolute limit at 65536.

The PWAD size he gave is not indicative of much though since he didn't say if that included a BLOCKMAP and a REJECT. Probably does so that needs to be subtracted.

If he has regular nodes right now, he can check the node specs either in DeePsea F10 - statistics or some command line programs that do the same thing.

Graf Zahl said:

If you are at 2 MB right now you will most likely still be below the 32767 segs limit. To check the amount of segs you have to look at the node builder's output which should report the amount of segs it created.

My community chest 2 map was under 2 MB and passed the seg limit. That was including the music file and the few textures I had.

As far as file size goes, there is no limit on size. It depends on other things that have been mentioned already.

deep said:
Various node builders don't differ all that much.

If you are near the limit even 'not that much' can become critical. For example, I have generally observed that ZDBSP creates up to 5% more segs than Zennode.

With sidedef packing that's not the case. The linedefs or vertices instead become the absolute limit at 65536.

If the editor can handle it, of course. I have never tested it.

I once made a map taht was quite big and I found out that Legacy's max limit in a map is 30k sidedefs.

Graf Zahl said:

If you are near the limit even 'not that much' can become critical. For example, I have generally observed that ZDBSP creates up to 5% more segs than Zennode.

Of course, that's obvious to anyone. But in general, if you are that close the number of segs is likely to turn into a problem no matter what node builder is used. You can also change the various tuning factors and influence the size also.

So "not that much" isn't the issue, the problem is that if a level is close to the limit, then one has to consider ports that support extended nodes or stop adding things:)

If the editor can handle it, of course. I have never tested it.

I have. Both DeePsea and DB can edit levels that size packed (tricky to do) or unpacked (has to be repacked to save). It's one of my test levels that blows up ZDOOM.

Here is some info of my wad in progress.
-4623 vertices
-5504 linedefs
-8582 sidedefs
-962 sectors

The reason why it is 2mb in size is because i use many new textures.
Reading your replys about my thread tells me i haven't got to the maximum size yet,which is good because i have got more ideas to put into my level.
Its not finished yet its gonna be a lot bigger,i think it will be ready about mid januari (i hope it will get finished some day).

dutch devill said:

Here is some info of my wad in progress.
-4623 vertices
-5504 linedefs
-8582 sidedefs
-962 sectors

Go getum .. you have lotsa room left. It's when you get over 20,000 linedefs where you start worrying. The actual number depends on the number of angled lines.

Thanks for the info guys.
But i have got a few other questions that are bugging me.

I have downloaded a lot of textures from different sites and used them in my wad,will i be doing something against the rules if i upload this wad to 3dgamers.

And i have downloaded a wadfile with most of the psx doom sfx will be doing something illigal if i upload this together with my level.

I hope not because then i would be pretty pissed of,and probably never release the damm thing at all.

Thanks in advance

dutch devill said:

I have downloaded a lot of textures from different sites and used them in my wad,will i be doing something against the rules if i upload this wad to 3dgamers.

Yes and No.

Yes since technically you have to get permission from the owner or the site said you could use them.

No because this is done all the time and nobody cares much so long as it's not-for-profit.

And i have downloaded a wadfile with most of the psx doom sfx will be doing something illigal if i upload this together with my level.

Same answer. The problem here is interesting since lots of wad files have illegal graphics taken from HEXEN (and many other games) and yet they are uploaded/downloaded with no peeps from anyone. Yet the very same site(s) that host these PWADs may tell you it's not acceptable if it's something not in that hazy "everybody does it" category. Legally makes absolutely no sense.

So the one thing you can count on in this topic is complete inconsistency :)

Ill take my chance and upload it when it is done,if it gets rejected i will know it soon enough.
I am already pretty far with my wad,and i dont want to remove all the textures and sounds thats gonna take more of my precious time.
And i dont have a lot of spare time sadly :(

But my wad lacks a good name anyone have some good ideas,i was thinking about this name "what lies beneath titan-426" is this a cool one :) or a crappy one :(

I know my reply is 13 years down to road but contrary to what I have seen in various forum postings and websites in am currently working on a huge level which currently has the following statistics:

Vertices: 52620

Linedefs 61454

Sidedefs 111554

Sectors 4414

Things 2131

The level is based on PrBoom and DOOM 1, editing is done in Doom Builder 2.

Nodebuilding for saving map: DeepBSP - Normal

Nodeduilding for testing BSP - W32 -Normal

Everything runs smoothly, although I get a warning from BD 2 when opening the map for editing: "Failed to complete operation: maximum number of vertices reached." The map is nevertheless opened and ready for editing. I have not found any missing vertices yet.

At some point in the development of my map I had gone into some very intrinsic detail that had caused my level to reach:  

Vertices: 52611

Linedefs 65259

Sidedefs 119661

Sectors 4435

Things 2104

and the map would not run with PrBoom. Instead the original Doom 1 map would be run.

So the practical limit is somewhere between these two statistics.

So, deep was correct when he wrote that:

"The linedefs or vertices instead become the absolute limit at 65536."

I can't get the Node Viewer to work at this map size because it always crashes, so I can't tell you what nuber of segments my map got to.

Just start a new thread next time, lol. 

• Are you using prBoom or prBoom+? I know most people just use prB to refer to prB+ but obviously can't hurt to ask.
• Would use extended nodes at that map size (build with ZDBSP stuff), unless you really need it to be compatible with weaker limit-removing ports. You are using nodebuilders suited more for maps that don't push those size limits.

I am using prBoom +.

I don't mind switching to another nodebuilder but what I use now works so I tend to be cautious. I would be happy to hear recommendations. I have three ZDBSP options in BD2. Which one should I use?

The amount of segs have to do with the architecture on your map, diagonal lines do not inherently cause more splits. Splits on diagonal lines are however more problematic, since they might lead to slime trails. It's generally easier to avoid splits IF you have no diagonal lines OR all lines are diagonal and only heading along two directions, being offset 90" to eachother. Basically a non-diagonal map rotated.

ZokumBSP has code to reduce visplane causing subsectors OR segs. The user can optionally tweak which parameter to go for. If the map is close to the SEGS limit, using that metric could help you reduce the SEGS count. The latest tweaks aren't out as a beta or rc, but source is available at GitHub. For more info contact me on irc and read the docs and info at http://doom2.net/zokum/zokumbsp/

There are also more subtle practical limits like the blockmap limit: if your map extends more than 256 blocks (1 block =128 units) in either direction, many regular collision and navigation mechanisms will crap out, unless the port fixes that by using a blockmap extension to 512x512. Another limit is that if the blockmap's size ON DISK exceeds 128 KBs, it will also crap out and will not be read reliably. This can be fixed by a port that automatically generates the blockmap internally. In practice, you want both fixes to the present at the same time.

Here's an old post I made on the subject,

1 hour ago, Maes said:

There are also more subtle practical limits like the blockmap limit: if your map extends more than 256 blocks (1 block =128 units) in either direction, many regular collision and navigation mechanisms will crap out, unless the port fixes that by using a blockmap extension to 512x512. Another limit is that if the blockmap's size ON DISK exceeds 128 KBs, it will also crap out and will not be read reliably. This can be fixed by a port that automatically generates the blockmap internally. In practice, you want both fixes to the present at the same time.

 

Here's an old post I made on the subject,

I got to clarify some errors here. The 256 block width problem isn't as far as I know related to the blockmap. It is caused by the data types not handling values bigger than 128*256, 32768, something that was mentioned earlier. The blockmap on disk limit is roughly 64kib. It can be bigger, but no "offset" kan point to data over this limit. The first element in the list has to be within that 64kib range.

Ports that generate blockmaps internally can screw up special effects and will ruin demo compatibility in many cases. ZokumBSP has code to produce more efficient blockmaps than ZenNode due to fixing errors and using various optimization techniques. Further compression can also be done by removing non-collidable lines, skipping the 0-header and by manually excluding lines from the blockmap from the map editor by using special linedef types. This allows one to in many cases greatly decrease the blockmap size and speed up the game.

A clever mapper could easily hand-edit a map to reduce the blockmap by using tricks such as removing the linedef of door backsides if the door has a stay open type and is only approachable from one side etc (exit doors etc). Many decorative elements also have lines one cannot collide with. A good example here would be some of the sides of the bars on the Doom 2 map06 elevator. It's very unlikely that you can collide with those facing the wall. If I had to choose between the wad crashing the game and not colliding with those lines, I know what I would choose. Johnsen also pointed out to me that a lot of maps have details in the ceiling but not the floor, to avoid affecting gameplay. Such lines can in many cases also be removed from the blockmap.

All these hand microoptimizations and trickeries are mentioned further down in the thread I linked to. It goes pretty deep, almost esoterically so :-)

The 64/128 KB limit is somewhat of a confusion caused by Boom extending it by using unsigned pointers into the blockmap, but even with that extension it's very easy to render useless. Just having a blockmap of size 256x256 means that you can't store anything in it but pointers to...well, nothing, and with the vanilla limit of 64 KB it'd be even worse.

On 11/28/2017 at 6:32 AM, ryg said:

Everything runs smoothly, although I get a warning from BD 2 when opening the map for editing: "Failed to complete operation: maximum number of vertices reached." The map is nevertheless opened and ready for editing. I have not found any missing vertices yet.

One of the subtleties of the Doom engine is that when you build the nodes on a map, it tends to add a significant number of "extra" vertices that you didn't place yourself but which are necessary for the BSP tree to function properly. It is possible that these extra vertices are bumping the total from 56K to 65K.

1 hour ago, Maes said:

All these hand microoptimizations and trickeries are mentioned further down in the thread I linked to. It goes pretty deep, almost esoterically so :-)

 

The 64/128 KB limit is somewhat of a confusion caused by Boom extending it by using unsigned pointers into the blockmap, but even with that extension it's very easy to render useless. Just having a blockmap of size 256x256 means that you can't store anything in it but pointers to...well, nothing, and with the vanilla limit of 64 KB it'd be even worse.

I am well aware of the thread. My point is that the optimizations are all theoretical while ZokumBSP does some of those things, and stuff not mentioned in that thread.

I would have to look at the source, this is pure speculation, but it would be an awesome hack to allow for much larger maps.

If we have a map that covers say 64*64 blocks, could we then define the blockmap to be 256*320? Put the actual play are at the upper right corner of this area, from blocks X: 192-256 and Y: 256-320 and shove all the lookup lists in the first ~65k bytes (minus header etc). This could lead to crashes / problems IF there are objects outside the normal play area. Actual numbers will vary, but we can use these as a rough estimate. Care would have to be taken to handle all the wraparounds of 16 bit data.

If this works, a maps could easily be much bigger, since it would mean that only the linedef lists have to be kept within the ~65k limit. There would have to be some tweaking of coordinates, translating them to a different location to fit all of this, but a blockmap rebuilder could in theory do all that automatically.

This would of course mean that some of the lookup pointers are "garbage" since they're really list data. As long as there is a FF end marker at the end of the blockmap, we'd hopefully have a worst case of slow lookups when travelling outside the 'playable map area'.

There's also the idea of interleaving the data in such a way that the lookup offsets also happen to be valid lists, putting end markers outside the normal play area or relying on a header that is valid to parse. This would mean the blockmap builder would rearrange the linedefs numbers etc. You'd start by putting as much data inside the lookup lists as possible, and only fall back to putting lists in the list area when there's no good positions left in the offset area.

@ryg  I made a simple guide on the limits a while ago (original thread here) in case this helps at all.

Generally speaking, if you're just looking at the geometric limits (i.e. the number of sectors, linedefs etc.) and not the physical size of the map, then the limits you're most likely to hit (and what you need to solve them) are:

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.

On 28.12.2004 at 9:04 PM, Dutch Doomer said:

Ill take my chance and upload it when it is done [...]

i was thinking about this name "what lies beneath titan-426"

Yeah, do that. Its non-profit, so it should be fine even though technically against some guidelines. Try and include what credits you can to the authors in your text-file, even if only listing the site where you found them (if still available). I kept a list of where I got my resources when making Echelon, and felt better in the end about it. I had similar concerns as you along the way though, as i couldn't name every author, such as when the source (Too Much Brown, to be exact) didn't keep a detailed list of its contributors and only had defunct contact info.

About the name choice, I think it is cool but a bit long. Consider shortening it to something like "Beneath Titan", "What lies Beneath" or "Beneath 426", as it is likely to get known under such a moniker after release anyway, if you keep the long name.

I'm sure it'll be a cool level anyway, looking forward to seeing you releasing it! =)

Guys, what are the Vanilla limits for floor/ceiling heights?

The absolute limit for coordinates is -32768 to +32767.

The practical limit, beyond which you start to get misbehaviour from the engine, is -16384 to +16383.

So I am assuming that there isn't a limit on file size itself?  My megawad is 37 mbs, and will probably be closer to 60 when I am finally done.  36 levels total.

Oh well.

1 hour ago, grommile said:

The absolute limit for coordinates is -32768 to +32767.

The practical limit, beyond which you start to get misbehaviour from the engine, is -16384 to +16383.

This applies to all 3 axes.

On 12/12/2017 at 2:49 PM, zokum said:

I would have to look at the source, this is pure speculation, but it would be an awesome hack to allow for much larger maps...

I can't picture what you're describing, but it sounds interesting. Are you thinking that this could be read by vanilla Doom? Or, "vanilla" Boom (without source port modification)?

22 minutes ago, Empyre said:

This applies to all 3 axes.

Doom's BSP represents a 2D (2 axes, only) area. Z axis (height/depth) axis checks are done dynamically at runtime. Which is a shame, cause a 3D blockmap would be a first step towards efficient 3D floors and portals. Instead, we have to contend with overdraw, and expensive runtime Z calculations which could otherwise be baked into level data by the map editor. It'd probably also make GL rendering a lot easier to set up.

I knew that the Z axis is different. When I saw:

10 hours ago, mgr_inz_rafal said:

Guys, what are the Vanilla limits for floor/ceiling heights?

followed by:

9 hours ago, grommile said:

The absolute limit for coordinates is -32768 to +32767.

The practical limit, beyond which you start to get misbehaviour from the engine, is -16384 to +16383.

, it looked like he was stating about the Z axis something I already knew about the X and Y axes, which would mean that it applies to all 3 axes.