Animating textures with hardware shaders

[boris]

Some post on DW made me play with GZDoom's hardware shaders, and I realized you can use them to animate textures - or more specifically build compound textures where only parts are animated (unlike the swirling textures). I'm not sure if this has been done before, so I'll explain how it works. First, here's a video of what it looks like:



On the left only the stripes are animated. This is not done with multiple frames, so the animation is very smooth. On the right side is a green stone wall, with two layers of blood running down at different speeds.

As only one texture is processed by the shader I'm using a little trick - I'm just putting all the different parts I need in the same texture. The textures you see actually look like this:



Then I'm utilizing the fact that the shaders can access other parts of the texture and do something with the retrieved information. For example in the blood fall texture I'm taking the blood parts, constantly scroll them a little and then blend them over the stone and each other. The shaders look like this:

Silver texture

---

Code: Select all

uniform float timer;

vec4 Process(vec4 color)
{
	vec2 background = gl_TexCoord[0].st;
	vec2 foreground = gl_TexCoord[0].st;
	vec2 highlight = gl_TexCoord[0].st;
	
	// Background starts at 64 units
	background.x += 1.0/3.0;
	
	// Highlight starts at 128 units and scrolls
	highlight.x += 1.0/3.0*2.0;
	highlight.y += timer * 0.5;
	
	// Make sure y is between 0 and 1
	highlight.y = highlight.y - floor(highlight.y);

	vec4 backgroundTexel = getTexel(background);
	vec4 forgroundTexel = getTexel(foreground);
	vec4 highlightTexel = getTexel(highlight);
	
	// Draw either the overlay, or the background
	if(forgroundTexel.a > 0)
		return forgroundTexel * color;
	else
		return (backgroundTexel * highlightTexel) * color;
}

Blood texture

---

Code: Select all

uniform float timer;

vec4 Process(vec4 color)
{
	vec2 background = gl_TexCoord[0].st;
	vec2 blood1 = gl_TexCoord[0].st;
	vec2 blood2 = gl_TexCoord[0].st;
	
	// Get the first blood stripe (starting at 64 units)
	// It's scrolling faster than the second one
	blood1.x += 1.0/3.0;
	blood1.y -= timer * 0.1;
	// Make sure y is between 0 and 1
	blood1.y = blood1.y - floor(blood1.y);
	
	// Get the second blood stripe (starting at 128 units)
	// It's scrolling slower than the first one
	blood2.x += 1.0/3.0*2.0;
	blood2.y -= timer * 0.05;
	// Make sure y is between 0 and 1
	blood2.y = blood2.y - floor(blood2.y);
	
	vec4 backgroundTexel = getTexel(background);
	
	// Add alpha to the texel
	vec4 blood1Texel = getTexel(blood1);
	blood1Texel.a = 0.75;
	
	// Add alpha to the texel
	vec4 blood2Texel = getTexel(blood2);
	blood2Texel.a = 0.5;
	
	// Blend the blood over the stone wall
	vec4 texel = (1.0 - blood1Texel.a) * backgroundTexel + blood1Texel.a * blood1Texel;
	texel = (1.0 - blood2Texel.a) * texel + blood2Texel.a * blood2Texel;
		
	return texel * color;
}

I'm not really good with shaders, so the code could most likely be improved. It should also be possible to make more advanced, cooler looking effects. The example map from the video is attached to this post.
There's one "problem" though. You have to make sure that the line you place the texture on is no longer than the compound texture result. In the case of the example textures that is 64 units. That means if you want to place them on a 128 unit long wall you have to split that wall in 64 unit parts. If you fail to do so you'll see the unanimated parts of the texture.

[boris]

There's one "problem" though. You have to make sure that the line you place the texture on is no longer than the compound texture result. In the case of the example textures that is 64 units. That means if you want to place them on a 128 unit long wall you have to split that wall in 64 unit parts. If you fail to do so you'll see the unanimated parts of the texture.

Looks like this can be fixed by modifying to shift all coordinates left when the x component is biggerthan 1/3.

[Nash]

The fact that the texture continues to animate even when the game is paused/console is open/menu is open prevents me from ever taking shaders in GZDoom seriously and I won't even consider using them...

[Graf Zahl]

The fact that all other texture animations also continue while the game is paused must mean then that you cannot take ZDoom as a whole seriously, right?

[Gez]

The fact that the texture continues to animate even when the game is paused/console is open/menu is open prevents me from ever taking shaders in GZDoom seriously and I won't even consider using them...

Have you missed that this happens to all animated textures in ZDoom, regardless of how they're animated? Does that prevent you from taking (G)ZDoom seriously and from considering using it?

The only way to have animations that pause when the game pause is to have your animation handled by something that is tied to game logic, like ACS or DECORATE code. Or to use a port that's not derived from ZDoom.

[edward850]

The fact that the texture continues to animate even when the game is paused/console is open/menu is open prevents me from ever taking shaders in GZDoom seriously and I won't even consider using them...

Have you missed how this has been a thing since 1993?
Honestly it's hard to take you seriously sometimes.
Edit: Well then. My mind is playing tricks on me again.

[Gez]

Have you missed how this has been a thing since 1993?

It's not vanilla behavior. I don't feel like looking back for when exactly ZDoom started doing that. It's old, but not "older than ZDoom itself" old.

[edward850]

