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

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

Re: The sky...

Post by dpJudas »

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

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.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael »

What if you were to spawn an LLVM branch, and do some experimentation?
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 »

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

Re: The sky...

Post by dpJudas »

Are skies always fullbright in ZDoom?
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael »

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.
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 »

You believe correctly.
dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: The sky...

Post by dpJudas »

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

Re: The sky...

Post by dpJudas »

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

Now I just need to fix the projection (instead of my failed 'linear sky' attempt) and it will be all good! :D
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 »

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

Re: The sky...

Post by dpJudas »

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.
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 »

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

Re: The sky...

Post by dpJudas »

Okay, I'll prepare a PR for ZDoom adding this there as well.
User avatar
Rachael
Developer
Developer
Posts: 3639
Joined: Sat May 13, 2006 10:30

Re: The sky...

Post by Rachael »

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

Re: The sky...

Post by dpJudas »

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

Return to “QZDoom”