That was exactly the problem - didn't read carefully enough.
Using Wine's D3D9 implementation on Windows XP, the missing cursor _does_ show up, so this Wine bug is likely not a D3D issue.
I did find some old fan-created tools which can extract the resources from the game's proprietary formats.
As there are no failed CreateSurface/CreateTexture calls, I'm assuming the code path never gets to that point.
Any ideas on how to go about debugging the problem of a custom file type not getting loaded? Does Wine implement it's own libc in which one could perhaps trace fread(), etc.? From the fan-made tools, I do have the byte offsets within the proprietary format where the missing cursor should be loaded from.
Also, is there any likely reason why Wine's behavior might differ from Windows on operations which are relatively libc-style operations?
On 3/24/2014 1:14 PM, Stefan Dösinger wrote:
Am 24.03.2014 um 18:53 schrieb Christopher Thielen christopher@thielen.co:
I then tried cross-compiling Wine from Linux using MinGW. I copied over the resulting d3d9.dll and wined3d.dll to the game's directory on Windows XP but it then won't run, complaining:
"The procedure entry point __wine_get_wgl_driver could not be located in the dynamic link library gdi32.dll.“
Did you set CFLAGS=-DUSE_WIN32_OPENGL ? This preprocessor define is needed to make wined3d work on Windows. Otherwise it uses some Wine-specific exports to bypass opengl32.dll for non-WGL calls and calls libGL.so directly for performance reasons.