http://bugs.winehq.org/show_bug.cgi?id=10229
--- Comment #30 from Alexander Dorofeyev alexd4@inbox.lv 2008-07-18 18:40:14 --- (In reply to comment #29)
Should use d3d8. I don't get any trace output with WINEDEBUG=+d3d7, but a few bits (attaching inline) with +d3d8.
The 3d engine is based on OpenGL though. At least I'm using the GL backend (since TSE there is also a D3D based backend).
(last bits from d3d8) trace:d3d8:IDirect3D8Impl_EnumAdapterModes (0x153068)->(0, 133, 0x32fb34) trace:d3d8:IDirect3D8Impl_GetAdapterIdentifier (0x153068)->(0,00000002, 0x32f498 trace:d3d8:IDirect3D8Impl_Release (0x153068) : ReleaseRef to 0 trace:d3d8:IDirect3D8Impl_Release Releasing wined3d 0x15f810 trace:d3d8:DllMain fdwReason=0
FPU mode change by native d3d must be happening somewhere in IDirect3D8_CreateDevice. So if there is no CreateDevice then d3d fpu messing shouldn't be a factor. But maybe one of versions that were trying to connect was using d3d?