I still haven't figured this bug out yet but Erich Hoover's help I've at least determined the missing cursor is not loaded from a resource in the .exe.
I ported an Allegro-based fan tool somebody wrote in 2000 to Linux+SDL and have determined that the missing cursor is loaded from a resource file in the game's static/bitmap.flx file.
Two questions: 1) Is there a way to add timestamps to the TRACE statements in Wine? 2) If I know which file is opened by the game, is there a way to debug from that point on, i.e. capture the fopen() and enable +cursor,+resource,+d3d TRACES for say, only 5 seconds after that point? Something along those lines?
I can find the exact offset within the data file used to load the missing resource - but I'd need a way to know when a fread() was that far along. I figure if I can determine that I can determine if the cursor is loaded as a Windows cursor or as a D3D surface and go from there.
Any ideas?
- Christopher Thielen
On 02/17/2014 12:27 PM, Christopher Thielen wrote:
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-----