Implementation patches for d3drm's CreateDeviceFromD3D.

Stefan Dösinger stefandoesinger at gmail.com
Mon Aug 17 03:57:26 CDT 2015


Hi,

Looks good, except for one thing: our d3d implementation allows querying IDirect3DRMWinDevice or similar. Please test this in the test.

Also you didn't include the GetDirect3DDevice2 patch in the mail. Was that intentional?

Cheers,
Stefan

> Am 16.08.2015 um 13:30 schrieb Aaryaman Vasishta <jem456.vasishta at gmail.com>:
> 
> Here's the device QI patches along with supporting patches to fix d3drm's
> QI behavior on unsupported interfaces.
> 
> 
> Cheers,
> Jam
> 
> On Tue, Aug 11, 2015 at 5:44 PM, Aaryaman Vasishta <
> jem456.vasishta at gmail.com> wrote:
> 
>> I just found an odd behavior while performing that test on windows.
>> 
>> Querying IDirect3DRMDevice2 from IDirect3DRMDevice1, then calling
>> GetDirect3DDevice2 will return DD_OK but the device is set to NULL instead.
>> It just verifies ddraw behavior but at the same time doesn't return an
>> HRESULT error.
>> 
>> 
>> On Tue, Aug 11, 2015 at 1:58 AM, Stefan Dösinger <
>> stefandoesinger at gmail.com> wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>> 
>>> Am 2015-08-10 um 20:41 schrieb Aaryaman Vasishta:
>>>> I've written device QI tests (quick look:
>>>> http://pastebin.com/5bpRizmr need to remove the last boolean flag
>>>> column as it's unnecessary now) and you can query up-down across
>>>> all versions.
>>> The follow-up question is: What happens if you create an
>>> IDirect3DRMDevice via CreateDeviceFromD3D, QI IDirect3DRMDevice2 or 3
>>> from it and then call GetDirect3DDevice2. In plain ddraw you can't get
>>> a device2 from a device1, so I'd expect the d3drm call to fail in some
>>> way.
>>> 
>>> I suspect your way to use QueryInterface in GetDirect3DDevice2 already
>>> implements the right behavior. Please add a test for this somewhere.
>>> 
>>> I think testing this with a d3drm device that was created via
>>> CreateDeviceFromClipper should work too. Your
>>> IDirect3DDevice::QueryInterface(&IID_IDirectDrawSurface) call in the
>>> version 1 test to get the render target shows that the device was
>>> created as a v1 device.
>>> 
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v2
>>> 
>>> iQIcBAEBAgAGBQJVyQmKAAoJEN0/YqbEcdMwFi0P+gIvNUxDgs2Ooqnj54aEF8s6
>>> XK9b0oZ8rVZQ3TviMV/fIPCoMXeCdY8EFKEhEFVTigAVdJda2t84153Lrk+fTx6I
>>> h9DSLmrXh2fpuCvGv0efnGdDScUchdxqcp6M2u+Ha/AA8w+kaDtqqO2NXDHG0bnK
>>> 5YoLT3SH3twbozTHDIaGlGWFIb/97Zw5ZcpdO9qG1ukt6Nlr/7p5kZeXQP+xU4Xk
>>> mATeMx4UPrTyRqCBq4nWirEk3h0SMWZHno+S6CAlYTdMohSvOmivWJAmQpL5YrzD
>>> grVvnMq+vTggqaKvV5d5VtZX82z8JQt1ZTzCLc1OOu+QnOTQsmEgmiycIGK25ngc
>>> eft/41TTVl3Lqipm75frGfyBm5bDe5DL/ELNJKKFvhVHohg/lcjoxONpJXVBCeb5
>>> RnqvLWxeg21h6kU9NYeeNjL7OUiMXyT1vYHmCki7QT5X2eXntJSmmJO3p2eXnrWY
>>> MDHGh1k8/rB5+wrKXyq9AMnPNesBLgBCMnFQGK+oij/FZhAPjEraisoz8qMAy5DZ
>>> EEYUwnLfJdYECQ3ZXNagmJOdecMvgSO9QrBzo1F0psiOdefrZzxdfomsUA8vJ7d7
>>> WkIWLw8ug/OjnOuT7Vr2Mkdy1GTQzkRn+Ih/oEButhNQ6u6IDLftNwBq9gn4hL/K
>>> niROk7IH4pH0DDZZ61Mf
>>> =5hW8
>>> -----END PGP SIGNATURE-----
>>> 
>> 
>> 
> <0001-d3drm-Add-IDirect3DRMObject-to-be-queried-from-IDire.patch><0002-d3drm-Fix-IDirect3DRMDevice3_QueryInterface-returnin.patch><0003-d3drm-tests-Add-QueryInterface-tests-for-IDirect3DRM.patch>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20150817/646e67a0/attachment.sig>


More information about the wine-devel mailing list