[4.6.1] action 242 problems & draw distance HOMS

[Krull]

I've been working on this map for a boom project and didn't get round to testing it in GZDoom until today. It features some large, non-solid map geometry made possible via the transfer sector height action, but GZD ignores it for these features (not for other areas of the map, mind you - there are plenty of places where 242 works just fine). This only happens with hardware rendering (it doesn't matter which renderer I choose). Weirdly, it did manage to render the objects from afar as I noclipped towards the area.

Screenshot_Doom_20210821_154247.jpeg

This is what it's supposed to look like, as displayed in the software renderer, but that leads me to the next problem...

Screenshot_Doom_20210821_202157.jpeg

In software mode, pillars at the back display the water floor texture from the rooms above as a ceiling in place of the green 'windows' seen in the foreground. Worse, the background further behind the pillars has turned into a giant HOM.

Here is a link to the map so you can test it for yourself.

I've tried it in 4.5 and the latest build and got the same result in both. This could be a settings issue rather than an actual bug but I'm not well versed in that side of things.

[Graf Zahl]

Can you please post the sector numbers where the problems happen?

[Krull]

OK.

Pillar windows:

189, 1050, 1092, 1121, 1149, 1162, 2297, 1205, 1230, 2352, 1260, 2389, 1288, 2428, 1302, 1330, 2460, 2497, 1373, 2525, 2557, 2588, 1398, 1428, 2615, 1454, 2505, 1482, 2396, 1510, 2628, 1538, 1566, 2326, 2679

Giant fireblu things:

1826-1830

[Graf Zahl]

This map uses 242 in a way that clashes with an effect that got added in early ZDooms and requires a slight change in how 242 works to display correctly in the hardware renderer.
For obvious reasons that effect cannot be disabled because several old ZDoom map sets from the early 2000's depend on it.

The only way to address this would be through a compatibility option.

[Krull]

Oh dear, what about the bugs seen in software mode?

[Graf Zahl]

No idea, but I wouldn't be surprised if it's somehow related to the same thing.

[Krull]

No idea, but I wouldn't be surprised if it's somehow related to the same thing.

Yeah, on closer inspection the HOMs in software mode seem to kick in at roughly the same distance that hardware mode starts actually rendering 242 actions correctly, so there's probably some relation. Either way, do you have any advice on how to fix this? As hardware rendering seems to be the most stable, are there ZDoom-specific map actions that would offer a workaround in that mode?

[Graf Zahl]

On your side, no. The only way to address this is to add a compatibility option in the engine. This is simply a use case that was never considered when doing the implementation

[Krull]

Fair enough, do you mind explaining in a bit more detail what you think went wrong here so people can avoid the problem?

[Graf Zahl]

Sure.
ZDoom in its early days implemented a way to use 242 for a simple ROR effect. Normally when viewing from a non-242 sector the function that processes 242 sectors will pick the middle part.
This effect checks the actual vertical span of the sector you can view into and may also pick the upper or lower parts instead - and that's what happens here in a scenario it wasn't supposed to.

As long as you use this type to create deep water or invisible platforms all is fine, the problems will start if you can see the outer walls of these sectors. This code cannot deal with that situation because it was never considered.