http://bugs.winehq.org/show_bug.cgi?id=10124
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefandoesinger@gmx.at Summary|Some apps (for excample: |Turok doesn't see D3D |game "Turok") don't see D3D |Compatible Adapter. |Compatible Adapter. |
--- Comment #6 from Stefan Dösinger stefandoesinger@gmx.at 2008-03-10 04:07:53 --- Even though more games may be affected by that we have to debug them separately. Those capability flag issues tend to be a per-game issue, where each game has its own problems. So we need separate bug reports for different games.
What happens most of the time is that the game sees our advertised D3D renderer, asks for its capabilities and decides that the caps do not meet its requirements. Quite often this doesn't happen due to rational reason but is rather a bug in the game, which assumes that specific caps are set or not set, which happened to be true on the Windows drivers that were current when the game shipped, and later drivers use a game specific workaround. For example, the game Rollcage breaks if D3DPTEXTURECAPS_POW2 is not set. This cap is a *restriction* flag, if it is set the device can do less than if it is not set. Rejecting a renderer without this flag on the grounds of missing features defies all logic. (The Rollcage problem was confirmed with the reference rasterizer on Windows)
There are two ways to debug this. One is to look for GetCaps / GetDeviceCaps or EnumDevices calls(ddraw, d3d7 logs), and read the game's assembly code to find out what the game requires. The other way is to get a dump of the caps a Windows driver that works with the game, and change the Wine code to hardcode those flags, then see if the game works. If it does, try to go back to the original wine caps step by step, trying to find which cap the game wants (not) to be set.