Attached is the patches for implementing CreateDeviceFromD3D. Please take a look and provide feedback, if any.
Thank you! Aaryaman
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
They look quite good: One suggestion though: Do you need the separate implementations for IDirect3DRM1 and IDirect3DRM3? It seems that you could thunk d3drm2 and d3drm3 to d3drm1 and work with just one implementation. That works because you don't need a separate way to create the device like you do in the cases where you create the immediate mode device yourself.
Yeah, I know that the thunk direction would be different from the other methods, but I think that's something we can live with. The thunk direction is forced by the IM device QI limitations and thunking is preferred over code duplication if it's possible.
However, there's one thing you need to test first: can you QI IDirect3DRMDevice3 from IDirect3DRMDevice(1)? Or do D3DRM Devices have the same kind of restriction (down-QI'ing only) as IM devices?
Cheers, Stefan
Am 2015-08-08 um 00:20 schrieb Aaryaman Vasishta:
Attached is the patches for implementing CreateDeviceFromD3D. Please take a look and provide feedback, if any.
Thank you! Aaryaman
However, there's one thing you need to test first: can you QI IDirect3DRMDevice3 from IDirect3DRMDevice(1)? Or do D3DRM Devices have the same kind of restriction (down-QI'ing only) as IM devices?
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. Now that I know that thunks are preferred, I'll do just that and reply with the changes here as soon as I can.
Cheers, Jam
-----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.
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@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-----
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@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@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-----
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@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@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@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>
Also you didn't include the GetDirect3DDevice2 patch in the mail. Was that intentional?
I'm a bit confused. That patch is already there over at wine-patches with the implementation patches, wheras these 3 patches just work on QI and tests for it. Is the GetDirect3DDevice2 patch required here for building?
I realized you were talking about the GetDirect3DDevice2 fix which came after the implementation patches, I had forgotten to include that, my bad. I've attached them in this email.
Cheers, Jam
On Mon, Aug 17, 2015 at 3:54 PM, Aaryaman Vasishta < jem456.vasishta@gmail.com> wrote:
Also you didn't include the GetDirect3DDevice2 patch in the mail. Was that intentional?
I'm a bit confused. That patch is already there over at wine-patches with the implementation patches, wheras these 3 patches just work on QI and tests for it. Is the GetDirect3DDevice2 patch required here for building?
-
Aaryaman Vasishta -
Stefan Dösinger