I was able to find the frame and exact call which draws the cursor under the Windows XP code paths: it's drawn toward the end of the frame in two DrawPrimitiveUP calls.
I ran into trouble tracing the Wine codepaths for the same:
I first tried running the Win32 version of apitrace under Wine. It runs successfully but never generates a .trace file, even when I specify --output. If I ask it to run a program which doesn't load d3d9.dll, it emits a warning saying as much, so I know it's running. Anyone have success running the Win32 version of apitrace under Wine and getting a .trace file?
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."
So I tried copying over Wine's cross-compiled gdi32.dll but the message doesn't change. My guess is you cannot locally override gdi32? Should __wine_get_wgl_driver be in gdi32? Any idea how I can get the game to launch using Wine's DLLs?
I also have the Wine codepath OpenGL trace (from the Linux version of apitrace, tracing Wine) in which I've identified the frame but not the calls yet, so I cannot say if the texture is loaded correctly under Wine's codepaths or not yet.
On 3/21/2014 9:10 AM, Matteo Bruni wrote:
2014-03-21 10:14 GMT+01:00 Stefan Dösinger stefandoesinger@gmail.com:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 2014-03-21 03:24, schrieb Christopher Thielen:
apitrace is really neat, thanks for pointing it out. I ran it on Windows XP with the Ultima IX (GOG edition) and generated a trace - which shows the missing mouse cursor - then rebooted into Linux and ran the Windows version of apitrace's GUI using the same .trace file and it _did_ also show the mouse cursor, running under Wine.
It means one thing for sure: The cursor is not a user32 cursor. Otherwise it would not show up in the captures.
I have two theories: Either the game looks at the d3d capabilities (CheckDeviceFormat, GetDeviceCaps, mostly IDirect3D9 methods) and concludes that something is missing, enters a bad codepath and does not draw the pointer.
Or some function unrelated to d3d does not work and the game fails to read the pointer from its resources.
Since this is a glide application running through a glide wrapper the second case is much more likely. (Unless my memory is completely broken)
You can compile wined3d for Windows. The basic idea is to set CFLAGS=-DUSE_WIN32_OPENGL and compile it with mingw on Windows, or Cross-Compile it from Linux. I also have a hacky Visual Studio 2013 based build setup, but you'll have a hard time generating a binary that works on Windows XP with that. With a Win32 build of wined3d.dll and our d3d9.dll you can run the game on Windows with our d3d code. If the pointer shows up in that case this demonstrates that it is not a d3d issue. If it does not, it shows that the issue is a capability flag problem.
Also, I don't know apitrace that well, but is the per-frame 'texture' tab only showing textures utilized in that frame, not counting anything already in the framebuffer? I couldn't find the cursor texture after looking at about two dozen frames, but then again, I didn't find most textures using that method.
No idea :-(
I never used apitrace on D3D traces, I assume it works in the same fashion as on GL ones. The 'texture' tab shows the textures bound to the texture units at that point in time, each one of them might or might not be used by the draw call you're examining. You should check the shaders (or the state of the fixed function pipeline, if no shaders are bound) to know which of those textures are actually used by the draw you're looking into.
What you can do at this point is to go through the draw calls of a frame, looking for the one which draws the cursor (I would do that just by looking at the framebuffer contents). Then run the game in Wine + apitrace and see if you can find the same draw in the GL trace. Either the draw is there, in which case you can look into why it doesn't draw anything, or the call is totally missing, which would support the hypothesis of the bad caps / wrong game codepath.