https://bugs.winehq.org/show_bug.cgi?id=38974
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51957|0 |1 is obsolete| |
--- Comment #9 from Matteo Bruni matteo.mystral@gmail.com --- Created attachment 52783 --> https://bugs.winehq.org/attachment.cgi?id=52783 Fix v2
I managed to get around writing some tests for this bug and it turns out that they don't quite give the results I expected. Can you check if the new patch also fixes the bug for you?
A quick explanation of the bug itself: the game uses ID3DDevice9::Clear() to initialize a texture to color (0.5, 0.5, 0.0, 0.0). That texture is then used in the final postprocessing pass as a sort of offset for the rendered scene. In the broken case the SRGBFRAMEBUFFER GL state happens to be enabled at the time of the clear because of the last draw (to a different render target), the texture ends up being cleared with the gamma-corrected color and that results in the smearing visible in the screenshot.
My initial guess was that clears should always ignore the D3DRS_SRGBWRITEENABLE state but my testing shows that's not the case, clears are affected by it. It's pretty weird actually, on the Windows systems I tested (XP and Win7) changes in the render state setting are ignored by clears unless "something" (e.g. a draw) happens in between and switching render targets sometimes also has an effect. The testbot (WARP on Win8 and Win10) seems to give a more sensible behavior though - the state affects the clears without that weirdness.