https://bugs.winehq.org/show_bug.cgi?id=43826
Bug ID: 43826 Summary: Tomb Raider (1996) GOG now launches only in safe mode Product: Wine Version: 2.18 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: jeffry84@hotmail.it Distribution: ---
The game used to work fully on the Wine version provided on Debian Jessie, but ever since I've switched to Wine Devel the game runs only in safe mode, with less colours and lower resolution. I've tried every graphical option in its Dosbox configurator (previously Direct3D and OpenGL were the best options but they don't work now). It's of course a Dosbox game but as it worked before I'm sure the issue is not on their end.
I'm sorry I can't be more specific, but if further testing or info are needed just ask
https://bugs.winehq.org/show_bug.cgi?id=43826
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #1 from joaopa jeremielapuree@yahoo.fr --- Problem with dosbox, not wine.
Can an administrator close this bug as INVALID?
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #2 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to joaopa from comment #1)
Problem with dosbox, not wine.
Can an administrator close this bug as INVALID?
Why do you say that?
There are two configuration options with GoG DOSBOX, one (dosboxTR_soft.conf) points to the TOMBs.EXE (Safe mode) and the other (dosboxTR_single.conf) to tomb.exe. The question would be what determines whether DOSBOX is launched with one configuration file versus the other.
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #3 from Gianfranco Del Borrello jeffry84@hotmail.it --- Created attachment 66555 --> https://bugs.winehq.org/attachment.cgi?id=66555 2020/02/29 backtrace, Wine 4.0.3
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #4 from Gianfranco Del Borrello jeffry84@hotmail.it --- (In reply to Jeff Zaroyko from comment #2)
(In reply to joaopa from comment #1)
Problem with dosbox, not wine.
Can an administrator close this bug as INVALID?
Why do you say that?
There are two configuration options with GoG DOSBOX, one (dosboxTR_soft.conf) points to the TOMBs.EXE (Safe mode) and the other (dosboxTR_single.conf) to tomb.exe. The question would be what determines whether DOSBOX is launched with one configuration file versus the other.
The game used to work flawlessly under the Wine provided with Debian Jessie (apparently 1.6.2), and the same game, same installer, same exe, same anything you could think of, doesn't work as fine today, only safe mode. The issue is not on DosBox' end, something changed in Wine and broke the compatibility. The safe mode runs just fine. I've added a backtrace today which hopefully will help someone more knowledgeable than me.
https://bugs.winehq.org/show_bug.cgi?id=43826
qsniyg qsniyg@mail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |qsniyg@mail.com
--- Comment #5 from qsniyg qsniyg@mail.com --- I'm trying to reproduce this issue, but I can't even get the game to launch under wine-tkg 5.12 (I'll try vanilla soon), it hangs after loading tomb.exe (or tombs.exe). In fact, it has the same issue under native dosbox.
What I ran was:
cd dosbox wine dosbox.exe -conf ../dosboxTR.conf -conf ../dosboxTR_single.conf -noconsole -c exit
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #6 from Jeff Zaroyko jeffz@jeffz.name --- (In reply to qsniyg from comment #5)
I'm trying to reproduce this issue, but I can't even get the game to launch under wine-tkg 5.12 (I'll try vanilla soon), it hangs after loading tomb.exe (or tombs.exe). In fact, it has the same issue under native dosbox.
What I ran was:
cd dosbox wine dosbox.exe -conf ../dosboxTR.conf -conf ../dosboxTR_single.conf -noconsole -c exit
You might be hitting bug 49564, which Béla Gyebrószki has kindly raised (see discussion there).
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #7 from qsniyg qsniyg@mail.com --- (In reply to Jeff Zaroyko from comment #6)
You might be hitting bug 49564, which Béla Gyebrószki has kindly raised (see discussion there).
Thanks, that was indeed the case!
It looks like it's crashing in glide2x.dll:
--- snip --- 843918.412:0288:028c:CALL glide2x._grDrawPolygonVertexList@8(<unknown, check return>) ret=005f8d1f 843918.412:0288:028c:trace:opengl:glEnable (3553) 843918.412:0288:028c:trace:opengl:glGenTextures (1, 0x3442420) 843918.412:0288:028c:trace:opengl:glBindTexture (3553, 2097261) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10242, 33071) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10243, 33071) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10241, 9729) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10240, 9729) 843918.412:0288:02bc:trace:dsound:IDirectSoundBufferImpl_GetStatus Format is: "(%p,%p)\n" (036051C0,0998FE70) 843918.412:0288:02bc:trace:dsound:IDirectSoundBufferImpl_GetStatus Format is: "status=%x\n" status=5 843918.412:0288:02bc:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition Format is: "(%p,%p,%p)\n" (036051C0,0998FE68,0998FE6C) 843918.412:0288:02bc:trace:dsound:IDirectSoundBufferImpl_GetCurrentPosition Format is: "playpos = %d, writepos = %d, buflen=%d (%p, time=%d)\n" playpos = 2712, writepos = 4476, buflen=32768 (036051C0, time=843918412) 843918.412:0288:028c:trace:opengl:glTexImage2D (3553, 0, 4, 256, 256, 0, 32993, 5121, 0xac30058) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10242, 33071) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10243, 33071) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10241, 9729) 843918.412:0288:028c:trace:opengl:glTexParameteri (3553, 10240, 9729) 843918.412:0288:028c:trace:opengl:glDisable (3042) 843918.412:0288:028c:trace:opengl:glDisable (3008) 843918.412:0288:028c:trace:opengl:glAlphaFunc (518, 0.500000) 843918.412:0288:028c:trace:opengl:glEnable (3008) 843918.412:0288:028c:trace:opengl:glBegin (4) 843918.412:0288:028c:trace:opengl:glColor3fv (0x9fee0e8) 843918.412:0288:028c:trace:process:NtQueryInformationProcess (0xffffffff,0x00000022,0x7ffdbac0,0x00000004,(nil)) 843918.412:0288:028c:trace:seh:KiUserExceptionDispatcher code=c0000005 flags=0 addr=00000000 ip=00000000 tid=028c 843918.412:0288:028c:trace:seh:KiUserExceptionDispatcher info[0]=00000000 843918.412:0288:028c:trace:seh:KiUserExceptionDispatcher info[1]=00000000 843918.412:0288:028c:trace:seh:KiUserExceptionDispatcher eax=00000039 ebx=00000000 ecx=02c7b8ec edx=09ff3ee0 esi=00000000 edi=00000000 843918.412:0288:028c:trace:seh:KiUserExceptionDispatcher ebp=00000000 esp=02c7b8e8 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010212 --- snip ---
I believe it's crashing either on 0x65fc8c8c or 0x65fc8ca0 in glide2x.dll (one of the two is uninitialized):
--- snip --- 65fc8c79 e8 7a e4 CALL glColor3fv undefined glColor3fv() 00 00 65fc8c7e 8b 15 90 MOV EDX,dword ptr [DAT_66012090] = ?? 20 01 66 65fc8c84 01 da ADD EDX,EBX 65fc8c86 83 ec 04 SUB ESP,0x4 65fc8c89 89 14 24 MOV dword ptr [ESP],EDX 65fc8c8c ff 15 58 CALL dword ptr [DAT_66054458] 44 05 66 65fc8c92 a1 9c 20 MOV EAX,[DAT_6601209c] = ?? 01 66 65fc8c97 8b 0c 30 MOV ECX,dword ptr [EAX + ESI*0x1] 65fc8c9a 83 ec 04 SUB ESP,0x4 65fc8c9d 89 0c 24 MOV dword ptr [ESP],ECX 65fc8ca0 ff 15 64 CALL dword ptr [DAT_66054464] 44 05 66 65fc8ca6 8b 15 94 MOV EDX,dword ptr [DAT_66012094] = ?? 20 01 66 65fc8cac 01 da ADD EDX,EBX 65fc8cae 83 ec 04 SUB ESP,0x4 65fc8cb1 89 14 24 MOV dword ptr [ESP],EDX 65fc8cb4 e8 2f e4 CALL glTexCoord4fv undefined glTexCoord4fv() 00 00 --- snip ---
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #8 from qsniyg qsniyg@mail.com --- Created attachment 67706 --> https://bugs.winehq.org/attachment.cgi?id=67706 hack to allow wglSetPixelFormat to modify the pixel format
SDL_SetVideoMode (0x65fd6452 in glide2x.dll) fails, and the following is logged in glide.log:
Video mode set failed: Unable to reset window for OpenGL context
It's using SDL 1.2.14, so looking at the source (WIN_GL_SetupWindow):
--- snip --- if ( !SetPixelFormat(GL_hdc, pixel_format, &GL_pfd) ) { if ( i == 0 ) { if ( WIN_GL_ResetWindow(this) < 0 ) { // <-- This is where it crashes, however return(-1); } continue; } --- snip ---
However, the real problem is that SetPixelFormat crashes (I added an ERR trace to figure out what was going on):
--- snip --- 0364:trace:wgl:set_pixel_format (0x110051,101) 0364:trace:wgl:get_pixel_format Returning fmt_id=0x1ab for iPixelFormat=101 0364:err:wgl:set_pixel_format prev 5 == format 101 0364:RET SDL.SDL_SetVideoMode() retval=00000000 ret=08656457 --- snip ---
The hack I attached is incorrect, but it allows the game to run, by allowing it to re-modify an existing pixel format.
https://bugs.winehq.org/show_bug.cgi?id=43826
--- Comment #9 from Rafał Mużyło galtgendo@o2.pl --- I've run into this problem in a different place.
I'm not quite sure what that lib was doing, but after the hack was applied, the app that was using it displayed only black screen, unless wine renderer (the registry option) was switched from default to gdi.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla