GZDoom Hardware Shader

[Urthar]

So I tried a 512x128 version:

uniform float timer;

vec4 Process(vec4 color)
{
// get texture coordinates
vec2 uppersky = gl_TexCoord[0].st;
vec2 lowersky = gl_TexCoord[0].st;

// scroll sky
uppersky.x += timer / 64.0;
uppersky.y += timer / 16.0;
lowersky.x += timer / 32.0;
lowersky.y += timer / 8.0;

// lowersky is left mid-quarter of texture
lowersky.x = mod(lowersky.x, 0.25) + 0.125;

// uppersky is right mid-quarter of texture
uppersky.x = mod(uppersky.x, 0.25) + 0.625;

// get texel for updated texture coordinates
vec4 lowerskyTexel = getTexel(lowersky);
vec4 upperskyTexel = getTexel(uppersky);

// Mix lower and upper sky
return color * mix(upperskyTexel, lowerskyTexel, lowerskyTexel.a);
}

That eliminated the horzontal lines, but the vertical lines remain, though they're a lot less obstrustive than the original black lines:



I don't think using mod instead of floor makes a difference, except in perhaps making the code a bit cleaner, and I suspect that because Linear Filtering works, that this is some form of mip map issue.

I had a brief look at various GLSL references, and there appears to be a dedicated offset function for handling these sort of sub textures, but that all gets set up outside of the fragment shader, so I think this is as good as I can get it for the time being.

[Graf Zahl]

Maybe it's a precision issue with the timer. This reminds me of one very odd bug report I got but never was able to track down:

http://forum.drdteam.org/viewtopic.php?f=24&t=5832

It wouldn't surprise me if both issues have the same cause - but due to shaders being close to impossible to debug I have no idea how to analyze what happens here.

[MaxED]

Graf Zahl said:

due to shaders being close to impossible to debug

Huh? Really?

[Graf Zahl]

I didn't say 'impossible', but 'close to impossible'. The small variations in the calculations that cause these problems are extremely hard to find.
It's not that this is some blatant and obvious error.

[MaxED]

Well, if it's a timer issue, I guess it's not directly related to GZDoom, because the same thing happens in PolyDraw:


Speaking of which, if anyone's willing to mess with the shader, here's the polydraw project I've used.

[boris]

One problem will be that neither x - floor(x) nor the modulo variants will ever reach 1.0: for 1.0 they will return 0 instead of the desired 1.0.

[Urthar]

Hmmm, I could try using an IF statement to look for even and odd integers.

[Urthar]

I introduced a test for odd integers, setting them to the equivalent of 1, but it didn't seem to make any difference.

uniform float timer;

vec4 Process(vec4 color)
{
// get texture coordinates
vec2 uppersky = gl_TexCoord[0].st;
vec2 lowersky = gl_TexCoord[0].st;

// scroll sky
uppersky.x += timer / 64.0;
uppersky.y += timer / 16.0;
lowersky.x += timer / 32.0;
lowersky.y += timer / 8.0;

// lowersky test for odd integer value and map to left side
if (mod(lowersky.x + 1.0, 2.0) == 0.0)
{lowersky.x = 0.375;}
else
{lowersky.x = mod(lowersky.x, 0.25) + 0.125;}

// uppersky test for odd integer value and map to right side
if (mod(uppersky.x + 1.0, 2.0) == 0.0)
{uppersky.x = 0.875;}
else
{uppersky.x = mod(uppersky.x, 0.25) + 0.625;}

// get texel for updated texture coordinates
vec4 lowerskyTexel = getTexel(lowersky);
vec4 upperskyTexel = getTexel(uppersky);

// Mix lower and upper sky
return color * mix(upperskyTexel, lowerskyTexel, lowerskyTexel.a);
}

[boris]

Trying to compare floating point values for equality can be problematic.