The sky...

Truecolor ZDoom with extra features and some unofficial/beta GZDoom features.
[Home] [Download] [Git builds (Win)] [Git builds (Mac)] [Libs (Win)] [Repo] [Bugs&Suggestions]

Moderators: Rachael, dpJudas

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael » Sun Oct 16, 2016 8:00

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).
Spoiler: Zen Sarcasm

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The sky...

Post by Graf Zahl » Sun Oct 16, 2016 8:08

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
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 8:16

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. :(

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The sky...

Post by Graf Zahl » Sun Oct 16, 2016 8:30

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
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 8:36

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

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: The sky...

Post by Graf Zahl » Sun Oct 16, 2016 8:42

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
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 8:53

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. :D

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 12:33

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

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael » Sun Oct 16, 2016 13:25

Neat. The sky stretching issue is fixed, now. :)

However... >_> *hides*
Screenshot_Hexen_20161016_082223.png
Screenshot_Hexen_20161016_082223.png (291.24 KiB) Viewed 154 times
As aesthetically appealing as it is, I don't think the bottom fog is supposed to be there. :P 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
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 14:50

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. :)

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael » Sun Oct 16, 2016 14:54

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

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas » Sun Oct 16, 2016 15:21

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

User avatar
Rachael
Developer
Developer
Posts: 3616
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael » Sun Oct 16, 2016 23:02

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

Locked

Return to “QZDoom”

Who is online

Users browsing this forum: No registered users and 1 guest