DRD Team

I think it is better to keep LLVM in QZDoom for a while to be absolutely sure there are no nasty surprises. To do the changes I'm talking about LLVM isn't really strictly required, but the difference between me and Randi is that she actually can do quality assembly stuff. I can't just patch the assembly drawers as she can.

Eruanna wrote:Well - let's see if we can get Randi on board with this - of course it may mean that ZDoom, itself, will start requiring LLVM, which she seemed clearly leery about. But if the benefits massively outweigh the costs, she'll probably go along with it. (I sent her a PM linking this thread)

I'd sure jump for joy if LLVM gets into ZDoom because I could forget about targetting that obtuse VM with the scripting stuff. It's all so poorly documented that I still don't really understand what its instructions do. Why had it to be such abstract pseudo-assembly instead of being a bit more high level and approachable?

But as things are, I have my doubts it will happen, especially if it is just for compiling some isolated bits of the renderer.

What if you were to spawn an LLVM branch, and do some experimentation?

I already started such a branch, but at the moment it doesn't do anything. First I want to get a little further with the ZSCRIPT code generator.

Are skies always fullbright in ZDoom?

I believe so. The original Doom code never allowed sector settings affect the sky - not that there were many to begin with in those days.

You believe correctly.

I've switched the sky rendering to use its own drawers now. It fades the top and bottom out like GZDoom does, although I still need to track down how it picks the colors for the top and bottom.

Okay, hooked this up to same sky cap colors that GZDoom uses:


Now I just need to fix the projection (instead of my failed 'linear sky' attempt) and it will be all good!

Can this be backported to ZDoom, too? The sky stretching is one of the ugliest artifacts of all. BTW, if you fade out the sky, are you checking the texture's skyoffset property? GZDoom uses this to shift the sky up or down if necessary and with your approach ZDoom could do that as well for fine tuning the position.

Right now I use the texture coordinate as the rule for when to fade in and out. In GLSL syntax it works like this:

FragColor = texture(SkyTexture, TexCoord);
FragColor = mix(TopCapColor, FragColor, clamp(TexCoord.y * 4, 0, 1));
FragColor = mix(BottomCapColor, FragColor, clamp((2 - TexCoord.y) * 4, 0, 1));

The code that decides the texture coordinate is currently identical to how ZDoom has always been doing it. I think that included some skyoffset thing, but I didn't study the specifics of that part well enough to say for sure.

As for backporting to ZDoom, that is relatively simple, except that it requires a new sky drawer. Right now the palette mode in QZDoom doesn't support this new rendering because it doesn't have such a drawer. I can write a C version fairly easy, but the assembly version I cannot do.

Ok, then do it as a C version. If that is in the assembly version can be done later. It's still debatable if it's actually necessary. Might be a good idea to see if there is any performance gain if it can switch between this and the old method...

Okay, I'll prepare a PR for ZDoom adding this there as well.

Hexen skies feel really really long with this - I just tried MAP09 and the mountains are barely visible - whereas with both ZDoom and GZDoom you can almost completely see them.

This is a nice change, otherwise, though.

Oh, hmm. I must have misunderstood how it mixed the two textures based on the old code.