[Bug 41930] New: Civilization III Complete shows black terrain ( Wine compiled with OSMesa support)
https://bugs.winehq.org/show_bug.cgi?id=41930
Bug ID: 41930 Summary: Civilization III Complete shows black terrain (Wine compiled with OSMesa support) Product: Wine Version: 1.7.38 Hardware: x86 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: michael@fds-team.de Regression SHA1: e618ab65ed5b623785c58ea5ece6e39895d43063 Distribution: ---
Created attachment 56311 --> https://bugs.winehq.org/attachment.cgi?id=56311 screenshot
This is one of the few games that I know of which makes some use of OpenGl in bitmaps. When Wine was compiled with OSMesa support, tiles containing terrain turn black as soon as I launch a game. Reproduced with Nvidia binary drivers 375.20 and nouveau/mesa. I tried Civilization III Complete (both the Steam and the GOG.com versions have this bug).
Terminal output: fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 16 err:ole:CoGetClassObject class {5959df60-2911-11d1-b049-0020af30269a} not registered err:ole:CoGetClassObject no class object {5959df60-2911-11d1-b049-0020af30269a} could be created for context 0x1
Reverting the following patch on top of git fixes the problem:
commit e618ab65ed5b623785c58ea5ece6e39895d43063 Author: Michael Müller michael@fds-team.de Date: Tue Feb 3 11:07:38 2015 +0100
gdi32: Fix arguments for OSMesaMakeCurrent when using 16 bit formats.
Please let me know if you need debug logs.
wine-1.9.24-105-g1d3b944 Fedora 24 x86_64 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 375.20
Installed packages: mesa-libOSMesa.i686 13.1.0-0.12.git95ddb37.fc24 mesa-libOSMesa.x86_64 13.1.0-0.12.git95ddb37.fc24 mesa-libOSMesa-devel.i686 13.1.0-0.12.git95ddb37.fc24 mesa-libOSMesa-devel.x86_64 13.1.0-0.12.git95ddb37.fc24
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #1 from Béla Gyebrószki gyebro69@gmail.com --- Some time ago the Mesa packages were updated on Fedora and I can't get Wine to recognize the installed OSMesa since then, although they're installed:
mesa-libOSMesa.i686 17.1.0-0.30.git32be878.fc25 @System mesa-libOSMesa.x86_64 17.1.0-0.30.git32be878.fc25 @che-mesa mesa-libOSMesa-devel.i686 17.1.0-0.30.git32be878.fc25 @System mesa-libOSMesa-devel.x86_64 17.1.0-0.30.git32be878.fc25 @che-mesa
The Wine configure script woes about missing OSMesa development files:
libOSMesa 32-bit development files not found (or too old), OpenGL rendering in bitmaps won't be supported.
From the config.log file:
configure:10830: checking for -lOSMesa configure:10855: ccache gcc -m32 -o conftest -O2 -g -gdwarf-2 conftest.c -lOSMesa -lXext -lX11 -lm >&5 /tmp/ccdTzB5A.o: In function `main': /home/gyebro/sources/wine-git/conftest.c:167: undefined reference to `glAccum' collect2: error: ld returned 1 exit status configure:10855: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "Wine" | #define PACKAGE_TARNAME "wine" | #define PACKAGE_VERSION "2.3" | #define PACKAGE_STRING "Wine 2.3" | #define PACKAGE_BUGREPORT "wine-devel@winehq.org" | #define PACKAGE_URL "http://www.winehq.org" | #define EXEEXT "" ... | #define SONAME_LIBXINERAMA "libXinerama.so.1" | #define SONAME_LIBXCOMPOSITE "libXcomposite.so.1" | #define HAVE_XICCALLBACK_CALLBACK 1 | #define HAVE_XEVENT_XCOOKIE 1 | #define SONAME_LIBGL "libGL.so.1" | /* end confdefs.h. */ | | /* Override any GCC internal prototype to avoid an error. | Use char because int might match the return type of a GCC | builtin and then its argument prototype would still apply. */ | #ifdef __cplusplus | extern "C" | #endif | char glAccum (); | int | main () | { | return glAccum (); | ; | return 0; | } configure:10870: result: not found
Could you please give me some hint for resolving this, so that I could re-test this bug?
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- Wine Staging now contains a patch which makes Wine recognize OSMesa again: https://github.com/wine-compholio/wine-staging/commit/c9b2336f643291a53648ca...
The problem in Civilization III is still present in wine-2.6 (Staging).
Antergos Linux (64-bit) xorg-server 1.19.3-2 mesa 17.0.4-1 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 378.13
https://bugs.winehq.org/show_bug.cgi?id=41930
Nick nick0515@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nick0515@gmail.com
--- Comment #3 from Nick nick0515@gmail.com --- (In reply to Béla Gyebrószki from comment #2)
Wine Staging now contains a patch which makes Wine recognize OSMesa again: https://github.com/wine-compholio/wine-staging/commit/ c9b2336f643291a53648caedd4731405768407bd
The problem in Civilization III is still present in wine-2.6 (Staging).
Antergos Linux (64-bit) xorg-server 1.19.3-2 mesa 17.0.4-1 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 378.13
Sorry I'm not sure if it is appropriate to say this here or not but I have the same problem. I'm new to Linux. Could you please explain to me how to apply the patch from Github.
Thanks,
Nick
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #4 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Nick from comment #3)
Sorry I'm not sure if it is appropriate to say this here or not but I have the same problem. I'm new to Linux. Could you please explain to me how to apply the patch from Github.
Thanks,
Nick
The patch has already been merged in Wine 2.7. Note that the goal of the patch is not to fix the black screen issue. It makes the problem reproducible again.
https://bugs.winehq.org/show_bug.cgi?id=41930
pietro.stroia@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pietro.stroia@gmail.com
--- Comment #5 from pietro.stroia@gmail.com --- (In reply to Béla Gyebrószki from comment #4)
(In reply to Nick from comment #3)
Sorry I'm not sure if it is appropriate to say this here or not but I have the same problem. I'm new to Linux. Could you please explain to me how to apply the patch from Github.
Thanks,
Nick
The patch has already been merged in Wine 2.7. Note that the goal of the patch is not to fix the black screen issue. It makes the problem reproducible again.
Found out that bug is still present in Wine 2.12 (x86) on ArchLinux: OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2) x86/MMX/SSE2 OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.1.4
https://bugs.winehq.org/show_bug.cgi?id=41930
gu3@gmx.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gu3@gmx.com
--- Comment #6 from gu3@gmx.com --- This bug is still present in Wine 2.18 stagging (x86_64) on ArchLinux:
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 387.12 OpenGL core profile shading language version string: 4.50 NVIDIA
https://bugs.winehq.org/show_bug.cgi?id=41930
Jonas Aaberg cja@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cja@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #7 from Jonas Aaberg cja@gmx.net --- Reproducable with:
OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Iris Plus Graphics 640 (Kaby Lake GT3) OpenGL core profile version string: 4.5 (Core Profile) Mesa 17.2.4 OpenGL core profile shading language version string: 4.50
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #8 from gu3@gmx.com --- Again, this bug is still present in Wine 2.19 stagging (x86_64) on ArchLinux:
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 387.12 OpenGL core profile shading language version string: 4.50 NVIDIA
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #9 from gu3@gmx.com --- Again, this bug is still present in Wine 2.20 stagging (x86_64) on ArchLinux:
OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GTX 750/PCIe/SSE2 OpenGL core profile version string: 4.5.0 NVIDIA 387.22 OpenGL core profile shading language version string: 4.50 NVIDIA
https://bugs.winehq.org/show_bug.cgi?id=41930
thibaut.broggi@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |thibaut.broggi@protonmail.c | |om
--- Comment #10 from thibaut.broggi@protonmail.com --- This bug is still present is both wine3.3, wine3.4 and wine 3.5 on ArchLinux:
OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.0.0 OpenGL core profile shading language version string: 4.50
https://bugs.winehq.org/show_bug.cgi?id=41930
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #11 from Jonas Aaberg cja@gmx.net ---
Reverting the patch e618ab65ed5b623785c58ea5ece6e39895d43063 mentioned in the first comment can be done without any merge conflicts with wine 3.0.2 and then Civ3 works again.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #12 from Jonas Aaberg cja@gmx.net --- This bug is still present with 3.18 on ArchLinux:
OpenGL vendor string: X.Org OpenGL renderer string: AMD CAYMAN (DRM 2.50.0 / 4.18.12-arch1-1-ARCH, LLVM 7.0.0) OpenGL core profile version string: 4.3 (Core Profile) Mesa 18.2.2 OpenGL core profile shading language version string: 4.30
https://bugs.winehq.org/show_bug.cgi?id=41930
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=41930
vapespb vapespb@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vapespb@gmail.com
--- Comment #13 from vapespb vapespb@gmail.com --- Created attachment 63404 --> https://bugs.winehq.org/attachment.cgi?id=63404 civilization 3 wine black terrain
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #14 from vapespb vapespb@gmail.com --- This bug is still present with wine 4.0rc5-1 on Manjaro:
OpenGL vendor string: X.Org OpenGL renderer string: AMD BONAIRE (DRM 2.50.0, 4.19.16-1-MANJARO, LLVM 7.0.1) OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.2 OpenGL core profile shading language version string: 4.50
https://bugs.winehq.org/show_bug.cgi?id=41930
Peter peter.milner+wine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.milner+wine@gmail.com
--- Comment #15 from Peter peter.milner+wine@gmail.com --- I also have this issue. It only appears black when there is a city/settler in view. If I can scroll to an area where there is no city, I can see the map/terrain fine. However, once lots of cities are built I can not really see anything and the game becomes very difficult to play.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #16 from vapespb vapespb@gmail.com --- (In reply to Peter from comment #15)
I also have this issue. It only appears black when there is a city/settler in view. If I can scroll to an area where there is no city, I can see the map/terrain fine. However, once lots of cities are built I can not really see anything and the game becomes very difficult to play.
I avoided the problem using Lutris with wine 1.9.20-x86_64 (that version is built-in to Lutris). Terrain is OK now.
However, the keys do not always work normally when starting a game in Lutris. Up and Down, Ctrl + L, etc. But on the tenth launch, they work, and then you can play for several hours. So far this solution is working.
https://bugs.winehq.org/show_bug.cgi?id=41930
Mateusz m.jedrasik@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |m.jedrasik@gmail.com
--- Comment #17 from Mateusz m.jedrasik@gmail.com --- While installing a grossly outdated copy of the software in question is possibly an option, I have found a possibly improved solution, working on 4.0.2 / x64 Ubuntu 18.04 / perhaps on newer wine too.
What I have done was:
(after installing winetricks)
winetricks d3dx11_43 dotnet452 vcrun2010
And that has brought the background back for CIV 3 for me!
(I had experienced the black background before, both with nvidia and nouveau, as the OP has described)
If you get errors during the winetricks run, try deleting the temp directories contents (for me being in ~/.cache/winetricks and ~/.wine/dosdevices/c:/windows/temp/)
Hope that helps as it has worked for me!
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #18 from Mateusz m.jedrasik@gmail.com --- Ah, sorry, hasn't fixed sh*t; I just clicked a non city unit so the textures were seen; like someone else wrote here, when there's no cities or settler units, then there's backgrounds visible.
Alright then, I also have this bug present, in all possible versions of wine that I thus far tried!
Come on wine, how long has this regression been about for now, 3 years almost.
https://bugs.winehq.org/show_bug.cgi?id=41930
wbaudler@gb.nrao.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wbaudler@gb.nrao.edu
--- Comment #19 from wbaudler@gb.nrao.edu --- Same problem with Civilization III Gold on Ubuntu 18.04 and wine 4.18
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #20 from cyberbaud wbaudler@gb.nrao.edu --- Undoing the patch to gdi32.dll mentioned in the initial report fixes the issue.
patch can be seen at https://marc.info/?l=wine-cvs&m=142496389504205&w=2
Looking at the patch, it essentially adds a if statement
if (pixel_formats[context->format - 1].mesa == OSMESA_RGB_565) type = GL_UNSIGNED_SHORT_5_6_5; else type = GL_UNSIGNED_BYTE;
I don't know what the original intend of that change was, but it is responsible for the black terrain issue in civ3.
A quick fix without re-compiling wine is to turn this if statement in wine's gdi32.dll.so into a no-op using a hex editor (hexedit):
search for the 3rd instance of 0x6383 in gdi32.dll and change it to 0x0114 and the black terrain issue is gone.
https://bugs.winehq.org/show_bug.cgi?id=41930
nate nathannichols454@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nathannichols454@gmail.com
--- Comment #21 from nate nathannichols454@gmail.com --- (In reply to cyberbaud from comment #20)
Undoing the patch to gdi32.dll mentioned in the initial report fixes the issue.
patch can be seen at https://marc.info/?l=wine-cvs&m=142496389504205&w=2
Looking at the patch, it essentially adds a if statement
if (pixel_formats[context->format - 1].mesa == OSMESA_RGB_565) type = GL_UNSIGNED_SHORT_5_6_5; else type = GL_UNSIGNED_BYTE;I don't know what the original intend of that change was, but it is responsible for the black terrain issue in civ3.
A quick fix without re-compiling wine is to turn this if statement in wine's gdi32.dll.so into a no-op using a hex editor (hexedit):
search for the 3rd instance of 0x6383 in gdi32.dll and change it to 0x0114 and the black terrain issue is gone.
I think it's actually the 2nd instance
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #22 from Peter peter.milner+wine@gmail.com --- Hmm. I don't have any instances of 0x6383 in gdi32.dll when I open it in a hex editor ...
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #23 from nate nathannichols454@gmail.com --- (In reply to Peter from comment #22)
Hmm. I don't have any instances of 0x6383 in gdi32.dll when I open it in a hex editor ...
I believe that he meant gdi32.dll.so.
On my machine, (ubuntu 18.04) "locate gdi32.dll.so" returns multiple files. The one that worked was /usr/lib/i386-linux-gnu/wine/gdi32.dll.so
https://bugs.winehq.org/show_bug.cgi?id=41930
Bryan Varner bryan@varnernet.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bryan@varnernet.com
--- Comment #24 from Bryan Varner bryan@varnernet.com --- So, it looks like this should always be GL_UNSIGNED_BYTE, regardless of the bit-depth.
Per the osmesa.h documentation on OSMesaMakeCurrent:
``` Return: GL_TRUE if success, GL_FALSE if error because of invalid ctx, * invalid buffer address, type!=GL_UNSIGNED_BYTE, width<1, height<1, * width>internal limit or height>internal limit. ```
I'm confused about why this patch was ever added, and why it was ever approved.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #25 from Bryan Varner bryan@varnernet.com --- Created attachment 66434 --> https://bugs.winehq.org/attachment.cgi?id=66434 osmesa-byte-fix.patch
According to the Mesa docs, only GL_UNSIGNED_BYTE is supported, ever. This is a quick hack to restore the original functionality.
https://bugs.winehq.org/show_bug.cgi?id=41930
Vijay Kamuju infyquest@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest@gmail.com
--- Comment #26 from Vijay Kamuju infyquest@gmail.com --- also check further documentation here https://cgit.freedesktop.org/mesa/mesa/tree/src/mesa/drivers/osmesa/osmesa.c...
/** * Bind an OSMesaContext to an image buffer. The image buffer is just a * block of memory which the client provides. Its size must be at least * as large as width*height*sizeof(type). Its address should be a multiple * of 4 if using RGBA mode. * * Image data is stored in the order of glDrawPixels: row-major order * with the lower-left image pixel stored in the first array position * (ie. bottom-to-top). * * If the context's viewport hasn't been initialized yet, it will now be * initialized to (0,0,width,height). * * If both the context and the buffer are null, the current context will be * unbound. * * Input: osmesa - the rendering context * buffer - the image buffer memory * type - data type for pixel components * Normally, only GL_UNSIGNED_BYTE and GL_UNSIGNED_SHORT_5_6_5 * are supported. But if Mesa's been compiled with CHAN_BITS==16 * then type may be GL_UNSIGNED_SHORT or GL_UNSIGNED_BYTE. And if * Mesa's been build with CHAN_BITS==32 then type may be GL_FLOAT, * GL_UNSIGNED_SHORT or GL_UNSIGNED_BYTE. * width, height - size of image buffer in pixels, at least 1 * Return: GL_TRUE if success, GL_FALSE if error because of invalid osmesa, * invalid buffer address, invalid type, width<1, height<1, * width>internal limit or height>internal limit. */
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #27 from Bryan Varner bryan@varnernet.com --- Ok! So the mesa headers are out of date with the implementation.
Looking into the actual osmesa.c source - it looks like it's saying it'll wrap the the actual buffer created to CHAN_BITS size with one that reports / functions as the type specified.
Perhaps I should do some more debugging here -- I'm wondering if osmesa is returning a GL_FALSE (resulting in the black terrain) or if there's something else amiss here.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #28 from Bryan Varner bryan@varnernet.com --- So I've determined that the type paramater to pOSMesaMakeCurrent is correct for both MESA and for the intended use-case... I think.
BUT.
If you force pOSMesaMakeCurrent to fail, due issuing the wrong type (BYTE for a 5_6_5 buffer), then the game appears to work.
HOWEVER.
The code-paths executed by the game become very different.
With the osmesa bits not returning errors, the game normally calls:
wglCreateContext wglMakeCurrent(to activate) ... draw things ... wglMakeCurrent(to deactivate) wglDeleteContext
In a pretty loop, but the backgrounds fail to work as intended at some point -- (one of the createContexts contains a deviation in the dib width / height, and that's when things go awry)
If you make the osmesa bits throw errors in OSMesaMakeCurrent, then the game only ever calls
wglMakeCurrent over and over, to try and activate a context. It never calls it with null parameters to unset the active context. it never deletes contexts.
Strange.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #29 from Bryan Varner bryan@varnernet.com --- Civ3 is requesting a 16 bit pixel format for the wglChoosePixelFormat...
0009:trace:wgl:wglChoosePixelFormat 0x1018e 0x32cca8: size 40 version 1 flags 40 type 0 color 16 0,0,0,0 accum 0 depth 0 stencil 0 aux 0
It's setting zeros for the bit channels, however, it's behaving as if it expects an alpha channel, and that the raster buffer will be initialized with transparency (I think).
The wglChoosePixelFormat is skipping all the formats with an alpha channel. I've tried forcing it to use OSMESA_RGBA with a 32bbp buffer, but I get page faults during the Civ3 glFlush().
The app is setting things up with 0009:trace:opengl:glEnable (3042) (0x0BE2) (GL_BLEND) 0009:trace:opengl:glBlendFunc (770, 771) (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)
But never calls a glClear() to set a background color. I do see it calling glColor4f() with non-zero (1 and decimal floats) for the alpha channel.
So it looks like wglChoosePixelFormat is returning a 16bpp buffer with no alpha channel, while the game is expecting (but not explicitly requesting) a raster with an alpha channel.
https://bugs.winehq.org/show_bug.cgi?id=41930
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|e618ab65ed5b623785c58ea5ece | |6e39895d43063 |
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #30 from Bryan Varner bryan@varnernet.com --- After a lot of debugging and stepping, I wrote a small win32 app in a Windows 7 virtual machine that mimicked the code paths I was seeing called from Civ 3.
It's pretty clear from messing with this that the app does expect a 565 raster, and utilizes pre-multiplied alpha for the offscreen opengl raster.
Yay.
But this got me to the blt implementations in gdi32/dibdrv.c. Based on what I'm seeing, it's like with pre-multiplied alpha it's expecting the blt to not just overwrite the target bitmap (even though the OP is a copy according to the debugging...).
What's confusing me now is that in the MSDN docs, I see references to offscreen dibs blts with tertiary ROPS, but I only see binary ROPS implemented in Wine code. it _looks_ like the tertiary ROPs funciton on premultiplied alpha, which is certainly what Civ 3 is expecting here.
The majority of the offscreen buffer is 0,0,0, with the actual OGL parts being rendered into 565 RGB but with pre-multiplied alpha transparency. I confirmed this with screenshots from running in a virtual machine -- where the opengl rendered bits are translucently blt overtop the destination bitmap (the 2d isometric terrain).
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #31 from Bryan Varner bryan@varnernet.com --- After a lot of debugging and stepping, I wrote a small win32 app in a Windows 7 virtual machine that mimicked the code paths I was seeing called from Civ 3.
It's pretty clear from messing with this that the app does expect a 565 raster, and utilizes pre-multiplied alpha for the offscreen opengl raster.
Yay.
But this got me to the blt implementations in gdi32/dibdrv.c. Based on what I'm seeing, it's like with pre-multiplied alpha it's expecting the blt to not just overwrite the target bitmap (even though the OP is a copy according to the debugging...).
What's confusing me now is that in the MSDN docs, I see references to offscreen dibs blts with tertiary ROPS, but I only see binary ROPS implemented in Wine code. it _looks_ like the tertiary ROPs funciton on premultiplied alpha, which is certainly what Civ 3 is expecting here.
The majority of the offscreen buffer is 0,0,0, with the actual OGL parts being rendered into 565 RGB but with pre-multiplied alpha transparency. I confirmed this with screenshots from running in a virtual machine -- where the opengl rendered bits are translucently blt overtop the destination bitmap (the 2d isometric terrain).
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #32 from nate nathannichols454@gmail.com --- (In reply to vapespb from comment #16)
(In reply to Peter from comment #15)
I also have this issue. It only appears black when there is a city/settler in view. If I can scroll to an area where there is no city, I can see the map/terrain fine. However, once lots of cities are built I can not really see anything and the game becomes very difficult to play.
I avoided the problem using Lutris with wine 1.9.20-x86_64 (that version is built-in to Lutris). Terrain is OK now.
However, the keys do not always work normally when starting a game in Lutris. Up and Down, Ctrl + L, etc. But on the tenth launch, they work, and then you can play for several hours. So far this solution is working.
This solution does not work for me
https://bugs.winehq.org/show_bug.cgi?id=41930
mo78@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mo78@abv.bg
--- Comment #33 from mo78@abv.bg --- The bug is still here in Wine 5.19.
https://bugs.winehq.org/show_bug.cgi?id=41930
Atilla ÖNTAŞ tarakbumba@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tarakbumba@gmail.com
--- Comment #34 from Atilla ÖNTAŞ tarakbumba@gmail.com --- I think a workaround would be using gdi32.dll.so from older wine packages. I used on Mageia 7.1 system wine32-2.0.5-1.mga6.i586.rpm package. I extracted this rpm package and copy gdi32.dll file to /usr/lib/wine/gdi32.dll.so Terrain is OK for me . I don't completed a game yet but it seems all game is OK besides well known sfx sounds glitch.
https://bugs.winehq.org/show_bug.cgi?id=41930
babybishops@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |babybishops@gmail.com
--- Comment #35 from babybishops@gmail.com --- Created attachment 69209 --> https://bugs.winehq.org/attachment.cgi?id=69209 Patched DLL as per comment #20
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #36 from babybishops@gmail.com --- Bug present with wine 5.0.
I applied the trick in comment 20 in this thread and it seems to have worked perfectly. I attached the patched DLL to this thread (see top of page) for convenience. On my machine, the file to replace was /usr/lib/i386-linux-gnu/wine/gdi32.dll.so. You can always run "cmp -l file1.so file2.so" to see the differences between the files if you don't trust me.
https://bugs.winehq.org/show_bug.cgi?id=41930
Trevor Cordes winehq@tecnopolis.ca changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@tecnopolis.ca
--- Comment #37 from Trevor Cordes winehq@tecnopolis.ca --- Bryan Varner in comment 25 is right. That patch does fix the bug. I just confirmed it in Fedora 33 and wine 6.11 using Steam civ3 and proton 6.3.
I had to update the patch to match the newer wine source though, I'll attach a newer patch.
It's very tricky to compile the 32-bit version in Fedora with rpmbuild as finding all the -devel deps for 32-bit is a big pain. I couldn't see an easy way to do it. Then fudging the resulting gdi32.dll and gdi32.so files into the right proton places for Steam was also a pain.
It would be nice to get this regression fixed in wine source. Right now none of the newer/experimental proton options on Steam will let you play the game (without this bug).
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #38 from Trevor Cordes winehq@tecnopolis.ca --- Created attachment 70279 --> https://bugs.winehq.org/attachment.cgi?id=70279 newer patch to reproduce comment#25 for wine 6.11
confirmed solves this bug
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #39 from Bryan Varner bryan@varnernet.com --- Thanks for the updated patch...
I'm still leery of the actual blt copy.
From what I recall, this patch makes things not fail in the game, but the
overlaid effect of the green boundary of the city, and other OpenGL effects that are alpha-composited over the map no longer function.
So I'm going to stand by my assertions that there's something going on in the code-path where the blt should be ignoring 565 bytes that are 0x00 -- this is in fact the normal behavior of premultipled alpha blends. I have a hunch that's where the actual issue is, as opposed to the byte format of the offscreen opengl buffer.
The fact that this patch makes things 'look like they work' is really a testament to the game being able to operate where OpenGL wasn't available or wasn't working properly. If an expectation fails, it tries to gracefully degrade the game function, rather than just error and halt.
https://bugs.winehq.org/show_bug.cgi?id=41930
clabbe.montjoie@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |clabbe.montjoie@gmail.com
--- Comment #40 from clabbe.montjoie@gmail.com --- The patch from comment 25 does not apply anymore on wine 6.12, but the bug is still present.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #41 from clabbe.montjoie@gmail.com --- But the patch from comment 38 fixes the issue on wine 6.12.
Thanks
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #42 from Bryan Varner bryan@varnernet.com --- Patches from Comment 25 and Comment 28 makes the game playable but _do_not_ fix the underlying issue.
The patches effectively fail to allocate a pbuffer context, which the game authors were intelligent enough to code around and degrade graphics overlays accordingly.
The underlying issue is an offscreen WGL pbuffer being drawn opaque (copy over destination), instead of doing an precomputed alpha merge into the destination from the pbuffer source.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #43 from Bryan Varner bryan@varnernet.com --- In gdi32/bitblt.c, nulldrv_StretchBlt(...) is responsible for determining what putImage implementation to use when StretchBlt is called upon a source and destination.
By default, it uses the nulldrv_StretchBlt(), which delegates to the _destination_ StretchBlt() implementation. This seems to make sense except in the case of:
* A WGL off-screen pbuffer source using * With alpha blending enabled in the GL Context * Using precomputed alpha in a 5_6_5 pixelformat (or any that doesn't include a dedicated Alpha channel)
In this case, an ROP of SRCCOPY should be carried out as a SRCPAINT, to OR the pixel values into the destination.
This seems like an awful lot of source state to be discovered by the destination in dibdrv_PutImage(), especially without the DC for the src being passed in as a way to validate against a current (if any) GLContext.
If there was an easy way to hook this so that the source driver was used for the PutImage function rather than the Destination driver, but the contexts for both were passed to PutImage, we could centralize this into a new driver function for osmesa_PutImage(...) have it massage the ROP in the proper context, and then defer to invoke the destination pPutImage with the proper ROP.
Or that might be a terrible idea and I'm missing the obvious fix.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #44 from Bryan Varner bryan@varnernet.com --- This is where I get to confess I was wrong about the SRCCOPY being the wrong thing.
I hacked up a quick and dirty StretchBlt that did the introspection on the src, and swapped the ROP to the SRCPAINT....
The _initial_ paint when the settler is active on the map (where it paints the translucent diamond pattern into the offscreen mesa context then blts back to the main screen) worked. However, the map layer never got updated properly again. Every draw after was black.
So, the SRCPAINT vs SRCCOPY and premultiplied alpha idea I've been harboring for a year or so is _not_ the issue. I've been wrong about that for a very long time.
However, in reviewing the ticket, and looking at the results of what was happening when I did the SRCPAINT hack, it has me wondering if I wasn't onto something at the tail end of Comment 30.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #45 from Bryan Varner bryan@varnernet.com --- After adding a bunch of debugging to dibdrv_wglMakeCurrent(...),
I'm quite confident that this is an upstream OSMesa bug.
Complete with a comment contained within osmesa.c, https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/o...
The osmesa context is not copying the user-supplied pixel buffer into the osmesa color buffer when OSMesaMakeCurrent() is invoked. Resulting in an empty (memset to all 0s) buffer being used.
The color_buffer in osmesa is then copied back overtop the user supplied buffer during glFlush() https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/gallium/frontends/o.... This obliterates the previously drawn contents to the device independent bitmap context, replacing them with the offscreen GL contents, which didn't have the original buffer copied in prior to the drawing functions.
It's an OSMesa bug.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #46 from Bryan Varner bryan@varnernet.com --- For anyone who wants to play along, I'm working on a patch to mesa here:
https://gitlab.freedesktop.org/bvarner/mesa/-/tree/feature/osmesa-preserve-b...
With the changes from that branch, the game no longer crashes.
The GL rendered elements seem like they may be in inverse byte order from what is expected.
There are some other visual elements that get messed up from time to time (city name blocks) as well.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #47 from Bryan Varner bryan@varnernet.com --- Upstream bugs related to Civ3 and OSMesa / Gallium Frontend
OSMesa Gallium frontend disregards (obliterates) user supplied buffer contents. https://gitlab.freedesktop.org/mesa/mesa/-/issues/5094
This second one may need to split to a different bug in WINE, as this can't possibly be only manifest in Civ3. Surely there was another app using 16bit off-screen WGL?
OSMesa Gallium frontend using 16-bit packed pixel format with inappropriate color channel spec for WGL https://gitlab.freedesktop.org/mesa/mesa/-/issues/5095
https://bugs.winehq.org/show_bug.cgi?id=41930
Scott shagooserver@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shagooserver@gmail.com
--- Comment #48 from Scott shagooserver@gmail.com --- Same problem, Kubuntu 21.04 Nvidia 1080 Wine 6.15
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #49 from Scott shagooserver@gmail.com --- (In reply to Trevor Cordes from comment #38)
Created attachment 70279 [details] newer patch to reproduce comment#25 for wine 6.11
confirmed solves this bug
Any chance of the compiled so file?
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #50 from Scott shagooserver@gmail.com --- (In reply to Bryan Varner from comment #46)
For anyone who wants to play along, I'm working on a patch to mesa here:
https://gitlab.freedesktop.org/bvarner/mesa/-/tree/feature/osmesa-preserve- buffer
With the changes from that branch, the game no longer crashes.
The GL rendered elements seem like they may be in inverse byte order from what is expected.
There are some other visual elements that get messed up from time to time (city name blocks) as well.
Tried compiling your fix but no luck, has trouble finding clang. Any chance you might do a merge request so we can avoid work-arounds?
https://bugs.winehq.org/show_bug.cgi?id=41930
tomsod-m@ya.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tomsod-m@ya.ru
--- Comment #51 from tomsod-m@ya.ru --- Created attachment 70676 --> https://bugs.winehq.org/attachment.cgi?id=70676 the patched gdi32 library for wine 6.16
Here's the patched gdi32.so for Wine 6.16. It was in /usr/lib32/wine/i386-unix/ on my system. The patch does fix the black screen glitch, but moving settlers around occasionally crashes the game now, so it's not perfect. Hopefully the OSMesa bugs will be fixed soon.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #52 from Scott shagooserver@gmail.com --- (In reply to tomsod-m from comment #51)
Created attachment 70676 [details] the patched gdi32 library for wine 6.16
Here's the patched gdi32.so for Wine 6.16. It was in /usr/lib32/wine/i386-unix/ on my system. The patch does fix the black screen glitch, but moving settlers around occasionally crashes the game now, so it's not perfect. Hopefully the OSMesa bugs will be fixed soon.
Works for me, thank you.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #53 from Scott shagooserver@gmail.com --- It's not just settlers that crash the game, it crashes randomly and frequently, unplayable.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #54 from tomsod-m@ya.ru --- (In reply to Scott from comment #53)
It's not just settlers that crash the game, it crashes randomly and frequently, unplayable.
Oh, it's not just me, then. Too bad! I mean, if you save often, it's manageable, but maybe I should look into that Mesa patch instead.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #55 from Scott shagooserver@gmail.com --- Comment 46 points to the mesa fix but I just cannot build it despite several tries.
https://bugs.winehq.org/show_bug.cgi?id=41930
Alexey Kuznetsov alexey.n.kuznetsov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alexey.n.kuznetsov@gmail.co | |m
--- Comment #56 from Alexey Kuznetsov alexey.n.kuznetsov@gmail.com --- FYI there is very simple workaround for this problem. Just hide libOSMesa from wine. Just create a dummy empty libOSMesa and point wine to load it with LD_LIBRARY_PATH when starting civ3. Or delete it completely (I have no idea what app really needs this, everything works just fine w/o it).
BTW as I see it now the problem is ancient, the bug is in osmesa or in interfacing wine to osmesa dates back at least 2013. I did not notice it only because libosmesa was not installed back then.
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #57 from Scott shagooserver@gmail.com --- (In reply to Alexey Kuznetsov from comment #56)
FYI there is very simple workaround for this problem. Just hide libOSMesa from wine. Just create a dummy empty libOSMesa and point wine to load it with LD_LIBRARY_PATH when starting civ3. Or delete it completely (I have no idea what app really needs this, everything works just fine w/o it).
BTW as I see it now the problem is ancient, the bug is in osmesa or in interfacing wine to osmesa dates back at least 2013. I did not notice it only because libosmesa was not installed back then.
I can confirm that your suggestion works by changing the name of this file: /usr/lib/i386-linux-gnu/libOSMesa.so.8
Thank you.
https://bugs.winehq.org/show_bug.cgi?id=41930
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |e618ab65ed5b623785c58ea5ece | |6e39895d43063
https://bugs.winehq.org/show_bug.cgi?id=41930
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- URL| |https://gitlab.freedesktop. | |org/mesa/mesa/-/issues/5094
https://bugs.winehq.org/show_bug.cgi?id=41930
Sergiy Kukunin sergey.kukunin@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sergey.kukunin@gmail.com
--- Comment #58 from Sergiy Kukunin sergey.kukunin@gmail.com --- I built Bryan Varner's patched libmesa, merged the latest 22.1 upstream branch. Instead of messing with system files, I copied the built libmesa to the folder with game, and launch Civ3 as
env LD_LIBRARY_PATH=./libmesa/lib32 WINEPREFIX="/home/sergiy/.wine32" wine C:\Program\ Files\Civilization\ III\Conquests\Civ3Conquests.exe
The terrain is now rendered, but there are still visual glitches:
1. Bad colors as mentioned https://gitlab.freedesktop.org/mesa/mesa/-/issues/5095 2. Culture advisor screen is black 3. Diplomacy screen has relationships but does not have nation icons
There are the opposite problems with disabling OpenGL (via patching the library or removing libOSMesa.so.8) - there are no diplomacy relationships and army locations on the advisor screens
P.S. Special thanks to Bryan Varner for troubleshooting the issue. I feel you man.
https://bugs.winehq.org/show_bug.cgi?id=41930
ant maex@firstfloor.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maex@firstfloor.org
--- Comment #59 from ant maex@firstfloor.org --- hi
debian 11, wine-5.0.3
i added KeepRes=1 to conquests.ini as described and simply uninstalled the libosmesa6:i386, instead of manipulating the libOSMesa.so.8 and the black screen is gone. the game works very well, beside some sound issues.
thank you all for your investigations in this matter.
m
https://bugs.winehq.org/show_bug.cgi?id=41930
Vyacheslav Chigrin vyacheslav.chigrin@izba.dev changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |vyacheslav.chigrin@izba.dev
--- Comment #60 from Vyacheslav Chigrin vyacheslav.chigrin@izba.dev --- Hello, I spent few days debugging this game, and found 3 issues with graphics. 1. One already known bug with not properly initialized offline OSMesa context (many thanks to Bryan Varner for discovering it making fix for it). 2. Seems, game expects RGB 555 format for 16-bit bitmaps, whereas OSMesa use RGB 565. Due to that lines on "diplomaсy" screen were displayed in weird patterns. I locally fixed it by making "mirror" buffer between off-scrreen DIB and OSMesa, and converting colors between different formats during communications with OSMesa (hooked MakeCurrent and glFlush/glFinish). 3. Seems, game use both Windows GDI and OpenGL for drawing to the off-screen DIB at the same time! Due to that icons of the leaders on the diplomacy screen were missed. I locally fixed that by adding a lot of "notification" hooks at the end of GDI functions, and calling from them OSMesa to update it state of the DIB.
Draft of my changes can be found here https://github.com/vchigrin/wine/pull/1/files (it is based on Wine master few weeks ago).
I am asking what do you guys think of this approach? Is it possible that these changes may be accepted, or from architectural point of view something here should be done in other way? I suspect that from performance point of view these fixes are very ineffective.
https://bugs.winehq.org/show_bug.cgi?id=41930
Max Mad nirterigno@vusra.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nirterigno@vusra.com
--- Comment #61 from Max Mad nirterigno@vusra.com --- Hello.
I been able to play thanks to the all comments that were made here, so a big thanks for all of you.
I would like to know if its possible to share the binaries of the last comment, to test them(with the command i share in a few lines).
Today i found the way to 'override' or 'tell' wine to use certain libraries, not the ones installed in the system.
I used this for achieve what you said, to remove the black terrain(i used to delete the 'libOSMesa.so.8' file every time i updated.
For this, i made a 'dummy' library, inside a folder, located in .wine/.../Conquests/lib32
I created a dummy library inside using the following command(inside the directory):
touch libOSMesa.so.8
This create a empty library, which can be used with the next command.
To achieve what you said, i used the command suggested in this way:
LD_LIBRARY_PATH=./lib32/ wine Civ3Conquests.exe
I ran that command inside the Conquests folder of the game, and it worked!
PS: I'm around the sound problem too(used a workaround,still not full sound), if you have any hints, please share them :)
https://bugs.winehq.org/show_bug.cgi?id=51502
M.
https://bugs.winehq.org/show_bug.cgi?id=41930
khaled khaledouslet@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |khaledouslet@gmail.com
--- Comment #62 from khaled khaledouslet@gmail.com --- I confirm that the method mentioned by Mr Max Mad is working. I have seen 2 small issues so far : -The connections (lines showing trade embargo, war, trade etc) between different civilization in the foreign advisor tab does not show at all. -After playing for some time. Closing the game will make the screen visually stuck on the last frame. Saw some thread talking about vsync but I do not know.
In some earlier comment some one mentioned uninstalling the omesa library, I did that but game crashed, I have attached a zip containing my conquest ini and the back trace, I have reinstalled the library and I forgot the details of the crash. I cannot and do not want to reproduce it.
Regarding the sound issue I have seen it also playing with win 10 so it is not only on linux, I still have not seen it though.
6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Mon Nov 20 18:15:30 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
System information: Wine build: wine-6.0.3 (Ubuntu 6.0.3~repack-1) Platform: i386 (WOW64) Version: Windows 7 Host system: Linux Host version: 6.2.0-39-generic
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #63 from khaled khaledouslet@gmail.com --- Created attachment 75881 --> https://bugs.winehq.org/attachment.cgi?id=75881 backtrace after uninstalling libomesa
backtrace after uninstalling libomesa
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #64 from khaled khaledouslet@gmail.com --- Created attachment 75882 --> https://bugs.winehq.org/attachment.cgi?id=75882 conquest ini file
conquest ini file
https://bugs.winehq.org/show_bug.cgi?id=41930
--- Comment #65 from Max Mad nirterigno@vusra.com --- Hello khaled.
About the problem with the last frame, you can try to add the following to the start of your conquests.ini :
PlayIntro=0 KeepRes=1
So you will have it this way:
[Conquests] PlayIntro=0 KeepRes=1 and here a big etc.
This will skip the intro of the game and force the game to use a bigger resolution that the default ones.
About the lines not showing in the diplomacy tab, it is because when you make wine to use the 'dummy' library, it does not have the necessary code to write/draw those. When you run the game without the proper described method, you will see a black terrain, but the diplomacy lines will be present. Unfortunately it is something that in the current status of the bug is not solved. The previous methods that have been cited in here also have this issue. I have tried to use a old version of wine, the 2.0 which has not the black terrain problem, and the diplomacy lines are missing too.
Regarding the uninstall of libOSMesa, i used to remove just the 'libOSMesa.so.8' library, instead of uninstalling the corresponding package
About the sound, check https://bugs.winehq.org/show_bug.cgi?id=51502 , in where there is a partial workaround to play with some music and effects at least. If you see a problem in diplomacy sound, downgrading the wine version, or using a custom version of it have worked for me(check the URL in where i detail what i did). Some issues of the Civilizaiton 3 sound are solved in windows 10 or higher using a thing called 'indirect sound', there are several tutorials in internet on how to use it. This thing does has no effect into the wine sound.
M.
https://bugs.winehq.org/show_bug.cgi?id=41930
jpliberato@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpliberato@gmail.com
--- Comment #66 from jpliberato@gmail.com --- Tried to play Civ 3 today, GOG version, the bug persists. I found a patched executable at civfanatics that adds some QOL features to the game, while also fixing many bugs. Among the bugs fixed, it allows the game to run properly on Wine. https://forums.civfanatics.com/resources/c3x.28759/ Source code is available on github. Game is running without issues now. Wine 10-1 Arch Linux Intel HD 620 Graphics
-
wine-bugs＠winehq.org -
WineHQ Bugzilla