I've just removed sRGB support from the engine.
Ye haven't an arm, ye haven't a leg, hurroo, hurrooI'm deeply saddened to see it go, but in the end the deciding factor was that it just did not play nice with alpha blending. The underwater polyblend was one example, but there were others.
Ye haven't an arm, ye haven't a leg, hurroo, hurroo
Ye haven't an arm, ye haven't a leg
Ye're an armless, boneless, chickenless egg
Ye'll be having to put a bowl to beg
Oh Johnny I hardly knew ye.
The D3D SDK says it all:
Ideally, hardware should perform the frame buffer blending operations in the linear space, but hardware is allowed to perform it after the pixel shader but before the frame buffer blender. This means that the frame buffer blending operations that take place in sRGB space will produce incorrect results.In other words, the end results can vary from driver to driver, and D3D allows this to happen as "correct operation".
There are a number of possible options now:
- Switch between sRGB and linear colour space as required, i.e. switch back to linear before performing any blending operations, then back to sRGB when finished. I've already tried this and the impact on framerate is horrendous.
- Bake sRGB translation into the textures at load time, probably the easiest method, but siwtching sRGB on or off would then require a vid_restart. The visual quality would be inferior too, but I suspect not that much so.
- Add a lookup to every pixel shader to do the translation. Not so certain that I like the idea of this one, as once again performance would suffer and anyone who wanted to use their own custom shaders would also have to support it.
- Accept the frame rate loss and do the state switching as required. This is just included for completeness sake: it's not even close to the table for consideration.
0 comments:
Post a Comment