Hi,
I've been tracking down the reason for bug 7993 ( http://bugs.winehq.org/show_bug.cgi?id=7993 , "Delta Force Land Warrior 1.31 -> Can't find 3D Video Card" ), and I think I've found it.
It appears as if the EnumDevices callback in Delta Force for some reason discards all devices with a GUID of IID_IDirect3DTnLHalDevice, thus discarding the only device enumerated by wine. This is "easily" checked (and bypassed) by searching for and altering the IID_IDirect3DTnLHalDevice value used in the check (78 9E 04 F5 (..) ) in the delta force executable.
While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine.
Fixing this together with applying (or otherwise fixing the issue highlighted in) the patch at http://flodaby.ath.cx/~david/0001-ddraw-fix-cases-where-desc2.u2.dwMipMapCou... (also sent to wine-patches), would enable both Delta Force Land Warrior and Delta Force Task Force Dagger to run great with wine.
David
(Resending mail after subscribing to list)
Hi,
I've been tracking down the reason for bug 7993 ( http://bugs.winehq.org/show_bug.cgi?id=7993 , "Delta Force Land Warrior 1.31 -> Can't find 3D Video Card" ), and I think I've found it.
It appears as if the EnumDevices callback in Delta Force for some reason discards all devices with a GUID of IID_IDirect3DTnLHalDevice, thus discarding the only device enumerated by wine. This is "easily" checked (and bypassed) by searching for and altering the IID_IDirect3DTnLHalDevice value used in the check (78 9E 04 F5 (..) ) in the delta force executable.
While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine.
Fixing this together with applying (or otherwise fixing the issue highlighted in) the patch at http://flodaby.ath.cx/~david/0001-ddraw-fix-cases-where-desc2.u2.dwMipMapCou... (also sent to wine-patches), would enable both Delta Force Land Warrior and Delta Force Task Force Dagger to run great with wine.
David
Am Sonntag, 2. September 2007 14:15 schrieb David Hedberg:
While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine.
It is quite likely that windows enumerates more than one device, but you have to keep an eye on the direct3d interface version. IDirect3D1 enumerates other devices than IDirect3D7, which is pretty tricky. IDirect3D7 only has HAL and TnLHal I think, others have HAL, TnLHal, MMX, RGB, Ramp. IDirect3D (1) does NOT enumerate the REF device.
What you could do is to add a test in dlls/ddraw/tests/d3d.c for this. The test could enumerate the devices, and verify that if the TnlHal device is enumerated, HAL is enumerated too, or something like that, depending on what Windows really does.
You've run into a pretty nasty and long-lasting problem here, a game that breaks with certain advertized or not advertized capabilities.
I've implemented a small test here, but to be honest I'm not really sure what to test for :)
The current test only tests what the game in question seems to rely on, which is that TnLHalDevice should never be the only device enumerated by IDirect3D7_EnumDevices.
In addition to this, I think it's "reasonably possible" to make two additional assumptions, which is that RGBDevice is always and enumerated, and that if there is a TnlHal device, a Hal device is also present. Should I add such tests based on my assumptions (and limited test runs) only?
Thanks, David
On 9/2/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Sonntag, 2. September 2007 14:15 schrieb David Hedberg:
While this works as a "fix", it's obviously not a good one. In my (somewhat limited and at the moment not doublechecked) understanding, windows "always" returns (at least) two devices, one reporting T&L capable and one not. So I am wondering how one would implement a proper fix for this in wine.
It is quite likely that windows enumerates more than one device, but you have to keep an eye on the direct3d interface version. IDirect3D1 enumerates other devices than IDirect3D7, which is pretty tricky. IDirect3D7 only has HAL and TnLHal I think, others have HAL, TnLHal, MMX, RGB, Ramp. IDirect3D (1) does NOT enumerate the REF device.
What you could do is to add a test in dlls/ddraw/tests/d3d.c for this. The test could enumerate the devices, and verify that if the TnlHal device is enumerated, HAL is enumerated too, or something like that, depending on what Windows really does.
You've run into a pretty nasty and long-lasting problem here, a game that breaks with certain advertized or not advertized capabilities.
Am Mittwoch, 5. September 2007 17:05:19 schrieb David Hedberg:
I've implemented a small test here, but to be honest I'm not really sure what to test for :)
The current test only tests what the game in question seems to rely on, which is that TnLHalDevice should never be the only device enumerated by IDirect3D7_EnumDevices.
In addition to this, I think it's "reasonably possible" to make two additional assumptions, which is that RGBDevice is always and enumerated, and that if there is a TnlHal device, a Hal device is also present. Should I add such tests based on my assumptions (and limited test runs) only?
Your test so far looks good, but I think your two additional assumptions sound sane too. You could extend your test with them and post the test on wine-devel, asking people to run it on different Windows drivers. Or just send them to wine-patches, there are automatic tests, if your tests fail we'll see that on the result pages.
-
David Hedberg -
Stefan Dösinger