Does zdbsp generate nodes incorrectly?

[entryway]

I have made test map to check a possibility of some overflows in prboom-plus. The map contains 65536+ sidedefs (which are compressed to 95)

deepbsp version with its extended nodes (xNd4 magic) works perfectly. zdbsp version (XNOD magic) is a full mess.

I tried to build nodes with the latest zdbsp for sunder.wad map11 (it requires extended nodes) and there are no problems with that map in prboom-plus. It's strange, because both maps use the same format of nodes. Sunder works, but test level does not.

I am using zdbsp 1.15 release. Command line is: zdbsp -X test241.wad

[entryway]

Ok, probably something is broken in prboom-plus. I have reduced lines number to make map_vertex_count + zdbsp_additional_vertex_count < 65536 and all is ok now.

[TheDarkArchon]

GZDoom has to rebuild the nodes on ZDBSP built nodes, stating the BSP tree is incomplete, but when it rebuilds, it runs fine.

[entryway]

TheDarkArchon said:

GZDoom has to rebuild the nodes on ZDBSP built nodes, stating the BSP tree is incomplete, but when it rebuilds, it runs fine.

Yes, it even does not try to load them, because of

UsingGLNodes = true;
if (map->MapLumps[ML_ZNODES].Size != 0 && !UsingGLNodes)
{
  idcheck2 = MAKE_ID('X','N','O','D');

Looks like prboom-plus has dependence from number of vertexes, because vertexes count is 65534 map vertexes + 4357 extra vertices by zdbsp > MAX_USHORT. deepbsp does not generate additional vertexes and that's why deepbsp version works fine. Currently I do not know how to fix it.

btw, svn Eternity can't handle test241_zdbsp.wad correctly too.

[Quasar]

entryway said:

Yes, it even does not try to load them, because of

UsingGLNodes = true;
if (map->MapLumps[ML_ZNODES].Size != 0 && !UsingGLNodes)
{
  idcheck2 = MAKE_ID('X','N','O','D');

Looks like prboom-plus has dependence from number of vertexes, because vertexes count is 65534 map vertexes + 4357 extra vertices by zdbsp > MAX_USHORT. deepbsp does not generate additional vertexes and that's why deepbsp version works fine. Currently I do not know how to fix it.

btw, svn Eternity can't handle test241_zdbsp.wad correctly too.

Loverly. Let me know if anything is figured out with respect to this. I'm knee-deep in DECORATE states right now ;)

[Gez]

Map is broken in ZDoom too. The test map is one that ZDBSP has trouble processing apparently.

[entryway]

Gez said:

Map is broken in ZDoom too. The test map is one that ZDBSP has trouble processing apparently.

How did you test? For me it works with zdoom

EDIT: map works fine with zdoom 2.4.1 (because 2.4.1 did not support XNOD?), but does not work with svn build

[TheDarkArchon]

Breaks on ZDoom r2351 but rebuilding the nodes using ZDooms internal nodebuilder (Which ZDBSP is based on) works.

[entryway]

TheDarkArchon said:

Breaks on ZDoom r2351 but rebuilding the nodes using ZDooms internal nodebuilder (Which ZDBSP is based on) works.

r2351?

Revision: 2351
----
Modified : /zdoom/trunk/src/g_shared/sbarinfo.cpp
Modified : /zdoom/trunk/src/g_shared/sbarinfo_commands.cpp
Modified : /zdoom/trunk/wadsrc/static/sbarinfo/doom.txt

[Gez]

entryway said:

EDIT: map works fine with zdoom 2.4.1 (because 2.4.1 did not support XNOD?)

Exactly. The nodes are unrecognized and therefore rebuilt. It works fine when nodes are internally rebuilt, but not when using nodes generated with zdbsp -X.

entryway said:

r2351?

Probably just the oldest revision he had on hand. It's actually r2287.

[Gez]

Fixed in ZDBSP 1.16.

[Quasar]

Any news on whether or not this resolves the issue with Eternity? :)

[entryway]

Quasar said:

Any news on whether or not this resolves the issue with Eternity? :)

It was zdbsp issue, not in my loader of zdbsp nodes. Now all is correct with prboom-plus and Eternity.