[Feature request] Spectre fuzz scaling

[michaeljhkim]

So when using higher resolutions in prboom, the scaling for the fuzz get's so high that they become really invisible. Could you guys add an option to scale up the fuzz so we can see them like we would in chocolate doom?

[JadingTsunami]

You are speaking of only the Software renderer, correct?

[Kappa971]

A similar function would also be useful with OpenGL renderer

[JadingTsunami]

A similar function would also be useful with OpenGL renderer

The OpenGL renderer already has several options for sprite fuzzing which are not affected by resolution. Hence just verifying.

[michaeljhkim]

You are speaking of only the Software renderer, correct?

yes, since I want to play doom in a vanilla fashion

[fabiangreffrath]

Then I'd suggest playing with a lower resolution. The fuzz effect is achieved by shuffling around neighboring pixels, which naturally becomes less visible the smaller the pixels get. We currently don't have a way to make it appear more blocky even for higher resolutions.

[ghost]

Maybe emulating the effect could help, rather than doing it natively? At least it could be a temporary solution until a better method is found.

[Kappa971]

The OpenGL renderer already has several options for sprite fuzzing which are not affected by resolution. Hence just verifying.

It seems to me that none of the OpenGL options emulate the DOS fuzz effect. I think GZDoom has a similar option which works with both software renderings and OpenGL/Vulkan

[JadingTsunami]

The OpenGL renderer already has several options for sprite fuzzing which are not affected by resolution. Hence just verifying.

It seems to me that none of the OpenGL options emulate the DOS fuzz effect.

They don't, but that's a different discussion from what's being asked here. The request here was for resolution-independent sprite fuzzing in the software renderer.

[Kappa971]

They don't, but that's a different discussion from what's being asked here. The request here was for resolution-independent sprite fuzzing in the software renderer.

In reality it was specified later that we were talking about software renderer but also the OpenGL renderer doesn't have this functionality so it seemed to me inherent to the issue. Neither OpenGL nor software render has resolution-independent sprite fuzzing similar to Vanilla Doom.

[JadingTsunami]

Let's not derail the discussion here please -- the issue topic is software renderer sprite fuzz scaling, and @fabiangreffrath has provided an answer.

[Kappa971]

Let's not derail the discussion here please -- the issue topic is software renderer sprite fuzz scaling, and @fabiangreffrath has provided an answer.

If you don't want to make further discussion about it (in my opinion inherent to the issue), you can close the issue. There's no need to be rude, I haven't been.

[fabiangreffrath]

I'll try to explain this with Vanilla code, because the code in Pr+ has been "unified" for different renderers and has become such a clusterfsck that I don't even try to bother around with it. These are the relevant lines in the R_DrawFuzzColumn() function:

https://github.com/chocolate-doom/chocolate-doom/blob/5082a2f1b43736e24e9927c16268788506b3b25b/src/doom/r_draw.c#L316-L329

What this code does is increase the index into the fuzzoffset[] array after each drawn pixel, which for very small pixels means that the blocky appearance gets lost and that the whole areas which was meant to appear "fuzzy" instead appears regularly shaded down on average.

What I think needs to be done: The fuzzpos index needs to get turned into type fixed_t and gradually increased during each step in this loop by the fraction of original and actual vertical resolution. Something like this (untested pseudo code):

fixed_t fuzzpos_fixed = fuzzpos << FRACBITS;
fixed_t fuzzinc = (200 << FRACBITS) / SCREENHEIGHT ;
do 
    {
    *dest = colormaps[6*256+dest[fuzzoffset[fuzzpos_fixed>>FRACBITS]]]; 

    fuzzpos_fixed += fuzzinc;

    while (fuzzpos_fixed >> FRACBITS >= FUZZTABLE) 
        fuzzpos_fixed -= FUZZTABLE << FRACBITS;

    dest += SCREENWIDTH;
    } while (count--); 
fuzzpos = fuzzpos_fixed>>FRACBITS;

However, this is only for the vertical column drawing function. Something similar will have to be applied to the functions calling this function for each horizontal coordinate.

[michaeljhkim]

I'll try to explain this with Vanilla code, because the code in Pr+ has been "unified" for different renderers and has become such a clusterfsck that I don't even try to bother around with it. These are the relevant lines in the R_DrawFuzzColumn() function:

https://github.com/chocolate-doom/chocolate-doom/blob/5082a2f1b43736e24e9927c16268788506b3b25b/src/doom/r_draw.c#L316-L329

What this code does is increase the index into the fuzzoffset[] array after each drawn pixel, which for very small pixels means that the blocky appearance gets lost and that the whole areas which was meant to appear "fuzzy" instead appears regularly shaded down on average.

What I think needs to be done: The fuzzpos index needs to get turned into type fixed_t and gradually increased during each step in this loop by the fraction of original and actual vertical resolution. Something like this (untested pseudo code):

fixed_t fuzzpos_fixed = fuzzpos << FRACBITS;
fixed_t fuzzinc = (200 << FRACBITS) / SCREENHEIGHT ;
do 
    {
  *dest = colormaps[6*256+dest[fuzzoffset[fuzzpos_fixed>>FRACBITS]]]; 

  fuzzpos_fixed += fuzzinc;

  while (fuzzpos_fixed >> FRACBITS >= FUZZTABLE) 
      fuzzpos_fixed -= FUZZTABLE << FRACBITS;

  dest += SCREENWIDTH;
    } while (count--); 
fuzzpos = fuzzpos_fixed>>FRACBITS;

However, this is only for the vertical column drawing function. Something similar will have to be applied to the functions calling this function for each horizontal coordinate.

Could we also just get a slider and we just multiply that by the thing to scale it?