Page 1 of 3

PSX Flaming Sky

PostPosted: Sun Dec 30, 2018 7:05 am
by 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.

Re: PSX Flaming Sky

PostPosted: Sun Dec 30, 2018 7:23 am
by 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.

Re: PSX Flaming Sky

PostPosted: Sun Dec 30, 2018 12:50 pm
by 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.

Re: PSX Flaming Sky

PostPosted: Mon Dec 31, 2018 2:25 pm
by Hellser
I don't think it has to be correct, but rather seems similar to.

Re: PSX Flaming Sky

PostPosted: Mon Dec 31, 2018 2:34 pm
by 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.

Re: PSX Flaming Sky

PostPosted: Mon Dec 31, 2018 3:41 pm
by 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.

Re: PSX Flaming Sky

PostPosted: Mon Dec 31, 2018 5:33 pm
by Erick194
Hellser wrote: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 allExpand view
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 allExpand view
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.

Re: PSX Flaming Sky

PostPosted: Mon Dec 31, 2018 11:48 pm
by spiral
Gez wrote: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.

Re: PSX Flaming Sky

PostPosted: Tue Jan 01, 2019 5:28 am
by Gez
The demo on shadertoy doesn't seem to work for me, I get plenty of error messages.

Image

Re: PSX Flaming Sky

PostPosted: Tue Jan 01, 2019 5:32 am
by Nash


Seems to work for me.

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

Re: PSX Flaming Sky

PostPosted: Tue Jan 01, 2019 7:01 am
by Graf Zahl
Nash wrote: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.

Re: PSX Flaming Sky

PostPosted: Tue Jan 01, 2019 6:34 pm
by spiral
Gez wrote: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.

Graf Zahl wrote: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.

Re: PSX Flaming Sky

PostPosted: Wed Jan 02, 2019 8:20 am
by Marisa Kirisame
Graf Zahl wrote: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.

Re: PSX Flaming Sky

PostPosted: Wed Jan 02, 2019 8:35 am
by 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.

Re: PSX Flaming Sky

PostPosted: Wed Jan 02, 2019 11:45 am
by phantombeta