[Bug 34398] New: Daedalic games don't display anything with winemac.drv
http://bugs.winehq.org/show_bug.cgi?id=34398 Bug #: 34398 Summary: Daedalic games don't display anything with winemac.drv Product: Wine Version: 1.7.1 Platform: x86 OS/Version: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: winemac.drv AssignedTo: wine-bugs(a)winehq.org ReportedBy: thanoulas(a)gmail.com Classification: Unclassified Created attachment 45793 --> http://bugs.winehq.org/attachment.cgi?id=45793 err+all,fixme+all With winemac driver The games "Chains of Satinav" and "Memoria" show a black display when using the winemac driver. They both work fine when using the x11 driver. I've attached a log -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 thanoulas <thanoulas(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thanoulas(a)gmail.com -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ken(a)codeweavers.com --- Comment #1 from Ken Thomases <ken(a)codeweavers.com> 2013-10-02 14:40:15 CDT --- Please collect two logs, one using the Mac driver and the other using the X11 driver, with these logging channels: +tid,+wgl,+d3d,+display. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #2 from thanoulas <thanoulas(a)gmail.com> 2013-10-02 18:12:42 CDT --- Created attachment 46174 --> http://bugs.winehq.org/attachment.cgi?id=46174 Memoria Wine 1.7.3 WINEMAC.DRV Channels +tid,+wgl,+d3d,+display, Winemac.drv -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #3 from thanoulas <thanoulas(a)gmail.com> 2013-10-02 18:13:38 CDT --- Created attachment 46175 --> http://bugs.winehq.org/attachment.cgi?id=46175 Memoria Wine 1.7.3 X11.DRV Memoria +tid,+wgl,+d3d,+display Channels -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #4 from Ken Thomases <ken(a)codeweavers.com> 2013-10-07 17:28:45 CDT --- Thanks for those logs. There are very few significant differences that I can see. One difference is the pixel format selected. Besides 32-bit color, double-buffer, and acceleration, the request asks for a 16-bit depth buffer. The X11 driver provides a pixel format with a 24-bit depth buffer even though it could match the request exactly. The Mac driver does match the request exactly and provides a pixel format with the requested 16-bit depth buffer. It's not clear if that makes a difference. The other difference is that the X11 driver ignores a request to enable vsync, because the X server doesn't implement it. The Mac driver honors the request. That shouldn't make any difference. In case it does, you can try setting the following registry setting to disable vsync in the Mac driver: [HKEY_CURRENT_USER\Software\Wine\Mac Driver] "AllowVerticalSync"="n" -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #5 from thanoulas <thanoulas(a)gmail.com> 2013-10-08 02:21:36 CDT --- (In reply to comment #4)
Thanks for those logs. There are very few significant differences that I can see.
One difference is the pixel format selected. Besides 32-bit color, double-buffer, and acceleration, the request asks for a 16-bit depth buffer. The X11 driver provides a pixel format with a 24-bit depth buffer even though it could match the request exactly. The Mac driver does match the request exactly and provides a pixel format with the requested 16-bit depth buffer. It's not clear if that makes a difference.
The other difference is that the X11 driver ignores a request to enable vsync, because the X server doesn't implement it. The Mac driver honors the request. That shouldn't make any difference. In case it does, you can try setting the following registry setting to disable vsync in the Mac driver:
[HKEY_CURRENT_USER\Software\Wine\Mac Driver] "AllowVerticalSync"="n"
Thanks. The vertical sync setting didn't change anything. I can still hear the sound playing in the background, but I don't see anything rendered on screen. I also checked the configuration file for the game, and I didn't find any settings for the depth buffer or vsync. So I guess it could be possible that the 16-bit depth buffer is breaking it? Any way to force a 24-bit instead, like X11 does? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #6 from thanoulas <thanoulas(a)gmail.com> 2013-10-08 18:03:52 CDT --- Ok, found this in the OpenGL implementation of glxChooseFBConfig: GLX_DEPTH_SIZE Must be followed by a nonnegative minimum size specification. If this value is zero, frame buffer configurations with no depth buffer are preferred. Otherwise, the largest available depth buffer of at least the minimum size is preferred. The default value is 0. http://www.opengl.org/sdk/docs/man2/xhtml/glXChooseFBConfig.xml
From my (little) understanding of the source code, the X11 driver is using glxChooseFBConfig, where the mac driver has its own selection routine. The problem is that glxChooseFBConfig is going to return the "largest available depth buffer of at least the minimum size", so since the largest one is 24bit (and not 16bit), this is why it returns that FBConfig. Winemac on the other hand, returns the best match, which is exactly what was requested. This may (or may not) be the cause of this issue, as I guess the expected behaviour is to get the largest depth size.
-- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #7 from thanoulas <thanoulas(a)gmail.com> 2013-10-08 19:01:53 CDT --- More updates. Forcing a 24-bit depth buffer didn't fix the issue. I saw another thing in the debug log, though, and correct me if I'm wrong, but doesn't 0009:trace:wgl:set_win_format created GL view 0x79627d30 in window 0x7a313400 at (0,0)-(10,10) mean that the GL view's size is 10x10 pixels? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #8 from Ken Thomases <ken(a)codeweavers.com> 2013-10-08 19:46:43 CDT --- Thanks for looking into this. I appreciate the additional eyes. That spec for glxChooseFBConfig() is interesting and explains the X11 driver's behavior. The question is, how is wglChoosePixelFormatARB() supposed to behave. Does it have a similar documented bias toward deeper depth buffers. (That bias is a bit weird, though. Why support multiple depth buffer sizes for otherwise-identical pixel formats? Why not just have 0 and max if the intermediate ones aren't going to be chosen?) The spec for wglChoosePixelFormatARB() says that the returned pixel format's depth buffer must equal or exceed the requested WGL_DEPTH_BITS_ARB. Beyond that, it says that the best pixel formats are returned earlier in the list but that the definition of "best" is device-specific. https://www.opengl.org/registry/specs/ARB/wgl_pixel_format.txt Regarding the 10x10 window: I believe that that is the temporary window created by WineD3D when it probes the GL capabilities. http://source.winehq.org/source/dlls/wined3d/directx.c?v=wine-1.7.3#L326 The log shows another GL view being created later. That has a more sensible size: 0009:trace:wgl:set_win_format created GL view 0x7ba52f90 in window 0x7bd3de20 at (0,0)-(1440,887) Another thing occurs to me. I wonder if the games are using glu32. Glu32 is one of the only places (maybe the only place) left outside of winex11.drv where Wine has a dependency on X11. So, glu32 can work when the X11 driver is in use but can't with the Mac driver. Sometimes that results in crashes, but sometimes just in failure to render. The +glu debugging channel is mostly worthless. I think a +module log would show if glu32 is loaded. A +relay log would definitely show calls into glu32, but seems like overkill. You could also try disabling glu32 using a DLL override. That would probably result in the games failing to launch with either driver. If you care to, you could also test with CrossOver, which has a hack to support glu32 with the Mac driver. (Alexandre doesn't want that hack in Wine. He has an idea for how to fix glu32 properly, but not the time to do it.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #9 from Henri Verbeet <hverbeet(a)gmail.com> 2013-10-09 04:22:20 CDT --- (In reply to comment #8)
Regarding the 10x10 window: I believe that that is the temporary window created by WineD3D when it probes the GL capabilities.
Provided the logs attached to this bug are complete, wined3d isn't involved here. (There are no +d3d traces in the attached logs.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #10 from thanoulas <thanoulas(a)gmail.com> 2013-10-09 04:58:31 CDT --- You are both right, d3d is not used. I haven't specifically checked for glu32 yet, but there are "OpenGL" settings in the games' config files. I'll do proper checks later when I get back home, and post further results both with wine and crossover. Ken, is this glu32 macdrv crossover patch available somewhere? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #11 from Ken Thomases <ken(a)codeweavers.com> 2013-10-09 09:04:35 CDT --- (In reply to comment #9)
Provided the logs attached to this bug are complete, wined3d isn't involved here. (There are no +d3d traces in the attached logs.)
Oh, right. I forgot that the logging channels included +d3d. I guess the game also uses a 10x10 window to probe GL capabilities. (It's always possible there's a bug in the Mac driver causing that spurious 10x10 GL view, but it wouldn't be my first guess.) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #12 from Ken Thomases <ken(a)codeweavers.com> 2013-10-09 09:10:47 CDT --- (In reply to comment #10)
Ken, is this glu32 macdrv crossover patch available somewhere?
Well, the full Wine sources from CrossOver are available as a tarball here: http://www.codeweavers.com/products/faq/source/ The glu32 hack isn't currently available as separate patches. I recall it being a small handful of commits. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #13 from thanoulas <thanoulas(a)gmail.com> 2013-10-09 13:35:12 CDT --- So just to confirm the +module, here's an extract of the glu32 calls: trace:module:get_load_order looking for L"C:\\windows\\system32\\GLU32.dll" trace:module:get_load_order got hardcoded default for L"GLU32.dll" trace:module:load_dll L"C:\\windows\\system32\\GLU32.dll" is a fake Wine dll trace:module:load_builtin_dll Trying built-in L"GLU32.dll" trace:module:load_builtin_callback loaded glu32.dll 0x113000 0x40f90000 trace:module:load_dll Loaded module L"C:\\windows\\system32\\GLU32.dll" (builtin) at 0x40f90000 trace:module:process_attach (L"glu32.dll",0x1) - START trace:module:MODULE_InitDLL (0x40f90000 L"glu32.dll",PROCESS_ATTACH,0x1) - CALL trace:module:process_attach (L"glu32.dll",0x1) - END -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #14 from thanoulas <thanoulas(a)gmail.com> 2013-10-10 02:36:23 CDT --- Chains of Satinav seems to be working fine in Crossover 12.5 with the mac driver. On wine it doesn't, so I guess it's possibly the glu bug -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #15 from thanoulas <thanoulas(a)gmail.com> 2013-10-10 02:39:32 CDT --- Ken, do you at least remember if the commits were all in the winemac.drv files, or other files as well? I could try and compile wine with crossover's winemac.drv and any other changed files, to see if that fixes it in Wine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #16 from Ken Thomases <ken(a)codeweavers.com> 2013-10-10 10:39:12 CDT --- It was not limited to just the Mac driver. It touched the configure script, glu32, opengl32, winex11, and winemac, at least. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #17 from Ken Thomases <ken(a)codeweavers.com> 2013-10-10 17:36:28 CDT --- Created attachment 46259 --> http://bugs.winehq.org/attachment.cgi?id=46259 Make glu32 get the system GLU via the graphics driver Here's a patch for decoupling glu32 from X11. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 --- Comment #18 from thanoulas <thanoulas(a)gmail.com> 2013-10-10 18:48:10 CDT --- (In reply to comment #17)
Created attachment 46259 [details] Make glu32 get the system GLU via the graphics driver
Here's a patch for decoupling glu32 from X11.
Amazing! Thanks a lot for the patch, you saved me a LOT of hours! It works perfectly, too, so I think I can confirm that winemac is breaking glu for these two games at least (I guess more opeDL games would be affected) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 Ken Thomases <ken(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Daedalic games don't |Daedalic games don't |display anything with |display anything with |winemac.drv |winemac.drv (glu32 is tied | |to X11) -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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=34398 WineBuG <winebugs140(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |winebugs140(a)gmail.com -- 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=34398 Jerome Leclanche <adys.wh(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #19 from Jerome Leclanche <adys.wh(a)gmail.com> --- (In reply to Ken Thomases from comment #17) What's the status on that patch, out of curiousity? -- 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=34398 --- Comment #20 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to Jerome Leclanche from comment #19)
(In reply to Ken Thomases from comment #17) What's the status on that patch, out of curiousity?
The patch is a hack. This approach is not expected to get accepted. Alexandre doesn't want us to use the platform-native GLU for Wine. He wants Wine's glu32 to be a full GLU implementation based on opengl32 in the same way that the platform-native libGLU is based on the platform-native libGL. The problem is that the GLU source implementations that are available use C++, which isn't acceptable for Wine. So, one choice is to C-ify such an implementation. I looked into that at one point, but it's hard. Another approach would be to build the Win32 version of those GLU sources as an external dependency, like Gecko or Mono. So, it wouldn't be incorporated in Wine as such and could still be based on C++. To my knowledge, nobody's working on either approach. -- 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=34398 --- Comment #21 from Austin English <austinenglish(a)gmail.com> --- This is your friendly reminder that there has been no bug activity for over a year. Is this still an issue in current (1.7.51 or newer) 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.
https://bugs.winehq.org/show_bug.cgi?id=34398 --- Comment #22 from Ken Thomases <ken(a)codeweavers.com> --- This is still an issue with Wine 1.7.51. -- 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=34398 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #23 from Gijs Vermeulen <gijsvrm(a)gmail.com> --- This is fixed now. I tested Chains of Satinav (GOG) and it works fine. I checked a +loaddll to check if it loaded glu32 and it did. I'm not sure exactly which commit/range of commits fixed it. -- 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=34398 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #24 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 6.7. -- 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 (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla