r1443 misplaced mid texture

[Enjay]

I just noticed this in my Burghead mod. The sign (on map111) is made from a mid texture. I have narrowed down the official versions where the change occurred.

GZDoom 1.5.2 r916 is OK:

[spoiler][/spoiler]

GZDoom 1.5.3 r990 is not:

[spoiler][/spoiler]

The current ZDoom (r3825) still has it in the right place:

[spoiler][/spoiler]

Without checking, the area probably has some sort of slope-screwyness going on that is confusing things.

[Enjay]

I found myself with a little time to spare so I narrowed things down to which revision caused the break. r943 is fine. r944 is not.

- added a workaround for Icarus's ugly transparent door hacks.
- fixed: lower textures between ceiling sky sectors were not clipped to the ceiling sky as in the software renderer.

[Gez]

That was what I was suspecting too.

Code: Select all

 // very, very, very ugly special case (See Icarus MAP14)
// It is VERY important that this is only done for a floor height difference of 1
// or it will cause glitches elsewhere.
tex = TexMan(seg->sidedef->GetTexture(side_t::mid));
if (tex != NULL && !(seg->linedef->flags & ML_DONTPEGTOP) &&
seg->sidedef->GetTextureYOffset(side_t::mid) > 0)
{
ztop[0]=ztop[1]=32768.0f;
zbottom[0]=zbottom[1]=
FIXED2FLOAT(bs->ceilingplane.ZatPoint(v2) + seg->sidedef->GetTextureYOffset(side_t::mid));
SkyTexture(fs->sky,fs->CeilingSkyBox, true);
return;
}

[Enjay]

Merged quadruple post.

Post 1
I wonder if it would make sense for GZDoom to maintain its own list of WADs that need specific fixes - basically like the compat list that ZDoom has but an extra list for WADs that only need fixes applied in the hardware renderer?

Post 2
Well, I've been trying and failing miserably to try and get an editing solution that manages to make the sign "version proof" (ie looking the same in ZDoom, GZDoom old and GZDoom new). My hope was that I could find something so that regardless of what happened next from the code side, the map would look as intended. I'll not bore anyone with the things that I have tried but there have been a lot.

Anyway, the real point of this post is to provide a test file. This is just the area from the mod cut out, set to be MAP01 and retextured to work without any additional files. I hope it's of use.

signpost.zip

(10.04 KiB) Downloaded 146 times

Post 3
Hah! Using the code that Gez posted to help me feel my way, I finally came up with something that actually seems to look the same in all the renderers. It's not desperately elegant. The sign mid texture has to be in its own sector surrounded by another sector (just putting it in its own sector was not enough). Then of course the sloped floors have to be made to match - done using some slope copy things.

[spoiler][/spoiler]

Of course, it's not a fix - a simple structure like this needs to have a predictable appearance across renderers, but at least I have managed to satisfy my own curiosity.

Post 4
Don't know why I didn't think of the easiest solution first:

[spoiler]Make a model



[/spoiler]

[Graf Zahl]

Is this problem still there? A few months ago I fixed a texture placement bug that was introduced by external code and screwed up a few things.

[Enjay]

Yes, I'm afraid so. The test file still attached to my earlier post still shows the problem. If you load it in ZDoom, the STEPTOP texture acting as the face of the sign sits as intended compared to the height of the signpost. In GZDoom, including a build made today, the STEPTOP sign sits too high.

ZDoom


GZDoom

[Graf Zahl]

Mystery solved. Finally. It's not the SIGN that is wrong but the POST which is too tall! In the software renderer it doesn't get cleanly clipped by the ceiling, and at some point I had to change this to be closer to what the software renderer does. Old versions did not clip this at all, producing glitches with other maps.

So I've been on a wild goose chase the entire afternoon (and on all previous attempts to find this.) Of course I couldn't find anything wrong with the sign's placement because it's correct in both renderers...

This is a clear case of some bad mapping which takes a glitch in the software renderer into account that can't be properly handled in the hardware renderer.
The software renderer glitches when a lower wall extends into the sky - but it does it in a very strange and erratic way - your sign is a clear border case. Had you made the post any higher than it was and it would have shown some HOM. The actual sky ceiling is where the later GZDoom version cut the post off.

You got to fix it in the map so that you do not rely on such things. I prefer not to change the current code which comes closer to what the software renderer does than the old code.

[Enjay]

I apologize for sending you on a wild goose chase.

To be fair, I had no idea that a mapping error was responsible - otherwise I wouldn't have made the map like that. With the post being in the middle of a sloped area, where things were set in the editor versus where they actually ended up when the slopes were drawn in game was not always obvious. So I guess I accidentally created the mapping error and didn't notice it.

However, this map was always made for the hardware renderer. It wasn't made to look right in software and then transferred to OpenGL; it was always a GZDoom map. That's where my initial confusion came in. When the map was first made, it looked as I wanted it to in GZDoom and looked correct in the version of GZDoom that was current at the time of release. When the appearance of the sign changed in a newer version of GZDoom (but still looked OK in ZDoom as a reference) I assumed that the change to GZDoom was where the break had happened rather than the map having always been broken. I was wrong.

Thanks for looking into it and I'm glad that you got to the bottom of it. I have actually fixed things in my own copy of the map and I intend releasing a fix eventually once a few other things are sorted out.