https://bugs.winehq.org/show_bug.cgi?id=37711
Bug ID: 37711 Summary: payday 2 broken lighting Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: davyaxel@free.fr Distribution: ---
On wine/radeonsi, payday 2 has broken lighting, and objects have no shadows. This doesn't make the game unplayable. It's just objects have no shadows. Gallium Nine has light working.
While trying to fix a bug with Gallium Nine textures of some parts of the road, I tested different configuration of input channels / default values for empty channels for the textures used by the game.
In particular for depth stencil formats, like D3DFMT_D24S8 used by the game, we have the depth on r, the stencil on g, and b=0 a=1
I don't remember what different combinations I tried for this format, but basically when different from that, I got broken lights exactly like wine.
Which makes me think wine probably doesn't handle this format correctly.
If you want to reproduce we have a server with the trace (too big to put here - taken with apitrace), come on our channel (#d3d9) to ask for access.
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #1 from Henri Verbeet hverbeet@gmail.com --- (In reply to Axel D from comment #0)
In particular for depth stencil formats, like D3DFMT_D24S8 used by the game, we have the depth on r, the stencil on g, and b=0 a=1
I don't remember what different combinations I tried for this format, but basically when different from that, I got broken lights exactly like wine.
Depth on R and stencil on G sounds suspicious, since D3DFMT_D24S8 is supposed to be a "shadow format" and supposed to return the result of the depth comparison (provided the format is supported at all for texturing) on R, while plenty of hardware that supported D3DFMT_D24S8 for texturing couldn't read stencil values at all.
Returning 1.0f for A on the other hand is likely correct, since many other formats behave like that in D3D, and Wine does indeed not handle those quite correctly.
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #2 from Axel D davyaxel@free.fr --- if depth on R and stencil on G sounds suspicious, what else do you suggest ?
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #3 from Henri Verbeet hverbeet@gmail.com --- I'd expect it to return the result of the depth compare on R, and 0, 0, 1 for GBA.
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #4 from Axel D davyaxel@free.fr --- This game seems to only look at the r component.
According to some docs, I found out that stencil should be empty as you said.
I haven't found though what are supposed to be the default values of the other components.
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #5 from Axel D davyaxel@free.fr --- Ok, now we discovered something else.
When render target is D3DFMT_NULL, the size of the rendering shouldn't be restricted to the render target size, but to the depth buffer size.
Doing it wrong also breaks shadows on payday2. Perhaps it's the problem wine hits ?
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #6 from Henri Verbeet hverbeet@gmail.com --- (In reply to Axel D from comment #5)
Ok, now we discovered something else.
When render target is D3DFMT_NULL, the size of the rendering shouldn't be restricted to the render target size, but to the depth buffer size.
Doing it wrong also breaks shadows on payday2. Perhaps it's the problem wine hits ?
Sounds plausible enough. You wouldn't happen to have a test case by any chance?
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #7 from Axel D davyaxel@free.fr --- Someone made a quick test application on windows to test several things we wanted to know, including the link between render target size, depth buffer size and rendering. We verified that D3DFMT_NULL changes the behaviour and makes the rendering happen on the whole depth buffer, whereas else it is limited to the render target size.
That said, it would be better have a proper wine test, but we haven't any (and won't have time in the near future for that).
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #8 from Ken Sharp imwellcushtymelike@gmail.com --- What version of Wine?
https://bugs.winehq.org/show_bug.cgi?id=37711
mexahotabop@w1l.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mexahotabop@w1l.ru
https://bugs.winehq.org/show_bug.cgi?id=37711
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr --- Still a bug in current wine (3.11) ?
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #10 from joaopa jeremielapuree@yahoo.fr --- No download. No news from the OP since 5 years. Can an administrator close this bug as ABANDONED?
https://bugs.winehq.org/show_bug.cgi?id=37711
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |ABANDONED Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Ken Sharp imwellcushtymelike@gmail.com --- Abandoned.
https://bugs.winehq.org/show_bug.cgi?id=37711
--- Comment #12 from Austin English austinenglish@gmail.com --- Closing.
https://bugs.winehq.org/show_bug.cgi?id=37711
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Austin English austinenglish@gmail.com --- Actually closing.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla