Welcome to the ZDoom Forums!

That's a few sectors over, though. :?

Try 255x255? :P

It's a generated map. It's nothing but a bunch of square sectors. They represent the cells of a randomly generated dungeon. The stats I showed above is for a 256x256 dungeon.

Holy pancakes, Nash! :shock:

See if you can merge a lot of those sectors with identical ones. For sectors in the same room/area it won't make a lot of difference to noise alerts. (THis is something I've made a habit of, though not from fear of limit-hitting. :P )

There's probably some 16 bit limitation in there, most likely for the sectors as that value is just above the 16 bit limit.

Hey, sorry to bump this, but...

[quote]
Vertices: 66057
Linedefs: 131592
Sidedefs: 263176
Sectors: 65538
Things: 8

Maximum Line ID assigned: 131584
[/quote]

... is this just too much for ZDoom/ZDBSP? I tried it with the latest ZDoom/GZDoom (no nodes built in an editor; I let the game generate it on the fly) and the game crashes.

Yay! Thanks. :D

Range checking added.

grep --text '^x = ' lol.wad | sort -gk3 | tail

Looking at the frames with gdb shows that the X values of some vertices is near the magic value of +/- 2^31, which seems very suspect.
[spoiler][code]
zdbsp: nodebuild.h:124: int FNodeBuilder::FVertexMap::GetBlock(fixed_t, fixed_t): Assertion `y <= MaxY' failed.
Aborted
Program received signal SIGABRT, Aborted.
0x00007ffff712c4e5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff712c4e5 in raise () from /lib64/libc.so.6
#1 0x00007ffff712d9b0 in abort () from /lib64/libc.so.6
#2 0x00007ffff712524a in __assert_fail () from /lib64/libc.so.6
#3 0x000000000040ed33 in FNodeBuilder::FVertexMap::GetBlock (this=0x7f5af0,
x=-6, y=2147483642) at nodebuild.h:124
#4 0x000000000040eaf5 in FNodeBuilder::FVertexMap::InsertVertex (
this=0x7f5af0, vert=...) at nodebuild_utility.cpp:539
#5 0x000000000040e8c2 in FNodeBuilder::FVertexMap::SelectVertexExact (
this=0x7f5af0, vert=...) at nodebuild_utility.cpp:491
#6 0x000000000040d0dc in FNodeBuilder::FindUsedVertices (this=0xbe68550,
oldverts=0x7ffff7f25010, max=66057) at nodebuild_utility.cpp:69
#7 0x0000000000404997 in FNodeBuilder::FNodeBuilder (this=0xbe68550,
level=..., polyspots=..., anchors=..., name=0x628828 "MAP01",
makeGLnodes=true, sselevel=2 '\002') at nodebuild.cpp:49
#8 0x0000000000411ff7 in FProcessor::Write (this=0x7fffffffdda0, out=...)
at processor.cpp:594
#9 0x000000000040243a in main (argc=2, argv=0x7fffffffe0d8) at main.cpp:236
(gdb) up
#1 0x00007ffff712d9b0 in abort () from /lib64/libc.so.6
(gdb)
#2 0x00007ffff712524a in __assert_fail () from /lib64/libc.so.6
(gdb)
#3 0x000000000040ed33 in FNodeBuilder::FVertexMap::GetBlock (this=0x7f5af0,
x=-6, y=2147483642) at nodebuild.h:124
124 assert (y <= MaxY);
(gdb) p y
$1 = 2147483642
(gdb) p MaxY
$2 = 50331647
(gdb) up
#4 0x000000000040eaf5 in FNodeBuilder::FVertexMap::InsertVertex (
this=0x7f5af0, vert=...) at nodebuild_utility.cpp:539
539 };
(gdb) p vert
$3 = (FNodeBuilder::FPrivVert &) @0x7fffffffdc10: {x = 0, y = -2147483648,
segs = 4294967295, segs2 = 4294967295, index = 65793}
[/code][/spoiler]
By running [code]grep --text '^x = ' lol.wad | sort -gk3 | tail[/code], I notice that a little over 250 vertices have an x value >= 32768. Unless I am mistaken, fixed_t that is used for calculations can still only represent values from -32768(-frac) .. 32767(+frac). Similarly for the y coordinate, where 250+ have y <= -32768 (specifically since -32768 should be ok: two vertices are -32896).
[attachment=0]the-extension-diff-is-not-allowed.txt[/attachment]
This patch may also be needed for the zdoom and zdacc code.
Nash: My suggested workaround is, since the domain of x for your vertices is just {-512..32896} and y={-32896..512} that you simply move all vertices (the entire map basically) to the left and upwards a bit.

Old thread but:

This is not a new feature. Either it's a bug in ZDBSP or a limitation that can't be overcome. Either way, moved to 'bugs'.

I got a crash but no 'out of memory'. Still need to do a debugger run with this map.

Possible in UDMF. You are not limited by the map format anymore. There remain the memory limit, as discovered by Nash, and the port itself still has a limit of course but you can reach the billion without problem so...

There's more than 65535 sectors and lines...

So what's the verdict? Have I hit the limits? Is this WAD something that's never meant to happen, ever?

[img]http://forums.multiplay.co.uk/images/smilies/emot-ms.gif[/img]

C:\test>zdbsp -o lol1.wad -x -z -w -b -r lol.wad
----MAP01----
Out of memory

This is what I get with it:

[code]C:\test>zdbsp -o lol1.wad -x -z -w -b -r lol.wad
----MAP01----
Out of memory[/code]

Now I'm not sure what memory it is using or expects, but I have 12GB of RAM in my system.