[Bug 55149] New: Nancy Drew: Danger by Design exits on game start
https://bugs.winehq.org/show_bug.cgi?id=55149 Bug ID: 55149 Summary: Nancy Drew: Danger by Design exits on game start Product: Wine Version: 8.0.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: tiger12506(a)gmail.com Distribution: --- Created attachment 74715 --> https://bugs.winehq.org/attachment.cgi?id=74715 warn+all,+seh,+ddraw Nancy Drew: Danger By Design is 2 disc cd game. I have ISOs created from original discs that I am installing from. Setup.exe works fine -- I choose to change the install location to C:\ND\DangerbyDesign\ because previous attempts to run game from the default location result in it looking for a CIFTree file in the C:\ND\DangerbyDesign directory. That's not the issue. When installed correctly, the game appears to start, the screen goes black, resolution changes to the game's chosen 640x480, and then the game quits (leaving my linux desktop resolution in 640x480 mode). This is the issue. I assume this is a crash, but I either haven't found, or don't understand the outputs of the WINEDEBUG logs well enough to diagnose the issue. Any way that I can help you help me would be appreciated. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55149 joaopa <jeremielapuree(a)yahoo.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree(a)yahoo.fr --- Comment #1 from joaopa <jeremielapuree(a)yahoo.fr> --- I confirm the problem with wine-8.11 Can be downloaded here for testing purpose: https://archive.org/details/nancy-drew-danger-by-design-disc-1 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55149 zl3na7mlf(a)mozmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zl3na7mlf(a)mozmail.com --- Comment #2 from zl3na7mlf(a)mozmail.com --- This is still an issue on Wine v9.3. Game 14 (Danger by Design) is also not the only Nancy Drew affected. Games 13-15 all exhibit this behavior. Game 13: Last Train to Blue Moon Canyon Game 14: Danger by Design Game 15: Creature of Kapu Cave Games 13-15 appear to be only Nancy Drew games affected by this, as I've been able to successfully run Games 1-12 and 16-32 with little to no issues. Additionally, I tried running the games via Lutris to see if anything would change, and it did: On Lutris, if you toggle the "dgvoodoo2" option, the games will boot just fine. They perform terribly, and the cursor is extremely laggy, but it's still something, so I figured I'd let it be known, here, in case it's useful. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=55149 ShimmerFairy <rnddim@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rnddim@gmail.com --- Comment #3 from ShimmerFairy <rnddim@gmail.com> --- Created attachment 81359 --> http://bugs.winehq.org/attachment.cgi?id=81359 One way of fixing the issue, ensuring proper struct size on surface creation. TLDR for the patch: I've narrowed down the issue to a DirectDraw pixel format struct not having its `dwSize` member set properly. Making sure it's set properly fixes all three games mentioned in a prior comment. I'm not familiar enough with wine to know if my patch is the best solution, so a second opinion would be appreciated. To offer a bit more explanation, this is a bug that I have periodically checked up on over the years, because I've been eager to get a chance to replay Last Train. Just today I came across a comment that suggested any library wrapper for ddraw would fix the problem, and that motivated me to poke around with wine's debug prints to see if I could see what the issue is. To my surprise, I actually worked it out, and the patch I've attached allows games 13 through 15 to work (I can at least play through the first few minutes of each one). These games were listed in a previous comment to this bug. The problem comes from when the games' Bink library requests the pixel format of a surface through `ddraw_surface7_GetPixelFormat`. Wine's implementation of this function checks the `dwSize` member of both the source and destination pixel format structs when copying, and this fails here because the surface's pixel format struct has a size of 0. So of course nothing gets copied over, and Bink is given an invalid pixel format struct (specifically all zeroed out). Bink can't do what it needs to do, and the game gives up and quits in response. As far as I can tell, this "zero size" pixel format originates in the surface description supplied to a call to `ddraw7_CreateSurface`. I don't see it show up in the trace before that point, so I think it's the game's fault for not setting the `dwSize` member, though I'm not familiar enough with all this to be sure of that. In any case, the CreateSurface call simply takes the pixel format struct as-is, and that causes the future GetPixelFormat call to copy nothing. (Worth noting, just to make it clear, the pixel format is completely legitimate outside of reporting zero size. Anything ignoring `dwSize` will work with it just fine.) Like I said, I'm a total novice to debugging Wine issues, and to how Windows APIs work in general, so I can't be too confident that my patch is exactly right. My guess is that wine's internal copy of the pixel format struct should have its size set to the actual size of the struct, so that it's describing the size of that internal copy, rather than remembering the original input's claimed size. I've conservatively made it so that the size is only corrected when the input has a size of 0, just in case "wrong" non-zero sizes have a use in other programs that I'm not aware of. Whether or not I got the fix exactly right, I hope this helps the devs fix this very old bug fairly quickly. If you're testing the patch against the games, I *highly* recommend enabling the game's own debug option by setting `DebugOutput=1` in the game's Game.ini file. This not only produces a log file in the game's directory, but it will also pop up a dialog box when Bink fails to initialize due to this bug, preventing the program from immediately quitting. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=55149 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
WineHQ Bugzilla -
WineHQ Bugzilla