[Bug 2082] DirectDraw games only showing black screen

[wine-bugs at winehq.org]

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

--- Comment #84 from Stefan Dösinger <stefandoesinger at gmx.at> 2011-07-07 17:38:23 CDT ---
Created an attachment (id=35470)
 --> (http://bugs.winehq.org/attachment.cgi?id=35470)
A slightly nicer hack

This hack makes the software emulated ddraw implementation render to the device
window or clipper window. The device window is NULL in most cases, so the ddraw
app will essentially render to the screen, overwriting the content of all
Windows(including possible child Windows).

This is broken in a rather bad way, but that's what native ddraw does. It is
also broken in native ddraw, and Windows Vista and newer will disable Aero when
an app attempts to use ddraw without a clipper in Windowed mode. In Fullscreen
mode it most likely disables Aero anyway, so the apps still get away with this
behavior. The draw-to-screen behavior can be observed in the d3d7 SDK's "Font"
sample, like on this screenshot:
http://web.student.tuwien.ac.at/~e0526822/ddrawtoscreen.bmp

Drawing to the screen basically works in X11, but only as long as no
compositing Window manager is active(Compiz for example). If Compiz is enabled
the rendering will most likely go nowhere. Using a virtual desktop may also
help, this way Wine still renders to a proper X11 window from the window
managers point of view. In anyway rendering to a NULL window does not work with
opengl-accelerated ddraw or direct3d. OpenGL needs a Window to render to. The
only alternative is rendering to an offscreen buffer, but then the rendering
results don't show up either.

The hack needs improvements in a few ways:
*) Don't do this in Windowed mode, only fullscreen. If we're in Windowed mode
cling to any window the app passes to ddraw, otherwise we make bug 1347
worse(Bug 1347 is essentially the opposite of this bug, where the app doesn't
provide any Window and runs amok when locking the front buffer)

*) Test if using the device window in this way is correct. You can do this by
extending the test app and call SetCooperativeLevel with DDSCL_SETDEVICEWINDOW
and your partially obscured window, and probably pass NULL or a different
window to the DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE SetCooperativeLevel call.
DDSCL_SETDEVICEWINDOW needs IDirectDraw7 I think.

*) Test what the behavior is when DDSCL_FULLSCREEN is used without
DDSCL_EXCLUSIVE.

*) Test clippers in fullscreen mode. E.g. try to set your obscured window as a
clipping window and see how Windows reacts(CreateClipper, Surface::SetClipper &
friends)

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