Advice fixing #13683 (DirectX mouse overlay?)

[Christopher Thielen]

I should clarify as per Stefan Dösinger's comments that I have only been 
using the gog.com version (both under Wine and in my testing so far 
under Windows XP) so the nGlide wrapper code paths should be the same. 
The original, non-gog.com version is more or less garbage due to some 
CD-ROM driver DRM-trickery.

Erich Hoover suggested to look at WINEDEBUG=+cursor,+icon,+resource and 
see if the game is merely using 'traditional' cursors. I do know this 
game was in development for quite a while and originally started out as 
a Glide game, so it makes some sense that the DirectX ShowCursor stuff 
might not be used at all. I tried TRACE'ing d3d8_device,d3d9_device,and 
dinput but found no calls related to cursors.

The WINEDEBUG=+cursor,+icon,+resource trace does appear to be onto 
something though. I attached the log to the bug but here are some snippets:

trace:icon:ICO_LoadIcon 0x360000 0x360086
trace:cursor:CreateIconFromResourceEx 0x37dc22 (1128 bytes), ver 
00030000, 32x32 icon
trace:cursor:ungrab_clipping_window no longer clipping
trace:icon:DrawIconEx 
(hdc=0x2002d,pos=23.4,hicon=0x10044,extend=32.32,istep=0,br=(nil),flags=0x0000000b)
trace:resource:LdrFindResource_U module 0x7e920000 type #0018 name #0002 
lang 0000 level 3
trace:resource:find_entry_by_id root 0x7e93f3b4 dir 0x7e93f3b4 id 0018 
not found
trace:cursor:LoadCursorW (nil), #7f00
trace:resource:LoadImageW ((nil),#7f00,2,0,0,0x00008040)
trace:cursor:CURSORICON_Load (nil), #7f00, 0x0, depth 32, fCursor 1, 
flags 0x8040

In particular, when the user presses 'Q', it should toggle the cursor 
icon. Here is the log grepped for "cursor:LoadIconW":

trace:cursor:LoadIconW (nil), #7f05
trace:cursor:LoadIconW (nil), #7f05
trace:cursor:LoadIconW 0x7edb0000, L""
trace:cursor:LoadIconW (nil), L""
trace:cursor:LoadIconW (nil), #7f05
trace:cursor:LoadIconW 0x7edf0000, #0001
trace:cursor:LoadIconW 0x7edb0000, #0001
trace:cursor:LoadIconW (nil), #7f05
trace:cursor:LoadIconW (nil), #7f00
trace:cursor:LoadIconW (nil), #7f00

Am I wrong in reading this as the game toggling between two cursors? Is 
there a way to dump the ICO resource from LoadIconW to the file system 
to debug which icons it is trying and/or failing to load?

Thanks again to everybody for all your help so far,
Christopher Thielen

On 02/16/2014 11:55 AM, Stefan Dösinger wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am 2014-02-16 20:39, schrieb Christopher Thielen:
>> fixme:d3d:wined3d_debug_location Unrecognized location flag(s)
>> 0xfffffc00.
> These lines are harmless. That's pretty much code doing something like
> this
>
> TRACE("Removing flags %s.\n",
> wined3d_debug_location(~WINED3D_LOCATION_SYSMEM);
>
> which ends up passing a value like 0xfffffffe to wined3d_debug_location.
>
> wined3d_debug_location then does something like
>
> if (flags & (SYSMEM | BUFFER | ALL | DEFINED | FLAGS))
>      FIXME("Unrecognized location flag(s) %#x.\n", flags);
>
> What is missing here is a logical and that filters out unknown flags in
> places where a bitwise not is used, or maybe just the removal of the
> unknown flags fixme in wined3d_debug_location.
>
>> Unfortunately, there is no reference to "ddraw7_GetCaps" or
>> "GetCaps" anywhere in the 975 MB log. That confirms it isn't using
>> overlays, right?
> Pretty much, yeah.
>
>> fixme:d3d:debug_d3dusage Unrecognized usage flag(s) 0x10000000
> That's WINED3DUSAGE_TEXTURE and needs to be added to the debug function.
>
>> This gog.com version uses nGlide to wrap the Glide API to DirectX
>> calls - DX9 I believe, based on the requirements of nGlide
>> (http://www.zeus-software.com/downloads/nglide). Not sure if this
>> information helps.
> This means the GOG version is using an entirely different codepath
> than what you're trying to run. It is quite possible that the codepath
> you're running is broken in some way. I recommend to test if the
> game's ddraw codepath is working properly on Windows before you bang
> your head against it. It can save you a lot of time :-) .
>
> If it turns out that the ddraw codepath is working just fine on
> Windows 7 there's certainly value in fixing it. If it is not, but it
> is working on e.g. Windows XP, it might still be worth a look.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJTARfAAAoJEN0/YqbEcdMwSC0P/1iZxKSLjIqEXeDmPsy7ARU9
> vWm0Uqo0SYdCAEemGA2vD53IuojRUyMZ9E0ikfCZ7qlVK7uaFs54TtiY15C+p6ic
> gZhNezdyt/6idLootvCsJ9ZDoSaFdIDvoWga7JThwlZnfGVVZIGj6WeJeTV+rXon
> QHkQO/jghlHpgZIT6mdicvsltaWujg+Idwfuz1Z8i8+fKEhy7Uvp+QKCqsF8JdNf
> AuDceOPwF8aaH0YWVieyQfTiqzv4RHTnF5i+LGWPx61SRuRXi2YT+2hHlTbspua2
> 6/FfQ+c2P6eoI39UiRysWL8+zB+T0o5V0JOF2PD5EJGqc+vP4066XkxZlA7Kdl6W
> h8RCzDbU+gxeq49cXHTG6AbvLUdkbDowo/dwW6x4wOmnlzZBW5CNxF0NbQ0Jf4sW
> mQLynduNdejnqgwZSFb5m8AoTqCZ+XbLkGq5uPAcAz6TIlsrKW7oQ41rTkeLxpU/
> Z5nlLDmC5MIP8t8he2KuLu8eVrLhSsxYFEyeevhHY/SvNkmi1LxkXJMQHt8gDpdi
> 3ZW+LuW5nsOJ/9T7vH27ENorqRNtpFWnpdwPMyBgQJbPlNCYVp5ZTKE8WHpk+fk4
> T+LzzbOlli8svOLHll4rmDhD89qYiQQUWNv7V7XjTHrgrxpZFY5aLXrprEGTc6Kc
> PCO4omr8MIkjrtJAHfKX
> =evKW
> -----END PGP SIGNATURE-----
>