[Bug 10459] New: Crash in G-Nome which uses Smacker Video Codec ( smackw32 + render.r32)
http://bugs.winehq.org/show_bug.cgi?id=10459
Summary: Crash in G-Nome which uses Smacker Video Codec (smackw32 + render.r32) Product: Wine Version: 0.9.39. Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wine-directx-d3d AssignedTo: wine-bugs@winehq.org ReportedBy: legolas558@email.it
G-Nome is a game developed by 7thlevel. It is a quite old game (1998).
The game uses the Smacker Video Codec, which seems to be the faulty one.
The crash happens in the render.r32 (exact filename) DLL; there is to say that a similar crash happens on Windows XP when exiting the game.
The initial video is played correctly, although when ending the "Loading mission" stage the game cannot be played.
If Wine will be fixed for this Smacker Video Codec bug, many other games will get the enhancement.
I am available for further testing, debugging or assembly inspection.
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #1 from Daniele C. legolas558@email.it 2007-11-15 09:09:38 --- Created an attachment (id=9167) --> (http://bugs.winehq.org/attachment.cgi?id=9167) render.r32 write pagefault
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #2 from Daniele C. legolas558@email.it 2007-11-15 09:11:30 --- Created an attachment (id=9168) --> (http://bugs.winehq.org/attachment.cgi?id=9168) The crash with WINE_DEBUG=warn+all
http://bugs.winehq.org/show_bug.cgi?id=10459
Daniele C. legolas558@email.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Crash in G-Nome which uses |Crash in G-Nome which uses |Smacker Video Codec |RenderWare v2.08 MR8 and |(smackw32 + render.r32) |Smacker Video Codec
--- Comment #3 from Daniele C. legolas558@email.it 2007-11-16 05:37:38 --- The problem is indeed in the RenderWare v2.08 MR8 DLL deployed with the game.
Before the crash, RwGetRasterPixels returns NULL. The game code does not handle such case, hence the crash in render.r32 during a possible attempt to copy pixels into another buffer.
I will debug in parallel the game under Windows XP and Wine using the same debugger, and possibly try another version of RenderWare.
Meanwhile, does anybody know about fixed/patched/updated versions of RenderWare v2.x ?
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #4 from Daniele C. legolas558@email.it 2007-11-16 05:49:37 --- I could find the RenderWare v2.31.2.0 libraries but they are not marked as "static" as the v2.0 provided with the game.
The game instantly crashes when using these versions, it doesn't get to the menu screen
http://bugs.winehq.org/show_bug.cgi?id=10459
Daniele C. legolas558@email.it changed:
What |Removed |Added ---------------------------------------------------------------------------- Difficulty|--- |Weeks Keywords| |conformance, download
--- Comment #5 from Daniele C. legolas558@email.it 2007-11-26 04:15:13 --- I think I have narrowed down the problem as best as I can. Now it's time for somebody else to give it a look, since I cannot continue due to my lacking skills.
The problem is that a certain RenderWare structure contains a 32bit field which is set to 0 in Wine, and to 8 in Windows XP. That's the bit depth, I guess. Actually Windows XP executes it in fullscreen and maybe it is giving the correct bit depth to it, while Wine fails to do this.
I have patched rwl20.dll as follows:
0001E910 47 28 09 00 00 00 89 47 1C 89 47 20 8B C7 5F 5E 0001E920 5B C2 0C 00 B9 08 00 00 00 89 48 14 EB 0E CC CC 0001E930 A1 D4 25 7D 01 90 90 EB EB 8B 48 14 8B 44 24 04 0001E940 51 52 50 E8 18 FF FF FF C2 08 00 CC CC CC CC CC
This code will set the 32bit field with value 8 (as it is on Windows XP) and continue execution.
However the game crashes elsewhere, so the problem must be solved at the root.
It is strange that the menu works correctly (except the hovering text which is not displayed at all), while the 3d mode - which uses RenderWare engine - fails.
The Smacker Videos also show correctly, except that they are at ultra-speed under certain conditions.
http://bugs.winehq.org/show_bug.cgi?id=10459
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Difficulty|Weeks |--- Ever Confirmed|0 |1
--- Comment #6 from Austin English austinenglish@gmail.com 2008-12-06 18:44:43 --- http://www.download.com/G-NOME-demo/3000-7563_4-10001059.html
Still present in 1.1.10.
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #7 from Daniele C. legolas558@email.it 2008-12-07 03:17:22 --- I am now using Ubuntu Intrepid Ibex and wine-1.0.1. Problem is still present, my patched version of rwl20.dll runs a bit longer but the crash happens anyhow.
I have attached the backtrace dumps got on stdout/stderr with both version (patched and original) of rwl20.dll
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #8 from Daniele C. legolas558@email.it 2008-12-07 03:18:15 --- Created an attachment (id=17712) --> (http://bugs.winehq.org/attachment.cgi?id=17712) Crash with wine-1.0.1 and the original rwl20.dll
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #9 from Daniele C. legolas558@email.it 2008-12-07 03:18:40 --- Created an attachment (id=17713) --> (http://bugs.winehq.org/attachment.cgi?id=17713) Crash with slightly patched rwl20.dll
http://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #10 from Austin English austinenglish@gmail.com 2010-06-13 19:43:30 --- Still present in 1.2-rc3.
http://bugs.winehq.org/show_bug.cgi?id=10459
butraxz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |butraxz@gmail.com
--- Comment #11 from butraxz@gmail.com 2012-05-17 15:05:25 CDT --- This bug has not been updated for two years. Is this still an issue i current (1.5.4) or newer wine ? You may also close this as abandoned if you feel that that this is issue is no longer relevant to you.
https://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #12 from Austin English austinenglish@gmail.com --- Created attachment 49300 --> https://bugs.winehq.org/attachment.cgi?id=49300 crash log
Starting a new mission results in the attached crash in 1.7.24.
https://bugs.winehq.org/show_bug.cgi?id=10459
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #13 from super_man@post.com --- (In reply to Austin English from comment #12)
Created attachment 49300 [details] crash log
Starting a new mission results in the attached crash in 1.7.24.
Pressing start (new mission) causes crash wine-staging 1.9.5 and wine-1.9.5-124-g62277fb
Maybe the analyzes are enough for fixing this?
https://bugs.winehq.org/show_bug.cgi?id=10459
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://archive.org/details | |/GNome_1020
https://bugs.winehq.org/show_bug.cgi?id=10459
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #14 from joaopa jeremielapuree@yahoo.fr --- The problem is the game needs 256 colors desktop Xephyr :1 -ac -screen 800x600x8 & DISPLAY=:1 wine g-nome.exe is a workaround
https://bugs.winehq.org/show_bug.cgi?id=10459
--- Comment #15 from joaopa jeremielapuree@yahoo.fr --- Without workaround game complains about
0024:fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
With Xephyr, you can start a mission. No crash.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla