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