[Bug 59846] New: Worms Forts: Under Siege (GOG.com) crashes on start when trying to play the intro
http://bugs.winehq.org/show_bug.cgi?id=59846 Bug ID: 59846 Summary: Worms Forts: Under Siege (GOG.com) crashes on start when trying to play the intro Product: Wine Version: 11.9 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: dsound Assignee: wine-bugs@list.winehq.org Reporter: gyebro69@gmail.com CC: jonkoops@gmail.com Regression SHA1: ebc31cfbeef9b1079685b1ef8b281a7b02072119 Distribution: --- Created attachment 81141 --> http://bugs.winehq.org/attachment.cgi?id=81141 terminal output This was tested with GOG.version. Can't reproduce with the original demo version. The game crashes on start just when the first intro movie should be started. Disabling the intro movie by starting the game with /NOMOVIES option works around the crash. Bisected to commit ebc31cfbeef9b1079685b1ef8b281a7b02072119 dsound: Create independent devices for each DirectSoundCreate call. Can't revert the patch but the game starts properly with the previous commit. Let me know what debug log would be useful. wine-11.10-181-g71958c63809 -- 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=59846 Alistair Leslie-Hughes <leslie_alistair@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|dsound |quartz CC| |leslie_alistair@hotmail.com --- Comment #1 from Alistair Leslie-Hughes <leslie_alistair@hotmail.com> --- Reproduced the issue. Work around winetricks quartz The crash occurs because the dst and src surfaces are not the same type. source is YV12 destination is RGB24 The destination is created via the application "allocator" and I couldn't find the location (d3d*) of where it was creating the destination Surface. Not sure, if we actually need to convert to the destination type. Guess a few tests could prove one way or another. -- 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=59846 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #2 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81780 --> http://bugs.winehq.org/attachment.cgi?id=81780 Screenshot MangoHUD showing OpenGL regardless of WINE_D3D_CONFIG=renderer=gl or vulkan
The destination is created via the application "allocator" and I couldn't find the location (d3d*) of where it was creating the destination Surface.
Game seems to use OpenGL for rendering vs d3d which MangHUD reports regardless of WINE_D3D_CONFIG=renderer=gl or vulkan so logs/tests may need to target opengl vs d3d. -- 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=59846 --- Comment #3 from Stian Low <wineryyyyy@gmail.com> --- Created attachment 81781 --> http://bugs.winehq.org/attachment.cgi?id=81781 Backtrace for wine-11.14-a37867ddf84 -- 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=59846 --- Comment #4 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #3)
Created attachment 81781 [details] Backtrace for wine-11.14-a37867ddf84
Oddly the backtrace shows d3d9 and other directx modules so maybe MangoHUD is not reporting correctly? -- 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 (1)
-
WineHQ Bugzilla