Advice fixing #13683 (DirectX mouse overlay?)

[Christopher Thielen]

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 at 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.
>