http://bugs.winehq.org/show_bug.cgi?id=9775
--- Comment #26 from Tobias Jakobi liquid.acid@gmx.net 2008-07-02 16:10:26 --- (In reply to comment #25)
(In reply to comment #24)
Wine's implementation of D3D is based on what you can read in the MSDN. If the MSDN is wrong then we should comment that in wine's code.
I'm not sure, but I may guess that clarity may have been the concern. I think a small note in IDirect3DDevice8Impl_CreateImageSurface (something like "creates a surface in sysmem pool. max payne and other games rely on that") will suffice.
The point is not that Max Payne (or other games) rely on that behaviour. The allocation of the surface in SYSMEM pool IS the correct behaviour by definition. That is verified two times: (i) Original DirectX8 SDK documentation (I take the part from the D3D reference as a definition) (ii) testcase run on both XP and Vista (backing up that what DX8 docs says is right)
It's not like we're implementing something that was documented wrong in the first place. The person who implemented IDirect3DDevice8Impl_CreateImageSurface in wine was probably basing his impl on what the DX9 (NINE!) docs state. Presumably because the DX8 docs were not not available any longer.
To sum it up: DX8 docs explained correct behaviour of the method, DX9 docs spread misinformation about the pool type in a short remark.
The rest is "documented" by test. For already implemented and tested Wine code we probably don't want to care too much about what msdn says anyway and give it lots of space (anything on msdn can be altered or removed any time btw, whenever ms deems fit).
Microsoft would break backward compatibility big time if they changed this behaviour now. That applies to large parts of their docs.
Comments in d3d9 that are wrong can be simply deleted, but maybe in different patch.
So if I get this right I create three patches, right? (i) Testcase (ii) Patch to correct behaviour of IDirect3DDevice8Impl_CreateImageSurface (iii) Removal of the faulty comment
And the bulk of my comments why the behaviour is correct and MSDN is wrong, and all this stuff, should go into the testcase patch?
I have an idea Alexander, why don't you hand in the (my) patch? I guess it's going to be applied in no time ;-)
It's more fair if your fix goes in under your name, and it's not like my patches don't ever get delayed or rejected (sigh)...
I couldn't care less who is sending in this patch. I didn't dig into this for the credit, but to get it working (and perhaps a bit of interest in the D3D architecture).
So, I think I'm gonna do a last rewrite (and split) of the patch and post it here, so you (Alexander) can review it. Then I send it to wine-patches and if it's not applied then I leave it to other people to resend it again. I really don't have the nerve to invest this much time in a patch that consists basically of only one changed line of code.
Greets, Tobias