[Bug 59693] New: Direct3DMaterial3::SetMaterial does not update the active material
http://bugs.winehq.org/show_bug.cgi?id=59693 Bug ID: 59693 Summary: Direct3DMaterial3::SetMaterial does not update the active material Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs@list.winehq.org Reporter: winehq@tiger.wah.net.au Distribution: --- The current implementation of Direct3DMaterial <= 3 does not directly update the render state on SetMaterial. Only a call of Direct3DDevice3::SetLightState(D3DLIGHTSTATE_MATERIAL) updates the active material properties. This differs from the behaviour on Windows: at least for Direct3DMaterial3, you can call SetLightState(D3DLIGHTSTATE_MATERIAL) once with the material, and then just call SetMaterial on the material itself to change the properties for each batch of primitives. This is visible in the game "I've Got Some BALLS", which uses this pattern of a single SetLightState followed by many SetMaterial/primitive batches. Under Wine, all primitives are rendered with the material values that were present at the SetLightState call, which happen to have a diffuse colour of 1,0,0 so everything is red. Under Windows (tested most recently on Server 2022) this renders correctly in full colour and with specular, etc changing as well. I'm sorry I haven't got a stand-alone test case, and the game itself has what I think is a lifetime bug which causes it to crash on both Wine and newer Windows - a fixed version is available here: https://codeberg.org/abrasive/IveGotSomeBalls-patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59693 --- Comment #1 from abrasive <winehq@tiger.wah.net.au> --- Created attachment 80808 --> http://bugs.winehq.org/attachment.cgi?id=80808 apitrace log of ddraw calls on Windows Server 2022 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59693 --- Comment #2 from abrasive <winehq@tiger.wah.net.au> --- Created attachment 80809 --> http://bugs.winehq.org/attachment.cgi?id=80809 Crude patch for the issue This patch resolves the behaviour. However, it doesn't handle the case where someone uses the same material with different devices at the same time, I'm really not sure how to handle that well? And nor does it handle the case of the material outliving the device. Perhaps it would be neater to check on the device side at primitive time whether the material has changed? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59693 abrasive <winehq@tiger.wah.net.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #80809|0 |1 is obsolete| | --- Comment #3 from abrasive <winehq@tiger.wah.net.au> --- Created attachment 80810 --> http://bugs.winehq.org/attachment.cgi?id=80810 Updated patch resolving behaviour I had some time so I checked the docs for DX3 (Direct3DMaterial), DX5 (Material2) and DX6 (Material3) and the docs for ::GetHandle in each instance say "A material can be used by only one device at a time.", so that isn't an issue. Attached patch is updated to remove the d3d_device pointer from the d3d_material if the material is still around when the device is destroyed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59693 --- Comment #4 from abrasive <winehq@tiger.wah.net.au> --- Created attachment 80811 --> http://bugs.winehq.org/attachment.cgi?id=80811 "I've Got Some BALLS" game w/ bugfix patches I've added a workaround to the game patch to get it working correctly under Wine, so I'm attaching the last revision before that as a testcase. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla