Problems with sky rendering

[Graf Zahl]

Sorry for bumping, but I have a small update.

While abusing the changesky CCMD to test out some textures I noticed that r_skymode 2 does in fact apply the fade, but it is very funky. When looking up the sky just repeats instead of drawing the cap and the fade disappears - it is only visible when looking straight ahead.

Maybe this is something for drfrag to hunt down? I have no desire to investigate software rendering bugs myself.

Here's one that shows the problems best:

https://drive.google.com/open?id=1SCb40 ... -ZrZUDh1Ge

[dpJudas]

The sky drawer will fade texture coordinates that go past -1 and 1. So far so good, but unfortunately there's setup code that remaps texture coordinates out of range if the texture is not a power of two.

Instead of applying this logic at the very last stage before calling a drawer, someone decided to do this much earlier and in such a convoluted way that I've been unable to reliably disable it without introducing other visual bugs. That's why in some GZDoom releases the fade sky worked, and in other releases it didn't, because every time I tried to fix it someone else undid it due to some other glitch appearing.

[Graf Zahl]

The sky drawer will fade texture coordinates that go past -1 and 1. So far so good, but unfortunately there's setup code that remaps texture coordinates out of range if the texture is not a power of two.

Instead of applying this logic at the very last stage before calling a drawer, someone decided to do this much earlier and in such a convoluted way that I've been unable to reliably disable it without introducing other visual bugs. That's why in some GZDoom releases the fade sky worked, and in other releases it didn't, because every time I tried to fix it someone else undid it due to some other glitch appearing.

Well, in that case I think we have to disable the feature and clamp the view pitch again. Because right now it's just visibly broken.
Sadly, as things stand, nearly every work being done on the software renderer seems to be hacks to make specific things work (and like this one) often break more important functionality.
If this continues it is only a matter of time until it breaks completely.

Can you point me to the commit that did the initial screwup? I'd like to have a look myself.

[drfrag]

One possible future would be to port softpoly to act as a backend to the hardware renderer. This would fix all its rendering bugs.

My interest in the software renderer mostly comes from my interest in the polybackend branch.
I think dpJudas become burned out of dealing with that messy and convoluted code. I estimate 1 dpJudas == 10 drfrags or even worse so why should i be able to clean up this mess? What he could fix in minutes it takes me hours that's in case i can do it. But on the other side you never know, i'm randi's disciple and the path of "randi-ism" is hard. I will take a look at it probably soon.
I guess the problem is the new looking up angle itself and not the height of the sky, everything needs to be hacked (again) for the new angle... becouse you know it's fake.
BTW seems the polybackend branch has been put on hold, i mention it becouse i won't be able to maintain LZDoom forever. I see now the startup screens are being ported to OpenGL, that could be a problem. But no big deal, may be switching earlier to the graphics mode like in ancient ZDoom would solve it and would be also cool.

[drfrag]

I've just read dpJudas' reply. Skies were already broken in ZDoom32, all modes even stretching in vanilla Doom II (fade works there) after changing the look up angle.

[dpJudas]

I can't point at a specific commit - all I can say that when I did my initial commits the sky fade did work for the maps I tested it on (vanilla doom, mostly). Then in later releases it did not because other people made changes.

If the software renderer was a professional product I was paid to maintain, my strategy here would be to rewrite certain functions in the software renderer and take the regressions it would produce. From there reimplement whatever those damn hacks were trying to accomplish in a proper fashion when I discover what they tried to do (from reported regressions).

However, this is the Doom community. If I do it here there will be a bug report from someone saying GZDoom is teh suck, MAYBE give me a map file for debugging if I'm lucky, and then essentially expect me do all the heavy lifting. I'm sorry, but I'm just not paid enough to do that. It also doesn't exactly help certain big profile folks of software rendered doom acted like assholes to me, so there goes the last good will!

[Graf Zahl]

I understand your pain.
But yeah, I'd do it the same way. Trying to refactor something this big without having regressions is impossible.

Let's talk about this when I am done hacking EDuke32's low level renderer to pieces and rebuilding it in a saner fashion. It's slow and painful progress because wherever I look - inside and outside the renderer - I find problems that eventually need to be fixed, and I cannot do everything at once while keeping things running. Doom's software renderer had always been on the same level for me - with the added caveat that my interest in 8 bit software rendering is close to nil (and that's what prompted me to take on the Build engine in the first place, because it had effectively reverted the hardware renderer to a paletted display simulation with all the things I dislike about that...)

[Graf Zahl]

I see now the startup screens are being ported to OpenGL, that could be a problem. But no big deal, may be switching earlier to the graphics mode like in ancient ZDoom would solve it and would be also cool.

I don't plan to port them to OpenGL but to the hardware independent render backend. The software-rendered backend would be able to deal with them just as well - but if that worked out they'd no longer be Windows exclusive.

What I managed so far is to initialize the frame buffer earlier in the startup code to be able to use it here, but there's several gotchas to sort out first:

* currently the screen resolution maintenance is not properly encapsulated. Messing around with the frame buffer during startup affects the global setting which it should not - it should be the other way around that this is being maintained externally and then sets the framebuffer's size instead of letting the frame buffer maintain its size and the global backing setting for that.

* another issue is the messed up exit code which may have made sense on DOS in 1998 (but even then only in Lee Killough's mind ) but on modern systems is a genuine hassle. The main blocker here is that the Posix backend is quite careless in how it terminates in case of a fatal error.

Without these two out of the way, it'd be a bit problematic - the core feature itself is not that hard to pull off - I got a 2D screen, turn it into a texture and render it. Case closed.

(But even that has to wait, because I am currently trying to untangle Build/Polymost's texture management from the high level rendering - the details of what textures are filter up far too high in the logic, causing spurious errors in many places - probably one of the reason why they went the palette-only route...)

So yeah, right now I'm spread a bit thin...

[drfrag]

Interesting... i missed your post somehow.
About the skies this is a mess, i need to investigate these commits:

Code: Select all • Expand view

16/10/2016 * Fix hexen sky cap offset
16/10/2016 * Fix hexen sky stretching
15/10/2016 * Move true color sky drawing to its own drawers and chamge r_stretchsky to false as the new drawers can fade to a solid color

But the new look up limit was stablished much later. Seems capped skies worked even in Heretic and Hexen but i don't remember them doing so.
Stretching is broken now too obviously and seems everything is hard-coded for the old limit and 200 pixels height. Changing SKYSTRETCH_HEIGHT just makes the sky bigger but it tiles exactly the same.

[Graf Zahl]

Yes, that sounds that someone truly fucked it up. When the sky capping was implemented the system was definitely working.

[drfrag]

Someone please call randiii...
Nah, i was kidding. I have exorcised the demons... this house is clear.
That was not the case, they could never have worked with the old freelook limit and offset. So dpJudas could not test them back then, it was a very minor thing actually. First i fixed the stretching (should be) but i haven't really tested with other big skies.
I've fixed them in LZDoom tough so now i need to port the code to do a PR.
Edit: ouch! I had the status bar on when i adjusted the stretching for Heretic. Hope the devbuilds aren't screwed as i did a hard reset.
Edit2: done. https://github.com/coelckers/gzdoom/pull/950