[Bug 2082] DirectDraw games only showing black screen

[wine-bugs at winehq.org]

https://bugs.winehq.org/show_bug.cgi?id=2082

--- Comment #139 from Henri Verbeet <hverbeet at gmail.com> ---
(In reply to comment #138)
> (In reply to comment #136)
> 
> >   - The main thing I'm wondering about is if it wouldn't make more sense to
> > pass a window to wglCreateFullscreenDCWINE(). Some of the considerations
> > there are what should happen when the device window is e.g. destroyed or
> > minimized.
> 
> It seems like knowing how to respond to such events should be the
> responsibility of ddraw/d3d.  The driver can provide the tools necessary for
> those to implement the proper behavior.  If we know what those are, we can
> add them to the extension.
> 
It's mostly that I have the impression that at least in d3d8 and d3d9 the way
it conceptually works is that D3D draws to a DC retrieved by GetWindowDC() on
the device window. I don't really have tests to back that up though, and even
then ddraw could very well be different.

> >   - When there are multiple threads drawing, wglCreateFullscreenDCWINE() is
> > going to be called multiple times for the same window / display. I didn't
> > really review the winemac.drv changes, but will it do the right thing in
> > that case?
> 
> Good question.
> 
> The implementation in the patch creates a single Cocoa window for all
> full-screen DCs.  So the rendering from all contexts would go to the same
> drawable.  Currently, there's also a single pixel format tracked, although
> it always allows the pixel format to be changed even if it was already set. 
> That's almost certainly wrong.  I was planning to change that to track the
> pixel format per DC in which case I'd probably enforce the usual rules about
> changing it.  I'm not sure that's right, either.  Does it make sense for
> multiple callers to create separate DCs with separate pixel formats but
> sharing a drawable?
> 
The pixel format should always be the same between threads / contexts belonging
to the same swapchain. The main variable that has an influence on the pixel
format is the swapchain's backbuffer format.

> Here's another approach to that same question.  What if the
> WGL_WINE_fullscreen_dc extension didn't add any new functions?  What if it
> simply indicated that doing OpenGL on the screen DC returned by GetDC(0) was
> allowed and full-featured?  Then, the change to wined3d would be to simply
> use GetDC(0) for a full-screen swapchain.  Releasing the DC could go through
> ReleaseDC() (and maybe wined3d_release_dc() with some tweaking).
> 
Looking at the MSDN for GetWindowDC(), we'd probably want that to either be
CreateDC() for the appropriate driver, or GetWindowDC() on the device window. I
do think we'd want some way for the caller to have to explicitly request this
behaviour, perhaps through a custom MakeCurrent() as proposed earlier.

> Would that work?  What about the issue with the pixel format?  Are there
> other issues?
A somewhat related issue is that for applications using OpenGL, the DC is
visible through wglGetCurrentDC(). I don't know if that will necessarily break
anything, but I wouldn't be terribly surprised if it did. (See also e.g. bug
29934 and bug 28869.) Ideally the wined3d GL context, pixel format, etc. would
be completely invisible to the application, but that would probably require
some equivalent of context_enter() / context_release() in winex11 / winemac.
Also slightly related to this bug are bug 29301 and bug 30062.

-- 
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.