#95 Support for extended nodes

[Michael Bäuerle]

The attached implementation is based on woof 1.2.0 from Fabian Greffrath.
I have modified the data types and macros to match DooM Legacy,
fixed the endianess for big endian machines and added some DooM Legacy
checks from the import of regular nodes.

The support for compressed ZDoom extended nodes requires zlib.
I have disabled this code via #ifdef HAVE_ZLIB for now.

I prefer this implementation, compared to the one of prboom+, because all
the code for extended nodes is in a separate file.

Adding this fixes bug #657 (the reason are DeepBSP V4 extended nodes).
The following segfault crash is fixed too (Eviternity.wad Map15 and Map32
use uncompressed ZDoom extended nodes):

---

$ uname
Linux
$ uname -m
ppc
$ doomlegacy -iwad doom2.wad -file Eviternity.wad -warp 32
[...]
RequestFullGraphics...
VID_SetMode(fullscreen,1)
HU_Init: Setting up heads up display.
VID_SetMode(fullscreen,1)
Correct blockmap offset[4498...] overflow by adding 0x10000
Warn: Bad subsector data
Warn: Bad segs data
Segmentation fault

---

Things that are still open If this approach will be accepted in general:
- zlib based DEFLATE decompression code not tested yet
- Only tested with the software renderer yet

[Michael Bäuerle]

Header file and patches to hook in the new code.

[Wesley Johnson]

I am not familiar with these extended nodes, and do not know what they will give to DoomLegacy.
If they have something to do with ZDoom compatibility, you should know that in general we do not adopt ZDoom features.
Right now, we just released 1.48.1, and bug fixes on that will be the concern for near future.
I do not know when I will even be able to review this.
I should fix segmentation faults though, even when given an incompatible wad.

[Michael Bäuerle]

Extended nodes are used to remove limits:
http://www.sbsoftware.com/files/DeePBSPV4specs.txt
https://zdoom.org/wiki/Node#ZDoom_extended_nodes

I would see the support for both types not as better "ZDoom compatibility" but as better general compatibility with modern WADs. Most of the other maintained source ports have support for extended nodes (Crispy Doom, PrBoom+, Woof and ZDoom).
Many WADs labeled as "Limit removing" or "Boom compatible" (not directly targeted to ZDoom) contains maps with extended nodes today.

At least the DeePBSP V4 nodes seem to have no relationsip to ZDoom. Consider to merge support only for this type (if ZDoom nodes are not acceptable).

If you choose to reject extended node support completely, maybe at least the detection code,
that prints the type to the console, may be useful to indicate to the user that the node format is not supported (and to abort before crashing).

[Michael Bäuerle]

I have now tested the code for compressed ZDoom extended nodes guarded with HAVE_ZLIB.
Z_Realloc() was missing and I replaced it with an ugly hack in the attched file. The memory management should be rewritten to use either Z_Malloc() or malloc(), not both.

It now works with:
CFLAGS+=-DHAVE_ZLIB
LDFLAGS+=-lz

[Wesley Johnson]

Z_Malloc is used where the extra functionality is used to clear the owner ptr when the memory is reclaimed, or to clear all the allocation at the end of a level map.

Plain malloc is used where Z_Malloc capability would serve no purpose.

I mark the owner of the memory as to whether it is malloc or Z_Malloc allocated.

What level maps that use DeepBSP extended nodes would be playable?
Is there anything else that they require that DoomLegacy would not have?

What level maps use ZDoom extended nodes, and do not have something else that is ZDoom that would mess up playing them anyway?
How many maps, and are they especially good maps?
Most likely won't be useful until I can port the Hexen stuff from Legacy 2.0, because anything ZDoom seems to be Hexen dependent.

[Michael Bäuerle]

Maps with DeePBSP V4 extended nodes:
- Avactor Map 9
- Avactor Map 10

Maps with uncompressed ZDoom extended nodes (they are used more often):
- Lost Civilization Map 4
- Lost Civilization Map 19
- Lost Civilization Map 20
- Remnant Map 1
- Man on the Moon Map 1
- NOVA II Map 32
- NOVA III all maps
The maps themselves are not ZDoom-specific, only the nodes use the ZDoom format.

Some maps need #96 too, because the blockmaps are not imported correctly or
missing (NOVA III).

Are the maps listed above good?
Some of the WADs have won a Cacoward, this should be enough to answer the question.

[Wesley Johnson]

Commited svn 1583, 1584, 1585.
Sorry to take so long to get to it. The modifications for DoomLegacy were mostly well done.
It did take some time to work my way through it.

I did mangle the code a bit.
- I try to have graceful recovery instead of I_Error, so the user can save game if nothing else.
- Some additional warning messages.
- BSP search got modified, so BSP children are not allowed to be negative.
- Support for ZLIB involves dynamic loading using dlopen, so we can distribute binaries that will run even when optional libraries are not present.

I have tested it playing parts of Avactor.

ZLIB support is LInux only. We need some Windows programmer to add ZLIB and dynamic library support for the Windows port.

[Michael Bäuerle]

Thank you for merging FR95!

Test with Lost Civilization Map 4 and software renderer looks good.
It still doesn't work with the hardware renderer (but has never worked for me).

And there are blockmap problems. If you are entering the building in the attached screenshot on the left side, you can walk through the left wall on the second screenshot
(and the wall straight forward beyond the opening to the right).
The building shown is located to the north of the map. Eureka displays the coordinates -8256/11584 for the position in the second screenshot.
FR96 solves this problem. Either the blockmap in the WAD is broken or there is a bug in the import code.

[Wesley Johnson]

The extended nodes seem to be working, so will close this FR.
Recent patches have fixed dehacked loading for Avactor, which was badly mangling everything that dehacked was changing. The Avactor dehacked is not entirely conformant to the standard we used before. I had to extend the dehacked code to read it properly. Also had to look at PrBoom to decide on a proper test for exiting sections, as the Avator dehacked tripped on that too.