[PATCH] d3drm: CreateDevice is unimplemented on Windows.

[Aaryaman Vasishta]

On Mon, May 27, 2019 at 12:43 AM Jeff Smith <whydoubt at gmail.com> wrote:

>
>
> On Sun, May 26, 2019, 9:26 AM Aaryaman Vasishta <jem456.vasishta at gmail.com>
> wrote:
>
>>
>> On Sun, May 26, 2019 at 10:13 PM Stefan Dösinger <
>> stefandoesinger at gmail.com> wrote:
>>
>>> Am 24.05.19 um 20:28 schrieb Jeff Smith:
>>> > I found it very odd myself, but I could not find a way to make it do
>>> > anything else, and the only documentation I found on the method just
>>> > says "Not implemented on the Windows platform."
>>> If I remember right when mentoring Aaryaman's GSoC project it only
>>> succeeded for an RGB device or something along those lines. It is quite
>>> possible though that CreateDevice fails while other ways (like
>>> CreateDeviceFromSurface, CreateDeviceFromD3D etc) succeed. This could be
>>> caused by d3drm trying to create a surface that's not supported on
>>> "modern" ddraw drivers for some reason.
>>>
>>> The interesting platform to test d3drm stuff would be Windows 9.x, and
>>> maybe Windows 2000/XP. The DLL got removed from Vista, and only ancient
>>> games use it.
>>>
>>> The interesting thing is that the tests are passing in 2000/XP as well.
>> I don't specifically remember why we skipped implementing CreateDevice
>> earlier. I'll reply here if I do get more details about that.
>>
>> By the way, which bug is CreateDevice related to?
>>
>
> I just ran across this when developing test code for other parts of d3drm
> that I am looking to implement.
>

I see. That's good to hear :) I'm glad to see more patches coming in for
d3drm ^^

It would be interesting to have a test which checks how CreateDevice reacts
when you pass a &device which was already created elsewhere (e.g., by
CreateDeviceFromSurface/Clipper).

FWIW, I don't recall exactly how CreateDevice worked, but one way to find
out its success case is by looking at d3drm documentation which is included
in DX1-7 SDK.
I currently lost my copy, but it seems like somebody had uploaded it in
archive.org, so it may be worth checking. I'll probably take a look at it
by next week, as this week is quite busy for me.
Another way is to run wine with TRACE on games that use d3drm. A useful
trick is to search for bugs related to d3drm and see if any of the
applications mentioned in the bug uses this method.



Cheers,
Aaryaman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20190527/259022ae/attachment-0001.html>