The game starts and runs fine except that the screen remains black during the intro videos and in the menu, only audio can be heard.
This is with the default OpenGL renderer in Wine. When using the legacy GDI renderer the game displays properly.
From the http://wiki.winehq.org/UsefulRegistryKeys page:
"The "gdi" option mostly exists for legacy reasons. Aside from bugs in the GL
renderer, only change this if you have a setup without OpenGL. Installing a software GL implementation is the preferred solution in that case though."
The problem doesn't occur with the binary drivers.
When using the software renderer (LIBGL_ALWAYS_SOFTWARE=1) 2 out of the 4 intro videos and the menu is displayed properly.
The trace consists of only a single frame which contains >100k calls.
Fedora 22 32-bit
VGA compatible controller: NVIDIA Corporation G92 [GeForce GTS 250] (rev a2) (prog-if 00 [VGA controller])
Replays fine with glretrace --sb (at least I think it does). If there's only a single giant frame, that sounds like the definition of single buffering...
Tested on both nvc0 (GF108) and nv50 (GT215).
In case it is a problem in Wine I reported the bug in their bugtracker as well:
Single buffering is pretty much expected for ddraw applications. You should be seeing framebuffer blits followed by a glFlush() instead of a glXSwapBuffers() call. I can't rule out that this is a bug in Wine, although the fact that it works with the proprietary driver and mostly works with software rendering seems to suggest it probably isn't.
One thing that's a bit nasty about ddraw applications in general is that they often end up with multiple (independent) GL contexts, not sure if that's the case here or not.
Ah yeah, nouveau fails pretty substantially at multiple concurrent GL contexts used simultaneously from different threads (this is a nouveau shortcoming, not a mesa one). Multiple contexts that are switched around with glXMakeCurrent from a single thread should operate fine though.
Indeed looking at the trace, I see
79407 glBindFramebuffer(target = GL_DRAW_FRAMEBUFFER, framebuffer = 0)
79409 glReadBuffer(mode = GL_COLOR_ATTACHMENT0)
79412 glDrawBuffer(mode = GL_FRONT)
79417 glBlitFramebuffer(srcX0 = 0, srcY0 = 0, srcX1 = 1024, srcY1 = 768, dstX0 = 0, dstY0 = 768, dstX1 = 1024, dstY1 = 0, mask =
GL_COLOR_BUFFER_BIT, filter = GL_NEAREST)
followed immediately by creating a (actually two!) new contexts, and discarding the old stuff. [Looks like it does both glXCreateContext *and* glXCreateContextAttribsARB, and discards the first one of those.]
I was looking over what flush did, and it does indeed explicitly flush the frontbuffer to screen if it's the current drawbuffer. [or something along those lines]. Tracing through that flow, it's entirely over my head... interactions between multiple modules of which I know nothing. I don't see anywhere where it'd be waiting for that blit to complete either, but that doesn't mean it's not there. Perhaps this should be a glFinish()?
I'm afraid this will have to wait for someone to understand what the issue is before it can be fixed.
(In reply to Ilia Mirkin from comment #4)
> discarding the old stuff. [Looks like it does both glXCreateContext *and*
> glXCreateContextAttribsARB, and discards the first one of those.]
Yeah... we first need a context to be able to call wglGetProcAddress(), to get the wglCreateContextAttribsARB() pointer.
> I was looking over what flush did, and it does indeed explicitly flush the
> frontbuffer to screen if it's the current drawbuffer. [or something along
> those lines]. Tracing through that flow, it's entirely over my head...
> interactions between multiple modules of which I know nothing. I don't see
> anywhere where it'd be waiting for that blit to complete either, but that
> doesn't mean it's not there. Perhaps this should be a glFinish()?
We don't wait for it to finish, but we shouldn't have to.
Some frontbuffer-related fixes went into mesa 11.0.3. Can you check if the issue persists?
(In reply to Ilia Mirkin from comment #6)
> Some frontbuffer-related fixes went into mesa 11.0.3. Can you check if the
> issue persists?
The black screen issue is still present, tested with mesa git and wine 1.7.53..
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV92
OpenGL core profile version string: 3.3 (Core Profile) Mesa 11.1.0-devel (git-3994ef5)
OpenGL core profile shading language version string: 3.30
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1076.