[Bug 9775] Max Payne 1.05 - Screenshot fails

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=9775





--- Comment #18 from Tobias Jakobi <liquid.acid at 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


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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.