Problems with sky rendering

[Graf Zahl]

It looks like r_skymode is not working anymore. No matter what its value is, the sky will always be drawn tiled and not fade out to the top.

In addition, the softpoly renderer's sky scaling is totally off for tall skies, it seems to compress everything into a virtual 128 pixel high image.

As a result of these issues, sky positioning is not possible right now for non-standard sky sizes because all renderers do it differently.

[dpJudas]

Hmm, r_skymode is working fine on my computer.

About softpoly, the intention here was always to make it match the GL renderer - the skydome it uses is from there. Unfortunately I tied the fade to the texture UV coordinates, which turned out to be a really bad idea. It requires a change in the drawers and the vertex format to be fixed.

[Graf Zahl]

Hmm, r_skymode is working fine on my computer.

Really? For me it always looks the same when using a 256 pixel tall sky.

About softpoly, the intention here was always to make it match the GL renderer - the skydome it uses is from there. Unfortunately I tied the fade to the texture UV coordinates, which turned out to be a really bad idea. It requires a change in the drawers and the vertex format to be fixed.

I wasn't talking about the fade. Using a 256 pixel tall sky it gets squashed to roughly half the intended height. If you need test material, I could give you a few old compilation mods I made long ago with different skies which also use sky offsetting.

[dpJudas]

Really? For me it always looks the same when using a 256 pixel tall sky.

Ah, I thought you meant the cvar wasn't working at all. It probably never worked with a 256 pixel tall sky then.

I wasn't talking about the fade. Using a 256 pixel tall sky it gets squashed to roughly half the intended height. If you need test material, I could give you a few old compilation mods I made long ago with different skies which also use sky offsetting.

Sure, that sounds like it could be useful. I should be able to make the softpoly one match what the GL renderer does with a little effort, but I'm less optimistic about dealing with the classic software renderer. Its sky offsetting code is very convoluted.

[Graf Zahl]

, but I'm less optimistic about dealing with the classic software renderer. Its sky offsetting code is very convoluted.

Indeed. As long as the y-offsetting looks roughly correct for 128, 200, 240 and 256 pixel tall skies with r_skymode 2 it should be ok. Sadly the hardware renderer has so copy some of that messed up offsetting to make it match what originally was shown.
I'll have a look through my list of mods and pick some with good skies to check this evening.

[Lexus Alyus]

I noticed this being a problem with Heretic skies. I've recenly started to really enjoy the true colour software renderer, which has this nice single colour fade at the top of regular Doom skies, but tiles Heretic skies so they look a bit silly if you look up too high. I think this has been an issue for quite some time as I generally play on an older version of GZDoom (not sure on the exact version, but it must be about a year or 2 old), but I tested this out on the latest stable release and it's the same for Heretic skies. I'm assuming it's also the case for Hexen skies and any sky that is taller than 128 units. My own personal work around for this is to create tilng skies, but that's only relevant for my own projects. This issues isn't a problem with the GL renderer though.

I was going to post this as a new bug report, but I think this is the same issue that I'm experienceing. It might not be exactly the same, I dunno though...

[Paar]

I have recently discovered this bug and must say that it's very annoying. As of now you cannot make a sky that is higher than 128 pixels and has no tiling effect. According to dpJudas this is something that's not easy to fix. Is that true? It's definitely frustrating to not be able to make this happen. It seems that this problem originated from the extension of the looking up pitch limit.

I have tried to simulate this with Heretic E1M1 with these results:

Capped when looking up roughly in an angle that is maximum in the vanilla game. You can see that the upper border is fading out. The bottom edge of the sky is untouched.


