Menu
▾
▴
1 Attachments
#657 More rendering problems
Split from #655, not a big-endian problem and likely unrelated.
WAD-File used for testing (Version from 2019-01-26):
http://www.mediafire.com/file/cn840vel0bkdr9s/Avactor.wad/file
$ openssl dgst -sha256 -hex Avactor.wad
SHA256(Avactor.wad)= 0e978e8deaee5c38b0f7dbe4209c3f8796fb538df78f38efbea33b4485d1628c
$ doomlegacy -iwad doom2.wad -file Avactor.wad -warp 9
SVN revision 1473 can load Map9, but it looks like in the Screenshot attached.
Wesley Johnson wrote in #655:
Please verify that this is not new behavior as a result of the patches for this bug report.
Check the wad with an older version of Doom Legacy.
Those vertex are too large for a 16 bit signed number. It looks like they are being read unsigned.
Tests with Doom Legacy:
- Version 1.47.2: Cannot load map
| Correct blockmap offset[11213...] overflow by adding 0x10000
| Error: Bad blockmap offset[11217]= 40.
- SVN revision 1448: Same behaviour as release 1.47.2
- SVN revision 1466: Same behaviour as SVN revision 1473
Looks like no recent change is responsible for this problem (at least not the patches for #655).
Test with PrBoom+:
- Version 2.5.1.4: Works as expected
| $ prboom-plus -iwad doom2.wad -file Avactor.wad -warp 9
Only starting area tested, not the whole level.
All tests are run on a NetBSD/AMD64 (64-Bit/Little-Endian) machine.
Applicable note from Bug 655:
Not every wad is bug free. There are some buggy wads. These are usually created when tool limits were exceeded, such as too big a blockmap for zennode, or too big a blockmap for the blockmap format. Sometimes they are bad data that had no effect on the development port. Some level map editors leave garbage around. When linedefs and sectors are deleted, some editors leave the unused vertex.
Sometimes we can create a way to read the wad anyway, but not always.
The Vertex warnings in Doom Legacy are there to detect bad wads, so that Doom Legacy does not get blamed. Need to verify that this wad is accepted by some other port, and how well it is accepted. It is possible that the author distributed the wad even though it has problems, and only Doom Legacy is detecting why it has problems.
Not many ports have buggy wad detection.
Addendum:
PrBoom plus:
Has the same buggy vertex detect as DoomLegacy. They put the error message later, after the sidedef test "to avoid overflow if the wrong vertexe's indexes are in the SEGS lump, see note below".
Their vertex error message is printed out using a "LO_WARN" level setting, so you may have to enable low warnings to see it.
PrBoom has added a fix where it goes back to the linedef to get vertex indexes.
They reference "e1m9 @ NIVELES.WAD".
This looks to be a buggy wad.
Deciding to add a buggy wad fix like PrBoom, and how to adapt it to Doom Leacy, may take some time, so it probably will not make the 1.48 release,
Thanks for investigation.
I agree that before a release the focus should be on fixing bugs in DL.
Potential workarounds for buggy wad files should be considered after the release.
Last edit: Michael Bäuerle 2019-10-11
Applicable note from Bug 655:
Not every wad is bug free. There are some buggy wads. These are usually created when tool limits were exceeded, such as too big a blockmap for zennode, or too big a blockmap for the blockmap format. Sometimes they are bad data that had no effect on the development port. Some level map editors leave garbage around. When linedefs and sectors are deleted, some editors leave the unused vertex.
Sometimes we can create a way to read the wad anyway, but not always.
The Vertex warnings in Doom Legacy are there to detect bad wads, so that Doom Legacy does not get blamed. Need to verify that this wad is accepted by some other port, and how well it is accepted. It is possible that the author distributed the wad even though it has problems, and only Doom Legacy is detecting why it has problems.
Not many ports have buggy wad detection.
Addendum:
PrBoom plus:
Has the same buggy vertex detect as DoomLegacy. They put the error message later, after the sidedef test "to avoid overflow if the wrong vertexe's indexes are in the SEGS lump, see note below".
Their vertex error message is printed out using a "LO_WARN" level setting, so you may have to enable low warnings to see it.
PrBoom has added a fix where it goes back to the linedef to get vertex indexes.
They reference "e1m9 @ NIVELES.WAD".
This looks to be a buggy wad.
Deciding to add a buggy wad fix like PrBoom, and how to adapt it to Doom Leacy, may take some time, so it probably will not make the 1.48 release.
I have noticed other problems, like animated sprites where they replaced only the first frame of the sprite, so it keeps changing between doom2 sprites, and the Avactor sprite.
Map11 won't draw the background, so HOM everywhere, probably load related.
I just got curious and downloaded this PWAD in order to do some tests on a PC with Ubuntu 18.04 64-bits.
Firstly, I've tested Doom Legacy from SVN revision 1473, running in software mode. Map01 seems to work fine, but Map09 gave me the same errors Michael Bäuerle had previously reported on a screenshot. If running on opengl mode, it gives me a segmentation fault.
Secondly, I tested this wad on two similar sourceports: ZDoom (v2.8.1) and Zandronum (3.0), both running in software mode. On those, Map09 worked fine.
Last but not least, Avactor.wad is a new pwad, created last year, that has 12 maps of jungles/temples style with huge areas and lot's of details. Although it seems to run on PRBoom, it seems to be one of those newer wads that were focused on Zdoom-like sourceports and its various new gameplay improvements. Depending on how it uses those new gameplay features, there's the possibility that this wad become incompatible with more vanilla-like sourceports, such as PRBoom and DL.
The author wrote:
|
| Testet with: PRBoom and Zdoom, also been played with GZDoom couple of times.
That reads like compatibility with the Boom-compatible group of sourceports is intended.
The first few Avactor maps work with DL and they look really nice.
I can live with minor errors like the wrong sprites. The monster behaviour errors are more annoying (like the "longhorn" pinky demons that don't move), but only the
missing walls are real show stoppers.
This WAD has won a Cacoward, maybe this justifies special workarounds for it.
But Wesley do the work and it's OK if he says that other things have higher priority
(or that it's not the job of DL to workaround buggy WADs at all).
Tests with ZDoom or its derivatives are not very useful. Ports that have some compatibility with Doom Legacy are Eternity Engine, PrBoom, PrBoom+, and other ports of that era.
ZDoom has been noted for taking features from other ports, and modifiying them slightly, making wads written using ZDoom incompatible with the port that orignally developed the feature.
They got 3d floors from Doom Legacy, but I do not trust that it is a compatible implementation.
The reason for the problem is the node format:
Avactor.wad Map9 use extended nodes (DeePBSP V4 format),
but DooM Legacy does not support this node format.
See feature request #95 for proposed solution.
This bug can be closed after #95 is accepted (fixed) or rejected (wontfix).
Deferred, too many more pressing problems right now.
Added extended nodes (DeePSea extended nodes).
Added blockmap generator.
Fixed dehacked reading to be compatible with Avactor.wad.
Please retest.
Avactor Map09 renders now, but I notice these strange holes in the ceiling.
One is boat shaped.
Are those supposed to be there ??
Tested Avactor Map 9 with the software renderer: Looks good.
I have not noticed holes in the ceiling. But the map is large, at which locations you see them?
Using OpenGL.
Avactor map9, player start, look up at ceiling.
The OpenGL is actually rendering exactly what they put into the sector heights.
Some of the linedefs around the ships, and some of the hills, are missing the 2nd sidedef. This seems to be a trick that works with software render, but not with the hardware render.
I tried to look at it using PrBoom, but it crashed immediately on that map.
The handling of missing sidedefs seems to be the same as what PrBoom does, which is to default them to the 0 sidedef.
Tested Map 9 again with SVN 1598 and hardware renderer:
Yes, I can see the holes too.
Tested with an old (SDL1 based) PrBoom+:
Similar behaviour. No holes with software renderer.
Holes present with hardware renderer (see attached screenshot).
No crashes on my test machine (NetBSD/amd64).
Avactor.wad has a few problems.
Eureka editor found a number of lines crossing, and several missing the 2nd sidedef.
There were a few lines with types unknown to Eureka.
Two of the bridges on map04 have the rungs disappear when the player approaches.
A linedef raises the floor under the bridge, and that causes the bridge rungs to fail to display.
Strange that other bridges of this type work fine.
No time for more testing yet.
Maybe I can play again some Avactor levels with SVN 1598 at the weekend.
Played again all maps of Avactor with the software renderer and noticed no more rendering errors.
I think this bug can be closed now.
The original issues of this bug report have been fixed.
Any additional issues with Avactor.wad will have to issue a new, more specific bug report.