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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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).

Share this post


Link to post
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.

Share this post


Link to post

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

Share this post


Link to post
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 :)

Share this post


Link to post

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 :(

Share this post


Link to post

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.

 

 

Share this post


Link to post

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.

 

 

Edited by rdwpa

Share this post


Link to post

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?

Share this post


Link to post

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/

Share this post


Link to post

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,

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post
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.

 

 

Share this post


Link to post
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.

Share this post


Link to post

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.

Share this post


Link to post

@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 LinedefsIf 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.
2 people like this

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