Boom 242-height error

[simc]

(edited 2020/10/21)

Happens with the latest devbuild gzdoom-x64-g4.5pre-308-g63035d503, fresh install without cfg, different computers (Win 8.1/10 x64), vulkan, opengl and softpoly.

It appears to happen between (not every version tested)
GZDoom 4.4.2 (latest) - 0.9.12 (atleast)
ZDoom 2.8.1 - 1.2.3 beta 33 (Feb 2002)

But it doesn't happen with the previous existing ZDoom 1.2.3 beta 28a (Sept 2001) or before.

If there's a Boom linetype 242 height setup and at some point the fake height control sector's floor height is the same or higher than the next sector's ceiling heigth in between the player and the fake height sector the rendering of all fake height systems at sight might "go wrong". This doesn't happen in PrBoom+.

screenshots from:
gzdoom-x64-g4.5pre-308-g63035d503: https://i.imgur.com/Gh1eX9z.jpg
ZDoom 2.1.0: https://i.imgur.com/tHQuIMY.jpg
PrBoom 2.5.1.7um: https://i.imgur.com/6ZmfTjL.jpg

The BRICK11 wall is the side texture of a 242-floor. After the ASHWALL3 textured ceiling blocks has been lowered, the BRICK11 texture disappears and the real sector CRACKLE2 walls come visible. The sides of the 242-pool on the right turn black as it's rendering of flips upsidedown.

The test level below has three switches and two fake floor setups.

The 1st switch from the left will lower the ceiling to couple units below the fake floor in a sector behind. Both fake height systems go wrong. SW renderes view HOM.

The 2nd switch will set one half of the ceiling to match the fake floor in a sector behind. The other half goes little bit above the fake floor. This looks better but the room still has places where both fake height systems go wrong.

The 3rd switch will reset the ceiling as it was at the start.

The result seems to somehow depend of the room detals too. With some lines moved around the rendering error might ease.

[dash1]

I had very similar issue. Reinstalling helped.

[wildweasel]

With ZDoom 2.8.1? You should check using a recent build of Gzdoom; that version of ZDoom is several years out of date.

[drfrag]

gzdoom-x64-g4.5pre-297-g473072d55

[simc]

With ZDoom 2.8.1? You should check using a recent build of Gzdoom; that version of ZDoom is several years out of date.

Should have been more clear. I tried to tell that it happens on "all" GZDoom versions including the fresh devbuild and also on ZDooms which run a different softtware renderer.

Thanks for the replies.

[Graf Zahl]

The problem with this setup is that you run into a classic case of undefined behavior. If you use type 242 you must make sure that at no point you can ever look into the middle part of one 242 sector but a lower part of another one. The area you are in is a global per-scene setting. The main difference between ZDoom-based engines and PrBoom is how they determine this. PrBoom sets this flag right on scene start (thus always forcing the middle area when not in a 242 sector) while ZDoom and related ports only set it when first encountering a 242 sector in a scene. This change was done for some ROR effects that were quite popular in early ZDoom maps - some good examples of this can be found in Doom Resurrection and The Darkest Hour.

You should also not use this type to create fake walls the player can walk through. Since 242 physically alters the sector when rendering it this can result in ugly visibility clipping artifacts and they are very obvious in the demo map.