Gamma-corrected FSAA - what is it?

Thanks again sireric.
Maybe that's why I thought of it as "in the shader". The position it's done is as if it were done in the shader (after texture read, and at the end of the shader), even if it's actually done with an external switch.

Certainly a step forward from how it was done earlier, but I still want a linear buffer with an exponent.


Chalnoth:
RGBe could give a benefit for current titles over sRGB, without any software changes, with no bandwidth costs. So it doesn't need an etheral future game to be useful. And I think it would be simpler hardware too.
 
Basic said:
Chalnoth:
RGBe could give a benefit for current titles over sRGB, without any software changes, with no bandwidth costs. So it doesn't need an etheral future game to be useful. And I think it would be simpler hardware too.
Um, you have to program for HDR/gamma correct rendering for the added precision to be of any use.
 
With a linear frame buffer, you shouldn't have any special gamma correction code. And you could make it as a driver option, "when someone want a sRGB fb (without alpha), use RGBe".

It gives you better precision directly. And you can also store overbright colors in the frame buffer (good if there's intermediate values that are overbright, that then is dimmed down to non-saturated range).

If you want to do tone-mapping, then yes, you'd need special code for it.
 
Just look at the "three fsaa steps" and how the darkest one is way too dark on the nv25 to help much...

gamma_fsaa.png


Thomas
 
tb said:
Just look at the "three fsaa steps" and how the darkest one is way too dark on the nv25 to help much...
On my screen with current settings, the darkest one is way too bright on the R300...
 
Back
Top