Actually, yeah. That's really weird, because I could have sworn I had seen it manifest from there, and yet not even Boom exhibits it, or the old ZDoom 1.17c. What I'm then probably remembering is the HUD continues to animate.
But then that begs the question as to where this does come from? Best guess is the interpolation code needed a different timer?

[NeuralStunner]

Since AnimDefs frames can use "partial tics", I guess it was necessary. That capability might come from Boom, I don't know.

[Caligari87]

This is really cool, I just wish I could actually make sense of how that shader code works, or at least get a "for dummies" reference. Wouldn't mind trying my hand at a few.

[Graf Zahl]

Since AnimDefs frames can use "partial tics", I guess it was necessary. That capability might come from Boom, I don't know.

That's precisely the reason. Animation speed is uncoupled from the playsim, not only for partial tics but also to allow animating menu graphics.

[boris]

This is really cool, I just wish I could actually make sense of how that shader code works, or at least get a "for dummies" reference. Wouldn't mind trying my hand at a few.

As I said I'm not really good with shaders myself, but I'll try to explain how the shaders works (so don't expect this to be the ideal or even good way). The shader computes the color of one pixel on your screen and not of the actual texture. If you look closely you'll see that the animation works on a sub-texture-pixel level.

Here's a breakdown of the silver texture shader:

Code: Select all

vec2 background = gl_TexCoord[0].st;
vec2 foreground = gl_TexCoord[0].st;
vec2 highlight = gl_TexCoord[0].st;

This sets three 2-dimensional vector variables. gl_texCoord[0].st gets the x/y components of the current texture position. They are all the same, but will then be modified point to other pixels. background will be the blue part, foreground the silver part, highlight the light stripe part. It's important to understand that the values are not in real texture dimensions (in this example192x128), but in the range of 0.0 to 1.0, where (0.0, 0.0) is the top left and (1.0, 1.0) is the bottom right. So the actual texture has these positions:

(note that the x values written as 0.333 and 0.666 are actually 1/3 and 2/3)

Code: Select all

background.x += 1.0/3.0;

This adds an offset of 1/3 (one third) of the texture dimension to the x position of the background vector. That means if the topmost leftmost pixel (0, 0) is processed, this vector will now point to (0.333..., 0), or to the topmost leftmost pixel of the blue part of the texture.

Code: Select all

highlight.x += 1.0/3.0*2.0;

This adds 2/3 (two thirds) of the texture dimension to the x position of the highlight vector. That means if the topmost leftmost pixel (0, 0) is processed, this vector will now point to (0.333..., 0), or to the topmost leftmost pixel of the highlight part of the texture.

Code: Select all

highlight.y += timer * 0.5;

This modifies the y position of the vector pointing to a pixel on the highlight part of the texuture. It takes the game time into account, so as time goes on the position will change, which will give the illusion that the texture is scrolling. It's multiplied by 0.5 (or divided by 2) so that it doesn't scroll superfast.
Let's say we're processing the topmost leftmost pixel of the texture (0, 0), at time 0 highlight.y will be 0. At time 0.1 highlight.y will be 0.05. At time 0.2 highlight.y will be 0.1 and so on.

Code: Select all

highlight.y = highlight.y - floor(highlight.y);

As said as the beginning, the texture dimension is between 0.0 and 1.0, so this makes sure highlight.y stays in that range. This is necessary because the value of highlight.y computed in the previous step grows bigger and and bigger as time goes on. For example a time 314.6 highlight.y will be 157.3, which will be reduced to 0.3 here. So basically it starts back at 0 once 1.0 is reached.

Code: Select all

vec4 backgroundTexel = getTexel(background);
vec4 forgroundTexel = getTexel(foreground);
vec4 highlightTexel = getTexel(highlight);

Gets the texel information at the position of each in RGBA format (I guess getTexel is a function defined by GZDoom). So at this point the shader has color information of three different pixels from the texture.

The following part says what color the pixel shown on the screen shoud have.

Code: Select all

if(forgroundTexel.a > 0)
	return forgroundTexel * color;

This checks if the pixel we want to show is transparent or not. If it is not transparent the silver texture will be displayed, otherwise we'll go into the else branch below. Effectively this will draw everything but the "windows" of the texture. It's multiplied by color (which is supplied to the shader) to take light level, color, fog etc. into account.

Code: Select all

else
	return (backgroundTexel * highlightTexel) * color;

If the alpha of foregroundTexel is 0 the shader will draw the light. It will do so by multiplying the background (blue) color with the highlight color. The highlight color is in a range of black and white, so multiplying it with the background color makes the blue either brighter or darker. Finally it's multiplied with the color supplied to the shader.

And that's pretty much it. Hope it helps.

[Nash]

Wow so much hostility in this thread, I didn't mean what I said in a bad way of course. :D Everyone here is aware by now that ZDoom is still my engine of choice despite me complaining about this and that - and probably will be forever - not even those fancy new AAA engines could attract me.

Yeah I'm aware that animated textures used to be one with the playsim because in older versions of ZDoom, such was the case and then somewhere along the way this was changed... which is normally not a big deal at all for normal Doom play but for non-Doom projects, and depending on what specific purpose, the continuously animating textures when the game is paused can be either undesirable or even "immersion breaking"... of course my comment was spoken in a "non-Doom-project" context but eh, I'll live with it. :)

[Tormentor667]

Tarin ftw!

[kodi]

I'll save this for later and see what can be done with it. Really neat!

Kinda OT: There's an idea I've been pondering about shaders, could they be used to rotate sprites and textures smoothly?