PSX Flaming Sky

[Enjay]

I was reading this (found via a link on Doomworld)

http://fabiensanglard.net/doom_fire_psx/

and I wondered how easy it would be to implement in GZDoom (perhaps GZDoom's full sky might make it a no-go?) and if there might be any enthusiasm for it?

It would be nice to have something engine-side rather than having to use a huge sequence of animated textures and, if it was implemented engine-side, the colour ranges might also be definable - allowing fire skies of any colour to be created.

[Gez]

Some times ago I tried to see if it could be made with shaders; but unfortunately no -- each frame modifies the previous, and while you can access the source image from the shader I don't think you can access the previous render.

Other than that, the code is very simple and as long as you can access the previous frame's output, it's easy. If the texture manager gets exported to ZScript, for example, it could be done simply there.

[Erick194]

It would be nice to add it, but you have to take into account that the code of
Fabien Sanglard and the kaiser, is not the correct sequence for the fire of Psx Doom.

[Hellser]

I don't think it has to be correct, but rather seems similar to.

[Rachael]

In my opinion, this would be a lot easier to do if it was possible to dynamically manipulate textures using ZScript - something reminiscent of UE1's animated textures system. (Like FireFX)

Yes, it's possible to do things like ripples and other non-destructive changes using shaders, but as was pointed out shaders don't save their result in the texture to be reused later.

[Graf Zahl]

And that won't happen. Remember that we eliminated the last one that did such stuff half a year ago? Dynamic textures make renderer optimization a lot more complicated.
That said, of course you can store the result of a shader generated image in a texture, just not from the shader itself. If not there wouldn't be camera textures!

Manipulating shaders from script code is pretty much the ultimate performance killer. There was a reason that in older GZDooms the size of warped textures was limited.

[Erick194]

I don't think it has to be correct, but rather seems similar to.

You're right, but it's good to feel as similar as possible, some time ago I did something similar with the psx fire, but I noticed that the pixels did not match the intro of psxdoom, which in the code of psxdoom v1.0 to be exact in the function (0x80027B90)

Code: Select all

L80027B90()//FIRE PSX
{
	r11 = r4;
	r3 = 0x80080000;
	r9 = 0;
	r5 = *((*(r11 + 16) << 2) + *L80078060) + 72;
	do {
		r8 = 1;
		r10 = 1;
		r6 = r5;
		do {

			//R_SpreadFire Here Start
			if ((*r6 & 255) != 0) {
				r2 = *(r28 + 1368) & 255;
				r4 = r2 + 1;
				r3 = r2 & 255;
				*(r28 + 1368) = r4;
				r1 = 0x80060000;
				*(r28 + 1368) = r2 + 2;
				r1 = 0x80060000;
				*((r10 - ( *(0x80058888 + r3) & 255 & 3) & 63) + r5 + -64) = r7 - ( *(0x80058888 + (r4 & 255)) & 255 & 1);
			}
			else {
				*(r6 + -64) = 0;
			}
			//R_SpreadFire Here End

			r6 = r6 + 64;
			r5 = r5 + 64;
		} while (r8 + 1 < 128);
		r5 = r5 + -8128;
	} while (r9 + 1 < 64);
	*(r11 + 28) = -1;
	return -1;
}

This results in:

Code: Select all

int fndindex = 0; // Fire Rand Index PSX

static void R_SpreadFirePSX(byte* src1, byte* src2, int pixel, int counter, int* rand)
{
    int randIdx = 0;
    int randIdx2 = 0;
    byte *tmpSrc;
    
    if(pixel != 0) 
    {
		//[GEC] Like PsxDoom
        randIdx = (rndtable[*rand]);
        randIdx2 = (rndtable[*rand+1]);
        *rand = ((*rand+2) & 0xff);
        fndindex = *rand;
        
        tmpSrc = (src1 + (((counter - (randIdx & 3)) + 1) & (FIRESKY_WIDTH-1)));
        
        *(byte*)(tmpSrc - FIRESKY_WIDTH) = pixel - ((randIdx2 & 1));
    }
    else
    {
        *(byte*)(src2 - FIRESKY_WIDTH) = 0;                                                                                                                      
    }
}

 and so it performs the correct sequence.

[spiral]

Some times ago I tried to see if it could be made with shaders; but unfortunately no -- each frame modifies the previous, and while you can access the source image from the shader I don't think you can access the previous render.

Other than that, the code is very simple and as long as you can access the previous frame's output, it's easy. If the texture manager gets exported to ZScript, for example, it could be done simply there.

I have been meaning to do that for a while so I threw together a GLSL port on Shadertoy that works using a backbuffer: https://www.shadertoy.com/view/3sX3W4

It might be cool to have an actual texture pipeline in GLDEFS in order to support this, but doesn't seem worth implementing unless there are other procedural effects people are interested in doing.

[Gez]

The demo on shadertoy doesn't seem to work for me, I get plenty of error messages.

[Nash]

Seems to work for me.

Cool demo, but yeah, unfortunately you don't have access to additional buffers in GZDoom GLSL.

[Graf Zahl]

Cool demo, but yeah, unfortunately you don't have access to additional buffers in GZDoom GLSL.

The big problem here is that we still have to support some ancient GL versions due to too high user share. Right now dumping 3.3 would not be doable which really complicates the shader interface.

[spiral]

The demo on shadertoy doesn't seem to work for me, I get plenty of error messages.

Sorry about that, if you're using an older browser it may not fully support WebGL2.

The big problem here is that we still have to support some ancient GL versions due to too high user share. Right now dumping 3.3 would not be doable which really complicates the shader interface.

It's been maybe a few months since I looked at gzdoom master, is there anything complicating it besides lack of direct state access? I've done this kind of thing in 3.3 before, it's certainly not trivial, but paves the way for allowing arbitrary compositing effects like you would see with a true scene graph.

[Marisa the Magician]

Dynamic textures make renderer optimization a lot more complicated.

Can I take this as a "No" for scripted textures in general or just those that would be done like this, purely on the software side? Because I still plan to make some sort of canvas texture that can be drawn to using the same functions as the ZScript Screen API.

[Graf Zahl]

Scripted textures would mean 'scripting through GLSL'.
Scripting textures through ZScript is too performance intensive, even with a JIT compiler. this is an area where speed is the only thing that matters.

[phantombeta]

Hi.
OH GOD NO, NOT THE HACKS