http://bugs.winehq.org/show_bug.cgi?id=9775
--- Comment #18 from Tobias Jakobi liquid.acid@gmx.net 2008-06-14 20:39:18 --- (In reply to comment #17)
Hmm. Are you aware you can build test executables for Windows under Linux? For ddraw and d3d tests at least it works great. If Wine's configure detects presence of mingw, then say "cd dlls/d3d8/tests; make crosstest" gives you a nice individual dll test executable (d3d8_crosstest.exe).
Yep, I know about crosscompiling. That's the first thing I tried. But somehow it didn't work really well (maybe because the host system is 64bit one?). I didn't investigate this further and tried next a mingw installation on my vm. Turned out that mingw wasn't really happy with the DX8.1 sdk, or vice versa? Next I tried vctoolkit and failed at installation. The 2008 version has win 2k support dropped, so I had to get the 2005 version, which works now. The recent platform SDK also doesn't work with w2k, but the 2003 version does the trick
I'm going to investigate the crosscompile problem if I find some free time. Currently the vctoolkit setup on my vm works for me, so at least I have possibility to build windows EXEs.
"The Direct3D9 documentation incorrectly states that CreateImageSurface returns a surface object with D3DPOOL_SCRATCH configuration."
Maybe I'm missing something, but this reasoning seems a bit suspect.Do you know for sure that D3D9 docs really are wrong, or maybe there just is a differences between d3d8 and d3d9 in this thing?
Direct3D9 doesn't even have a CreateImageSurface method anymore. According to the MSDN docs the method was renamed to CreateOffscreenPlainSurface. Again that's not entirely correct. The method isn't simply renamed, they also added the pool type parameter, which was somehow "hardcoded" in CreateImageSurface.
The wrong statement is "D3DPOOL_SCRATCH will return a surface that has identical characteristics to a surface created by IDirect3DDevice8::CreateImageSurface". That can't be correct. The D3DPOOL_X flag meaning hasn't change between DX8 and DX9. D3DPOOL_SYSTEMMEM hasn't miraculously become D3DPOOL_SCRATCH. DX8.1 sdk docs states that the surface pool type returned by CreateImageSurface is D3DPOOL_SCRATCH. Tests on WinXP verify this behaviour. D3D9 can't change that behaviour because D3DPOOL_SCRATCH and D3DPOOL_SYSTEMMEM are not "compatible".
It would be ideal to add a
similar test for d3d9. Then you can change pool parameter in d3d8 and submit the patch with this stuff. Since it's simple, clear and tested and fixes a bug it should be accepted. Nice research :).
Nothing to test then for D3D9 I think. :-)
Oh, one note about the test though, in case of test failures it's best to print all relevant values, not just state what is implied by failure anyway. E.g. if you test surf_desc.Pool == D3DPOOL_SYSTEMMEM, then it's best to print something like "surf_desc.Pool was %u instead of D3DPOOL_SYSTEMMEM" or "unexpected memory pool: %u". It's recommended in test writing docs IIRC, and it makes debugging test failures (if they happen) easier to debug.
Gonna change that!
Greets, Tobias