The sky...

[Rachael]

I used the palette strips for comparison rather than the BGRA strips, for better consistency and accuracy, it seems like you got that much right.

I think you just miscalculated how high those strips really are supposed to be. It should be 500 pixels from end-to-end, that's top (where you look up) to bottom (where you look down). Somewhere close to 250 or so (though not exactly) is where the sky abruptly terminates at the bottom and becomes the "top" instead (for the in-floor sky view, which if I recall is never used in Hexen anyway so you'll have to make a map to test it).

[Graf Zahl]

The sky positioning is a bit tricky and uses different formulas based on texture height. Have a look at GZDoom's RenderDome function to see the different ways to do it. Obviously you will have to test that with a few differently sized skies. The most common sizes are 128, 200, 240 and 256 but I have also seen 220 and 224, 384 and 512 in some rare occasions, 512 being one sky filling the screen from top to bottom.

[dpJudas]

My version uses the alpha channel of the bgra texture, which seems to be 0 whenever the value is 0 in the pal version. When I saw your version I figured there was a good chance of this being the case. After seeing them mix in Hexen I concluded everything is alright, but apparently that 500 buffer size affects the texture scaling somehow. The new code doesn't use any buffers at all and just looks the value up directly from the textures.

@Graf: yeah tbh I'm quite annoyed about the fact that texture coordinate calculations are totally fubar in Doom. And since all maps rely on it now there's no way to ever fix this.

[Graf Zahl]

That was basically unavoidable. Of course original Doom never bothered with sky positioning because looking up and down wasn't possible. So the sky's top was at the screen's top.
Raven extended this so that the top is at the screen's top when looking fully up - the problem here was that it didn't deal well with skies that are taller than 200, so ZDoom had to change it again, and made the mistake to use a height of 240 as the assumed maximum. Which required another change to make even taller skies work, but that again needed special treatment because it would have screwed over any sky between 240 and 256 otherwise. And so this mess developed...

[dpJudas]

Okay, so the blame goes to Carmack and Raven, but it still is such a PITA to deal with.

[Graf Zahl]

The blame goes to everyone who approached that code with some shady assumptions. The special cases to tall skies came when I had to fix the mess and was unable to do it with a single formula.

[dpJudas]

Well yes, that is usually what happens if the original premise is built on a bonkers idea (like tieing the sky texture to the screen resolution and a specific texture size). By the time it got to you there were already so many hacks that adding one more would just be business as usual.

[dpJudas]

Okay, fixed the Hexen sky stretching issue and added a r_capsky cvar that can turn it off.

[Rachael]

Neat. The sky stretching issue is fixed, now.

However... >_> *hides*

Screenshot_Hexen_20161016_082223.png (291.24 KiB) Viewed 1773 times

As aesthetically appealing as it is, I don't think the bottom fog is supposed to be there. The fog appears for Heretic's single-layer skies, as well (E1M1), but Doom's skies appear correctly.

Also it seems like my status bar is missing from my screenshot. o.O

[dpJudas]

Okay, fixed that too.

The missing status bar is because OpenGLSWFrameBuffer::GetScreenshotBuffer is currently not implemented. It should be there if you use the d3d9 target.

[Rachael]

Okay, I pulled from the latest and am compiling that for the latest build before I leave today.

[dpJudas]

Sounds good. The vid_hw2d fix has to wait for tomorrows build then I guess.

[Rachael]

Or I can just do another build. Of course, to you, it's "tomorrow" because you're 6 hours ahead of me.