The sky...
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
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.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: The sky...
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.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: The sky...
What if you were to spawn an LLVM branch, and do some experimentation?
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: The sky...
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.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
Are skies always fullbright in ZDoom?
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: The sky...
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.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: The sky...
You believe correctly.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
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.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
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!
Now I just need to fix the projection (instead of my failed 'linear sky' attempt) and it will be all good!
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: The sky...
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.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
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.
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.
- Graf Zahl
- GZDoom Developer
- Posts: 7148
- Joined: Wed Jul 20, 2005 9:48
- Location: Germany
- Contact:
Re: The sky...
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...
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
Okay, I'll prepare a PR for ZDoom adding this there as well.
- Rachael
- Developer
- Posts: 3646
- Joined: Sat May 13, 2006 10:30
Re: The sky...
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.
This is a nice change, otherwise, though.
-
- Developer
- Posts: 798
- Joined: Sat Jul 23, 2016 7:53
Re: The sky...
Oh, hmm. I must have misunderstood how it mixed the two textures based on the old code.