[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(a)winehq.org Reporter: gyebro69(a)gmail.com CC: michael(a)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(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #1 from Béla Gyebrószki <gyebro69(a)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(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #2 from Béla Gyebrószki <gyebro69(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Nick <nick0515(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nick0515(a)gmail.com --- Comment #3 from Nick <nick0515(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #4 from Béla Gyebrószki <gyebro69(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 pietro.stroia(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pietro.stroia(a)gmail.com --- Comment #5 from pietro.stroia(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 gu3(a)gmx.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gu3(a)gmx.com --- Comment #6 from gu3(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Jonas Aaberg <cja(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cja(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #7 from Jonas Aaberg <cja(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #8 from gu3(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #9 from gu3(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 thibaut.broggi(a)protonmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thibaut.broggi(a)protonmail.c | |om --- Comment #10 from thibaut.broggi(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #11 from Jonas Aaberg <cja(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #12 from Jonas Aaberg <cja(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 zzzzzyzz(a)hacari.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz(a)hacari.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 vapespb <vapespb(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vapespb(a)gmail.com --- Comment #13 from vapespb <vapespb(a)gmail.com> --- Created attachment 63404 --> https://bugs.winehq.org/attachment.cgi?id=63404 civilization 3 wine black terrain -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #14 from vapespb <vapespb(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Peter <peter.milner+wine(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.milner+wine(a)gmail.com --- Comment #15 from Peter <peter.milner+wine(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #16 from vapespb <vapespb(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Mateusz <m.jedrasik(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.jedrasik(a)gmail.com --- Comment #17 from Mateusz <m.jedrasik(a)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! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #18 from Mateusz <m.jedrasik(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 wbaudler(a)gb.nrao.edu changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wbaudler(a)gb.nrao.edu --- Comment #19 from wbaudler(a)gb.nrao.edu --- Same problem with Civilization III Gold on Ubuntu 18.04 and wine 4.18 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #20 from cyberbaud <wbaudler(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 nate <nathannichols454(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nathannichols454(a)gmail.com --- Comment #21 from nate <nathannichols454(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #22 from Peter <peter.milner+wine(a)gmail.com> --- Hmm. I don't have any instances of 0x6383 in gdi32.dll when I open it in a hex editor ... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #23 from nate <nathannichols454(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Bryan Varner <bryan(a)varnernet.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bryan(a)varnernet.com --- Comment #24 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #25 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Vijay Kamuju <infyquest(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |infyquest(a)gmail.com --- Comment #26 from Vijay Kamuju <infyquest(a)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. */ -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #27 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #28 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #29 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1|e618ab65ed5b623785c58ea5ece | |6e39895d43063 | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #30 from Bryan Varner <bryan(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #31 from Bryan Varner <bryan(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #32 from nate <nathannichols454(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 mo78(a)abv.bg changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mo78(a)abv.bg --- Comment #33 from mo78(a)abv.bg --- The bug is still here in Wine 5.19. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Atilla ÖNTAŞ <tarakbumba(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tarakbumba(a)gmail.com --- Comment #34 from Atilla ÖNTAŞ <tarakbumba(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 babybishops(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |babybishops(a)gmail.com --- Comment #35 from babybishops(a)gmail.com --- Created attachment 69209 --> https://bugs.winehq.org/attachment.cgi?id=69209 Patched DLL as per comment #20 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #36 from babybishops(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Trevor Cordes <winehq(a)tecnopolis.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq(a)tecnopolis.ca --- Comment #37 from Trevor Cordes <winehq(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #38 from Trevor Cordes <winehq(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #39 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 clabbe.montjoie(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clabbe.montjoie(a)gmail.com --- Comment #40 from clabbe.montjoie(a)gmail.com --- The patch from comment 25 does not apply anymore on wine 6.12, but the bug is still present. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #41 from clabbe.montjoie(a)gmail.com --- But the patch from comment 38 fixes the issue on wine 6.12. Thanks -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #42 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #43 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #44 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #45 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #46 from Bryan Varner <bryan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #47 from Bryan Varner <bryan(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Scott <shagooserver(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |shagooserver(a)gmail.com --- Comment #48 from Scott <shagooserver(a)gmail.com> --- Same problem, Kubuntu 21.04 Nvidia 1080 Wine 6.15 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #49 from Scott <shagooserver(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #50 from Scott <shagooserver(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 tomsod-m(a)ya.ru changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomsod-m(a)ya.ru --- Comment #51 from tomsod-m(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #52 from Scott <shagooserver(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #53 from Scott <shagooserver(a)gmail.com> --- It's not just settlers that crash the game, it crashes randomly and frequently, unplayable. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #54 from tomsod-m(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #55 from Scott <shagooserver(a)gmail.com> --- Comment 46 points to the mesa fix but I just cannot build it despite several tries. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Alexey Kuznetsov <alexey.n.kuznetsov(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alexey.n.kuznetsov(a)gmail.co | |m --- Comment #56 from Alexey Kuznetsov <alexey.n.kuznetsov(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #57 from Scott <shagooserver(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |e618ab65ed5b623785c58ea5ece | |6e39895d43063 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://gitlab.freedesktop. | |org/mesa/mesa/-/issues/5094 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Sergiy Kukunin <sergey.kukunin(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sergey.kukunin(a)gmail.com --- Comment #58 from Sergiy Kukunin <sergey.kukunin(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 ant <maex(a)firstfloor.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maex(a)firstfloor.org --- Comment #59 from ant <maex(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Vyacheslav Chigrin <vyacheslav.chigrin(a)izba.dev> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vyacheslav.chigrin(a)izba.dev --- Comment #60 from Vyacheslav Chigrin <vyacheslav.chigrin(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 Max Mad <nirterigno(a)vusra.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nirterigno(a)vusra.com --- Comment #61 from Max Mad <nirterigno(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 khaled <khaledouslet(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |khaledouslet(a)gmail.com --- Comment #62 from khaled <khaledouslet(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #63 from khaled <khaledouslet(a)gmail.com> --- Created attachment 75881 --> https://bugs.winehq.org/attachment.cgi?id=75881 backtrace after uninstalling libomesa backtrace after uninstalling libomesa -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #64 from khaled <khaledouslet(a)gmail.com> --- Created attachment 75882 --> https://bugs.winehq.org/attachment.cgi?id=75882 conquest ini file conquest ini file -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #65 from Max Mad <nirterigno(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=41930 jpliberato(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jpliberato(a)gmail.com --- Comment #66 from jpliberato(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #67 from Hans Leidekker <hans(a)meelstraat.net> --- Wine no longer uses OSMesa, please retest. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #68 from Béla Gyebrószki <gyebro69(a)gmail.com> --- (In reply to Hans Leidekker from comment #67)
Wine no longer uses OSMesa, please retest.
The bug is not reproducible without OSMesa. The terrain looks good to me in wine-10.18-229-g0fc31f45624 when no OSMesa support is present. NVIDIA 580.105.08 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #69 from jpliberato(a)gmail.com --- Tested today. Wine 10.18. Intel UHD Graphics. Fresh install of civ 3. The bug is no longer reproducible on my system. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #70 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to jpliberato from comment #69)
Tested today. Wine 10.18. Intel UHD Graphics. Fresh install of civ 3. The bug is no longer reproducible on my system.
Thanks. Béla, can we close this bug? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 --- Comment #71 from Béla Gyebrószki <gyebro69(a)gmail.com> --- (In reply to Hans Leidekker from comment #70)
(In reply to jpliberato from comment #69)
Tested today. Wine 10.18. Intel UHD Graphics. Fresh install of civ 3. The bug is no longer reproducible on my system.
Thanks. Béla, can we close this bug?
Sure, feel free to close this bug report. I just wasn't sure what the correct resolution to this bug report would have been: fixed or wontfix ? (because the bug would still exist if OSMesa support had not been dropped in both recent Mesa and Wine). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 Hans Leidekker <hans(a)meelstraat.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #72 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Béla Gyebrószki from comment #71)
(In reply to Hans Leidekker from comment #70)
(In reply to jpliberato from comment #69)
Tested today. Wine 10.18. Intel UHD Graphics. Fresh install of civ 3. The bug is no longer reproducible on my system.
Thanks. Béla, can we close this bug?
Sure, feel free to close this bug report. I just wasn't sure what the correct resolution to this bug report would have been: fixed or wontfix ? (because the bug would still exist if OSMesa support had not been dropped in both recent Mesa and Wine).
I guess WORKSFORME is fine as a resolution is this case. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #73 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- Hello, Wasn't the original bug in OSMesa? https://gitlab.freedesktop.org/mesa/mesa/-/issues/5094 Shouldn't this bug be resolved NOTOURBUG and be closed, as the Mesa bug is closed? Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=41930 Gijs Vermeulen <gijsvrm@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #74 from Gijs Vermeulen <gijsvrm@gmail.com> --- Closing WORKSFORME. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (3)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla -
WineHQ Bugzilla