[Bug 47389] New:=?UTF-8?Q?=20Sid=20Meier=E2=80=99s=20Alpha=20?= Centauri Planetary Pack (GOG version) ddraw crash
https://bugs.winehq.org/show_bug.cgi?id=47389
Bug ID: 47389 Summary: Sid Meier’s Alpha Centauri Planetary Pack (GOG version) ddraw crash Product: Wine Version: 4.10 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: BabylonAS@yandex.ru Distribution: ---
Created attachment 64728 --> https://bugs.winehq.org/attachment.cgi?id=64728 Terminal output of an attempt to execute Alpha Centaurl with the expansion
This is a direct continuation of my ill-fated attempt at a bug report: https://bugs.winehq.org/show_bug.cgi?id=47388
Sid Meier’s Alpha Centauri (with Alien Crossfire expansion pack) crashes when trying to run with Wine 4.10 on a 32-bit Debian Testing distribution. Judging by the backtrace (see the attachment), the problem is related to the DirectDraw implementation. If that matters, I’m using a museum exhibition grade ATI Mobility Radeon 7000 IGP with just 16 MB of RAM (and a mostly open-source Linux driver, with proprietary microcode; compatible with OpenGL 1.3), but I suppose that SMAC might work even with 4 MB.
Trying to add DirectDraw=0 to Alpha Centauri.Ini didn’t fix the issue, the only practical difference was the appearance of Firaxis Games logo followed by the crash. Running the Alpha Centauri itself (without Alien Crossfire) didn’t work either.
https://bugs.winehq.org/show_bug.cgi?id=47389
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #1 from Paul Gofman gofmanp@gmail.com --- Looks like your setup or mesa problem: --- Mesa 18.3.6 implementation error: Invalid GLSL version in shading_language_version() Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa ---
Maybe mesa does not work very well with museum exhibition grade ATI Radeon card...
Does 'glxgears' work for you? 'glxinfo -l' output might be interesting to see, but overall not much chances it can be helped. You can try setting the following values in HKCU\Software\Wine\Direct3D\ key: MaxVersionGL 0x10000 (DWORD) value UseGLSL disabled (string value).
See https://wiki.winehq.org/Useful_Registry_Keys.
There is a small chance that this will help.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Can you please also attach the output with "WINEDEBUG=+ddraw,+d3d"?
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #3 from BabylonAS@yandex.ru --- Created attachment 64730 --> https://bugs.winehq.org/attachment.cgi?id=64730 wine output with WINEDEBUG=+ddraw,+d3d
Here’s the combined terminal output for +ddraw and +d3d. Number 4 because I’ve saved the 2nd file for pure SMAC (without Crossfire), 3rd solely for d3d and 4th solely for ddraw.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #4 from BabylonAS@yandex.ru --- Created attachment 64731 --> https://bugs.winehq.org/attachment.cgi?id=64731 Output of glxinfo -l
glxgears works, and here’s the glxinfo -l output. I’ll try editing the registry.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #5 from BabylonAS@yandex.ru --- Created attachment 64732 --> https://bugs.winehq.org/attachment.cgi?id=64732 wine output after editing registry (same WINEDEBUG)
Didn’t help. I suppose it’s time to try the other course of investigation, the one that isn’t about DirectX implementation.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #6 from BabylonAS@yandex.ru --- Created attachment 64733 --> https://bugs.winehq.org/attachment.cgi?id=64733 wine output with WINEDEBUG=+seh,+virtual,+module
Per https://bugs.winehq.org/show_bug.cgi?id=47388#c4 I’ve also supplied an output with WINEDEBUG set to +seh,+virtual,+module. Beware, it’s almost 1.5 megabytes in size.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #7 from Paul Gofman gofmanp@gmail.com --- (In reply to BabylonAS from comment #5)
No need to. Thanks for the additional logs & information. Your log confirms Comment #1 with a bit of additional details. This is from your log: --- 0009:trace:d3d:wined3d_adapter_init_limits Max anisotropy: 16. Mesa 18.3.6 implementation error: Invalid GLSL version in shading_language_version() Please report at https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa 0009:trace:d3d:wined3d_adapter_init_gl_caps GLSL version string: (null). ---
The next line of code after printing the message with NULL GLSL version string is: --- TRACE("GLSL version string: %s.\n", debugstr_a(str));
/* The format of the GLSL version string is "major.minor[.release] [vendor info]". */ sscanf(str, "%u.%u", &major, &minor); ----
It crashes in sscanf() with NULL string received for GLSL version string.
While that's probably worth fixing in terms of returning error instead of crashing here, unfortunately this won't let the application to run, wined3d is unlikely willing to workaround such a problem of getting NULL GLSL version string. Besides, the NULL string and inability to initialize shaders in GL driver size is likely not the only problem with it on the way.
This is not a Wine bug, the only way to fix it is to fix host OpenGL driver (maybe install some other one / version, or fix on the Mesa side). If you want to test it further from the Wine side and is ready to build Wine from source I can probably make a workaround patch tomorrow which will allow wined3d continue with GLSL disabled if GLSL version string is NULL. There is a small chance that after that you will be able to run the game with GLSL shaders disabled.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #8 from Paul Gofman gofmanp@gmail.com --- You can also try the following to workaround the problem if fixing the driver / setup is not possible:
- Set HKCU\Software\Wine\Direct3D\MaxVersionGL to 0x10000 (DWORD hex value) in registry; - run with Mesa environment MESA_EXTENSION_OVERRIDE=-GL_ARB_shading_language_100
With GL_ARB_shading_language_100 extension disabled Wine won't ask for GLSL version string and this should allow to workaround the crash.
From the Wine point of view, the incorrect GL driver behavior is that it
reports GL_ARB_shading_language_100 extension but then refuses to give a valid GLSL version string. The driver itself complains in the log that things went wrong with the string.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #9 from BabylonAS@yandex.ru --- Created attachment 64743 --> https://bugs.winehq.org/attachment.cgi?id=64743 wine output with MESA_EXTENSION_OVERRIDE
This is what I’ve got after setting MESA_EXTENSION_OVERRIDE. The error didn’t trigger, but the game just showed a black screen and a few seconds later exited. DirectDraw is not set to 0.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #10 from Paul Gofman gofmanp@gmail.com --- (In reply to BabylonAS from comment #9)
--- 0009:err:winediag:wined3d_adapter_gl_init You are using the backbuffer for offscreen rendering. This is unsupported, and will be removed in a future version. ---
Oh... your card or driver with this card does not support framebuffer objects. I am not sure if this is the exact reason for the black screen and exit, but unfortunately, I am afraid this card is just generally unsupported under Wine, at least with this OpenGL driver (I am not sure if there are other drivers which will work with the card, but if yes, using them certainly worth trying). Yes, I know it is DirectX 7 card which should work for DX7 on Windows, but Wine does that through OpenGL and requires some later GL features to work.
Yet, there is a chance that some other <= DX7 games will work even under this setup (with MESA_EXTENSION_OVERRIDE=-GL_ARB_shading_language_100 of course).
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #11 from Paul Gofman gofmanp@gmail.com --- I actually missed the point with framebuffer object, your card actually claimed to support that initially, setting MaxVersionGL to 1.0 should have disabled it. You can probably try running with MESA_EXTENSION_OVERRIDE=-GL_ARB_shading_language_100 but without setting any tweaks in registry (removing MaxVersionGL override).
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #12 from BabylonAS@yandex.ru --- It didn’t fix the issue, I’m getting the backbuffer error again.
What other OpenGL drivers can you suggest? I have xserver-xorg-video-radeon 19.0.1, latest ATI/AMD firmware, Radeon DRM 2.4.97.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #13 from Paul Gofman gofmanp@gmail.com --- (In reply to BabylonAS from comment #12)
It didn’t fix the issue, I’m getting the backbuffer error again.
That's looks strange to me. Your earlier logs from comment #3 suggest GL_EXT_framebuffer_object support, so does your glxinfo output from Comment #4. This extension is not there in the log from comment #9. Did anything else besides using MESA_EXTENSION_OVERRIDE change between Comment #3 and the last attempts? If no, can you compare the output of 'glxinfo | grep EXT_framebuffer_object' and 'MESA_EXTENSION_OVERRIDE=-GL_ARB_shading_language_100 glxinfo | grep EXT_framebuffer_object'? I am not sure where did this extension go.
What other OpenGL drivers can you suggest? I have xserver-xorg-video-radeon 19.0.1, latest ATI/AMD firmware, Radeon DRM 2.4.97.
I don't have such a card and don't have any idea which driver will work (better) with it.
Overall, this sort of analysis looks like an offtopic here. Yet I am still a bit curious if we can make this museum card to work with Wine ddraw. Can you please e-mail me directly instead of writing here on these topics?
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #14 from BabylonAS@yandex.ru --- UseGLSL has been set to zero.
Running grep on glxinfo did yield GL_EXT_framebuffer_object when not setting MESA_EXTENSION_OVERRIDE, and nothing when setting it.
https://bugs.winehq.org/show_bug.cgi?id=47389
--- Comment #15 from BabylonAS@yandex.ru --- My bad, I’ve meant “disabled”. And I also disabled DirectDraw in the game’s settings.
https://bugs.winehq.org/show_bug.cgi?id=47389
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG
--- Comment #16 from Matteo Bruni matteo.mystral@gmail.com --- AFAIU right now this is a driver bug. Did you report this to Mesa? If so, please put the bugzilla link in the URL field at the top.
After the driver side is fixed it's likely that some "new" Wine bugs will become visible. We'll probably want separate bug reports for those, but for the time being let's resolve this bug. Please report here when / if the upstream bug is fixed.
https://bugs.winehq.org/show_bug.cgi?id=47389
BabylonAS@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|NOTOURBUG |FIXED
--- Comment #17 from BabylonAS@yandex.ru --- Apparently it’s this: https://bugs.freedesktop.org/show_bug.cgi?id=109524
https://bugs.winehq.org/show_bug.cgi?id=47389
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |NOTOURBUG
-
wine-bugs＠winehq.org