Animating textures with hardware shaders

[boris]

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

Not really. Of course you can apply rotation math to (parts) of textures with the method described above. But rotating a whole texture by 45° or so will not work out. For sprites it might work out with some trickery and sprites specifically crafted for this purpose, but it's still very limited, because there's no way to tell how much the shader how many degrees you want to rotate. For sprites it would make much more sense to do the rotation using a vertex shader (I assume the sprites are just drawn as a rectangle).

[kodi]

Not really. Of course you can apply rotation math to (parts) of textures with the method described above. But rotating a whole texture by 45° or so will not work out.

Oh I realize that, sorry for being unclear. But say if my texture is an 128*128 alpha channel PNG (like a big wheel for example), could rotation centered on it's axis be applied to it? If tiled, each wheel would spin independetly.

For sprites it might work out with some trickery and sprites specifically crafted for this purpose, but it's still very limited, because there's no way to tell how much the shader how many degrees you want to rotate.

I know information can't be passed to the shader so it'd definetely be used for sprites that are supposed to rotate constantly - it could then be used on a vortex-like sprite to simulate Quake 4's dark matter gun projectiles for example.

[boris]

Yeah it's possible. You can also rorate huge parts of a texture, as long as what you want to rotate does not have a bigger diameter than the shorter side of your texture.

[GooberMan]

Rotations like that are generally done in the vertex shader. GZDoom doesn't give you access to vertex shaders. Ergo, it'll be balls-slow if you do a rotation at pixel time.

[Graf Zahl]

Balls slow like the warped textures? I never had problems with these, even when the entire screen consisted of warping textures.

[GooberMan]

Doing the rotation operation 4 (or 6 depending if tri strips or lists are used) time compared to doing it potentially for every single pixel in the backbuffer? There's a performance boost to be had.

Now combine a rotation texture with the random warp.

Shader operations stack up fairly quickly if you try to do more than simple things with it.

[Graf Zahl]

Well, too good then that the engine hardly requires any shader computing power to begin with so that these things aren't that bad.
The computations for texture rotation are nothing compared to what shader based dynamic lights require - and even those worked fine on my old, long broken system with a Geforce 8600 - at least it wasn't worse than layering all those lights on top of each other with multiple rendering passes.
I'm well aware, though that this lighting system might have ground a modern game with more complex effects to a halt. But this is Doom we are talking about.

[boris]

Attached is a updated example with 4095 (slightly glitchty) rotating Megaspheres. Still runs at a constant 60 fps for me.

[Graf Zahl]

I don't think that's really representative. A pixel shader's performance isn't determined by the amount of surfaces using the shader but by the amount of actual pixels affected by it.

[Leonard2]

Still runs at a constant 60 fps for me.

Not for me.
I went on and tested this and when I saw the map I immediately did "turbo 256" and tried to collect all the megaspheres as fast as possible.
It was smooth but suddenly I had a HUGE FPS lag followed by this:

ss (2015-06-22 at 05.02.24).png

No idea what's happening here
So far I tried it twice and the exact same thing happened, 72 bytes failed to allocate.
Could be a bug?

[Gez]

You ran out of memory. Given the amount of memory generally available nowadays, it is possible it is caused by a bug, such as a memory leak.

[ibm5155]

^ It looks like some infinte loop, I beat there are 72 MegaSphere! messages on that window. (it's like an infinte function loop in acs, you add a while true and spam random projectiles, your fps will go to zero and the function will crash)

you guys want more performance? port gzdoom to glnext or directx12, the main problem is the cpu use itself, and both api will help on that part, the only down side would be the support for legacy gpus, maybe make something like vavoom did, standart opengl render option and advanced opengl render option (this one being glnext)

[wildweasel]

ibm5155, do you have some basis for that post, or are you guessing?

[kodi]

Thanks a ton for the rotation shader (and the others as well) boris!
I've been interested in shaders for a while but didn't have a clue were to start, should be able to experiment some with this.

Edit: just made a spinning cacodemon. Some distortion, but holy damn it's hilarious

[ibm5155]

ibm5155, do you have some basis for that post, or are you guessing?

about Glnext/dx12 yes.

Vulkan is also able to better distribute work among high amounts of CPU cores, as concluded by a simulation that used an "infinitely fast" GPU on a 16-core CPU.[9] Vulkan is derived from and built upon components of AMD's Mantle.[10][11][12][13][14][15]

The main problem of gzdoom is related to make a better use of all CPU cores, that's why there's a big hype about the new glnext(Vulkan) and DX12.

About the MegaSphere crash it's just a guess,with acs, a function cannot use too much time, if a function requires too much time without a delay, it'll consume the time for rendering, so your fps will be lowered acording to the size of the loop. Zdoom avoid an infinite loop breaking the function.
I just suspect that something like that happened when he got the MegaSphere, maybe on that specific map there was more than 73 MegaSphere on the same space (it wouldn't help neither for multiplayer,since a single player would pass over there, get an earrape and receive all the MegaSphere for he)...

It's just a guess, but it looks like something similar...