https://bugs.winehq.org/show_bug.cgi?id=38115
Bug ID: 38115 Summary: Grandia 2: game crashes after videos are skipped Product: Wine Version: 1.7.36 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: c.wehrmeyer@gmx.de Distribution: ---
Created attachment 50797 --> https://bugs.winehq.org/attachment.cgi?id=50797 Backtrace of wine when the game crashes
What I am trying to archive: I want to get the game Grandia II running on a Multilib Gentoo System (x86 and x64). To reduce I/O latency that is bound to happen due to the carrier medium (optical drive/CD), I created local images that can be mounted in. This runs fine on Windows, the copy protection detects no problems, and I can start and play that game.
How have I installed Winw: - I have got the latest source from the git repository: $ git clone git://source.winehq.org/git/wine.git wine 2>&1 > ~/wine_git.txt
- I configured the sources, compiled them, and installed the binaries into a separate directory:
$ ./configure --prefix=/opt/local/wine $ make -j 9 2>&1 > ~/wine_make $ make install 2>&1 > ~/wine_make_install
- I mounted the CD images:
$ sudo mount -t iso9660 GRANDIA2CD1.iso cd1 mount: /dev/loop0 ist schreibgeschützt, wird eingehängt im Nur-Lese-Modus $ sudo mount -t iso9660 GRANDIA2CD2.iso cd2 mount: /dev/loop1 ist schreibgeschützt, wird eingehängt im Nur-Lese-Modus $ sudo mount | grep 'CD' /path/GRANDIA2CD1.iso on /path/cd1 type iso9660 (ro) /path/GRANDIA2CD2.iso on /path/cd2 type iso9660 (ro)
- I created a Win32 user prefix, because the game is a x86 application.
$ WINEPREFIX="/home/user/new_wine" WINEARCH='win32' /opt/local/wine/bin/wine "wineboot"
- I made sure (with WINEPREFIX="/home/user/new_wine" WINEARCH='win32' /opt/local/wine/bin/winecfg) that the drives D: and E: were directly pointing to where the CD-images are mounted
- I installed the game - in the cd1/ dir:
$ WINEPREFIX="/home/user/new_wine" WINEARCH='win32' /opt/local/wine/bin/wine autorun.exe
- I copied the games executable from the second CD to the main game folder, because for some reason the installer wouldn't do that.
What is the problem:
The game starts, but it does not play the intro videos, and the game crashes if I press F9 (skip videos).
What can I say about the crash:
The crash always happens at the same address:
Unhandled exception: page fault on read access to 0x00000004 in 32-bit code (0x004884b9).
From what I can gather, 0x004884b9 is the code address that causes the crash.
The machine code read this (intel syntax):
4884b3: 8b 0d 0c 47 9c 00 mov ecx,DWORD PTR ds:0x9c470c 4884b9: 8b 51 04 mov edx,DWORD PTR [ecx+0x4] 4884bc: 8b 42 08 mov eax,DWORD PTR [edx+0x8] 4884bf: 8b 40 48 mov eax,DWORD PTR [eax+0x48]
If I read this correctly - and I might be mighty wrong here - the value 0x9c470c is loaded into the ecx register, and the value stored at 0x9c4710 is then tried to load into the edx register. But it seems as if the ecx register is nullified again.
For reference: other 3D games as Deus Ex run very fine. Due to the fact that I am rendering with my Intel chip (I own an optimus laptop with maxwell architecture, for which the drivers are still declared as WIP), the CPU usage is a bit higher than on Windows, but I can archive 60 FPS with not problems whatsoever.
The backtrace is included as attachment. If demanded, I can also upload the "configure", "make" and "make install" logs.
https://bugs.winehq.org/show_bug.cgi?id=38115
Christian Wehrmeyer c.wehrmeyer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |c.wehrmeyer@gmx.de Distribution|--- |Gentoo
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #1 from Christian Wehrmeyer c.wehrmeyer@gmx.de --- I found the cause of the problem.
I disassembled the code further and found out that Wine seems to have a problem with old DOS pathnames. If the game, for example, tries to load in the file "kami01.vms.adx", this attempt failes because there's only a "kami01~1.adx" available. My workaround involves renaming all the DOS file names into "correct" ones, but as you can imagine, this is a bit of work that can be avoided completely if Wine was capable of finding the file behind the DOS paths.
Windows, as I said, has no problems finding the correct files, so this is no feature request, but a bugfix.
https://bugs.winehq.org/show_bug.cgi?id=38115
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #2 from super_man@post.com --- Can you the point where wine does something wrong when it searches the files?
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #3 from Christian Wehrmeyer c.wehrmeyer@gmx.de --- I guess you meant "pin-point" where Wine does something wrong ...
And if I remember correctly (unfortunately it has been some months and I don't have the disassembly database anymore) there was an fopen(3) call with the real file name ("kami01.vms.adx"). If that call fails because the file does not exist, fopen(3) returns a NULL pointer.
That the developers of the game did not check for NULL pointers - OK, that's a given. But once I change the file name, the game at least starts.
The fopen(3) implementation of Wine should take into consideration that the given file name is not 1:1 available on the file system. But if it's converted into a DOS name and then searched for again, it will be found.
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #4 from Christian Wehrmeyer c.wehrmeyer@gmx.de --- By the way: the installer of "Warlords Battlecry 2" has the same problem. On the CD, the files are only available with their DOS file names, but the installer searches for the real names. Under Windows, the installer finds the files, but with Wine the installer fails when it tries to copy video files. Due to this, I now have to install the game on Windows and recreate the registry entries in Wine as well.
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #5 from super_man@post.com --- Still needs console output. It's too complicate to start looking where wine does something wrong based on just description.
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #6 from Matteo Bruni matteo.mystral@gmail.com --- Actually it's pretty clear, thanks Christian for the thorough analysis.
Wine does also look for the short filenames, the problem is that it uses an incompatible encoding (e.g. see http://source.winehq.org/git/wine.git/blob/370254cbe93beae6a9ff693d98c638db5...), probably because it has to generate unambiguous short names without storing them on the filesystem. What it means is that Wine is okay if e.g. an application creates a file with a long name and then looks up the short name version but it fails in this case since the file was created and is stored with the "windows version" short name.
I guess this bug could be fixed by e.g. storing the short filenames in extended attributes and then using a compatible short filename encoding. Not trivial but if you want to take a stab at it it would be great ;)
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #7 from Alexandre Julliard julliard@winehq.org --- (In reply to Matteo Bruni from comment #6)
I guess this bug could be fixed by e.g. storing the short filenames in extended attributes and then using a compatible short filename encoding. Not trivial but if you want to take a stab at it it would be great ;)
If I understand correctly, this bug is about the filenames on the CD, so extended attributes won't help. You probably need to tweak the CD mount options (joliet etc.) to show the long file names.
https://bugs.winehq.org/show_bug.cgi?id=38115
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #8 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.14?
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #9 from Christian Wehrmeyer c.wehrmeyer@gmx.de --- Well, it's been five years since I posted the original bug. I don't have access to the hardware, the system or the game anymore; however I still remember a few things from back when that I cannot reproduce right now.
As already explained the initial problem was with the file system on the CDs using shortened DOS file names. The way I fixed that back then was by copying the files from the CD into the install directory of the game, then fixed their names and started the game. I'm not entirely sure in which order Wine or Windows are supposed to search for files, but this fixed the crashes for me.
So why did I never follow up on this? Because it soon became very clear that the rendering API that Grandia 2 uses - which may be DirectX 8 or something like that - simply wasn't supported correctly by Wine, both in the 2D and 3D department. In terms of 2D Grandia 2 uses alpha blending for the "Press Button" text in the main menu to make it fade in and out, but on Wine all I got were warnings about alpha not being supported or something on the console that killed my FPS, whilst the text stayed more or less on the same alpha level. I remember delving into the Wine source and adding the option in a switch-case statement that would get rid of the warnings and made the text properly fade in and out, but I couldn't tell you what I did exactly anymore.
As for 3D things were a lot more broken than for 2D. On the Wine version that I initially advertised there was model flickering basically the moment I loaded a save and the game switched into 3D mode; a flickering that would persist in the field as well as in battle mode. I remember downloading an updated version of Wine some time after this and, instead of flickering, was met with a black screen instead (music still played). When I then read that the Wine devs cared more about supporting DirectX 12 than making sure that older APIs worked (Grandia 2 isn't the sole exception here by the way; in the original version of La-Mulana the music didn't play because no one other than Microsoft ever bothered to support DLS files) I sort of gave up on this ordeal and instead decided to move on with my life. Because if the devs don't care about getting this to run on older DirectX versions, then why should I?
https://bugs.winehq.org/show_bug.cgi?id=38115
--- Comment #10 from Henri Verbeet hverbeet@gmail.com --- (In reply to Christian Wehrmeyer from comment #9)
met with a black screen instead (music still played). When I then read that the Wine devs cared more about supporting DirectX 12 than making sure that older APIs worked (Grandia 2 isn't the sole exception here by the way; in the original version of La-Mulana the music didn't play because no one other than Microsoft ever bothered to support DLS files) I sort of gave up on this ordeal and instead decided to move on with my life. Because if the devs don't care about getting this to run on older DirectX versions, then why should I?
I'm not sure where you read that, but that's certainly not the project's policy. Individual contributors will of course always have their personal preferences, but personally I'm not especially interested in chasing the game of the week either.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla