by Rachael » Wed Oct 31, 2018 2:22 am
I don't know if this problem can be fixed.
What's happening here is the sprites are being drawn in a square. I would not have known it before, but it seems pretty obvious now - it's processing all pixels in that square, even if they're clear - which means that it's pushing them through the RGB666 table and the darkening is what's coming out the other side.
The real kicker is this: First, You have to up the gamma or brightness quite a bit to even see this effect. Second, this IS the 8-bit software renderer - even if it is softpoly. If you really need precise 8-bit colour drawing you can do "gl_tonemap 5" and swap to the truecolour softpoly instead.
In my opinion the only reason to even consider fixing this issue is if it would improve the speed of the softpoly drawers.
I don't know if this problem can be fixed.
What's happening here is the sprites are being drawn in a square. I would not have known it before, but it seems pretty obvious now - it's processing all pixels in that square, even if they're clear - which means that it's pushing them through the RGB666 table and the darkening is what's coming out the other side.
The real kicker is this: First, You have to up the gamma or brightness quite a bit to even see this effect. Second, this IS the 8-bit software renderer - even if it is softpoly. If you really need precise 8-bit colour drawing you can do "gl_tonemap 5" and swap to the truecolour softpoly instead.
In my opinion the only reason to even consider fixing this issue is if it would improve the speed of the softpoly drawers.