RFC - d3d9: Return success for UnlockRect attempts on already unlocked surfaces
stefandoesinger at gmail.com
Mon Oct 12 03:46:50 CDT 2015
-----BEGIN PGP SIGNED MESSAGE-----
Am 2015-10-11 um 18:36 schrieb Bruno Jesus:
> - switch(hr)
> + if (hr == WINEDDERR_NOTLOCKED)
> - case WINEDDERR_NOTLOCKED: return D3DERR_INVALIDCALL;
> - default: return hr;
> + TRACE("surface was not locked!\n");
> + hr = S_OK;
Buffers already behave like this, but I believe we have a test that
shows surfaces and textures behave differently.
Either way what we need is a test for all d3d versions, from
dlls/ddraw/tests/ddraw1.c to d3d11. If all of them behave in the same
way we can return WINED3D_OK in wined3d, otherwise we'll have to catch
this in the client library.
I vaguely remember that there was some difference between
IDirect3DTexture9_LockRect and IDirect3DSurface9_LockRect on a surface
that was retrieved from that texture. It's also possible that there's a
difference between stand-alone surfaces and textures, and / or different
> Hi all, this is an attempt to fix bug 28874 . The tests  run
> fine up to Windows 8, which unfortunately introduced a change in the
> behavior so I'm not sure how to handle this (broken?).
So Windows <= 7 have the behavior the game expects, whereas Windows 8
and 10 have a different behavior? Yeah, in this case accept the 8+
behavior as broken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
-----END PGP SIGNATURE-----
More information about the wine-devel