Capped when looking higher up. The sky begin to tile, fade out effect disappears and what is interesting, the bottom edge of the sky starts to fade out (sorry it's not entirely apparent on screenshot).


Normal mode. The sky is not fading out in any angle and the same applies for them bottom edge. Texture tiles.


Stretched mode. It behaves like normal mode. I assume that the code doesn't consider this necessary with 200 pixels high texture.


I am surprised that Graf accepted the looking limit removal without modifying the sky behavior. Now it's broken and only thing that player can do is setting "cl_oldfreelooklimit" to 1 via console. I wouldn't have a problem with that if the new extended limit wasn't a default setting.

[dpJudas]

I have recently discovered this bug and must say that it's very annoying. As of now you cannot make a sky that is higher than 128 pixels and has no tiling effect. According to dpJudas this is something that's not easy to fix. Is that true?

Technically, the issue here is that the function that applies the fade effect receives input texture coordinates that have been shifted into a range that is valid and should not be faded. I tried to track down where that happens and figure out why it is doing it, but ultimately failed.

If you have enough developers over enough years add one hack after another, usually naming them all 'fake'.. at some point the tower collapses and that's what happened to the software renderer. I'm sorry, but I cannot fix this bug without breaking something else. Hell, I can't even figure out how the sky scaling code even works. It should be a simple translate, scale or maybe rotate - instead there's insane stuff at the bit shifting level, usually documented with a comment saying "// it is fake!"..

[Graf Zahl]

and that's what happened to the software renderer

... and this is not the only place.
After expanding the Doom 64 color feature today I wanted to port at least the single color effect to the software renderers. With softpoly it was relatively easy because the code is reasonably well organized.

No such luck with the original renderer. Like you said, over the years too many people with too many neat ideas but too little discipline to keep the code sane have turned it into a monstrosity that isn't really maintainable anymore. The entire handling for lighting and colors is all over the place. It's still possible to add per-line effects, but beware if you want to do per-tier effects. And this wasn't the first time I had to fold on this. The last time I tried to add per-tier coloring the same happened. The code is such a total disaster that I had no chance to get it in.

So yeah, sorry. You have to take what you can get, but there's really nobody here who is willing to work with that code anymore.

[Paar]

Okay, what about other modes? Capped mode is obviously broken and will be hard to fix but it would be nice if I could at least set the mode to normal and make big enough sky texture that would cover entire area of the freelook angle. I don't care for stretch mode because the result is an ugly mess of oversized pixels but I understand that it should be fixed too. Others may like it.

I just don't understand why implement something (bigger mouse look limits) at the expense of something else. The original vertical mouse look was a bit limiting but it wasn't so bad that I would sacrifice something so vital as sky texture behavior. I consider it vital because it can ruin your work to some degree. It will descrease the visual quality of your project and you cannot do anything about it.

[Paar]

So yeah, sorry. You have to take what you can get, but there's really nobody here who is willing to work with that code anymore.

This is a bit depressing. More so after true color mode was implemented. I really saw it as a new dawn and thought that the software renderer will get expanded even more. I never knew that the source was in such a bad shape.

May I ask what does that mean for the future of the renderer? Will it get more and more obsolete to the point the most OpenGL features won't be compatible and software renderer will become just a relic of a time?

[dpJudas]

This is tricky to answer as I personally don't know everyone's motivation for using the software renderer. One possible future would be to port softpoly to act as a backend to the hardware renderer. This would fix all its rendering bugs.

Softpoly should be able to match the speed of the original software renderer if it is given two extra drawer variants: wall and plane with constant Z. Plus a few other minor tweaks like using a different projection matrix. At that point you have the ability to stay in 8-bit palette mode, which I think is the primary motivator for most people to use the software renderer. Are there any other reasons to use it? If there is not, I don't see any particular reasons to keep that code given it is just going to fall further and further behind.

[Paar]

The original software renderer just has a big nostalgia factor. That's how we used to play idTech1 games back in the day, right? Other than that I don't think there are any significant benefits, perhaps if you would develop a commercial game it could be interesting selling factor. I would love for it to be preserved and expanded but with the condition it is in I would understand if it got forgotten over time. The softpoly is the closest thing to it and I would love for it to be developed further even though it seems it is a low priority now. The possibilities you mention are exciting and I look forward to more updates even though some would argue that 8bit colormap emulation in OpenGL/Vulkan would make more sense. But I'm not a sofware engineer so I can only observe and enjoy things you decide to make.

[Rachael]

My main motivation for using software has always been correct sprite rendering. Most sprites have offsets that put some pixels underneath the actual actor to give the illusion of a "pop-out" effect which does not work in OpenGL. This, along with a few other issues that are a bit of a challenge to mitigate, make sprites effectively look a lot like cardboard cut-outs in OpenGL - it's very obvious when you look at them what they are. After a while you get used to it, but I still think they look better in Software.

[Graf Zahl]

My main motivation for using software has always been correct sprite rendering.

On the downside it has its own glitches that occasionally can even be worse than the hardware renderer