[Bug 2082] DirectDraw games only showing black screen

[wine-bugs at winehq.org]

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

--- Comment #108 from Ben Klein <shacklein at gmail.com> 2013-03-14 18:14:32 CDT ---
(In reply to comment #101)
> (In reply to comment #100)
> > But i still fail to understand how a bug that was reported in year 2004 has its
> > status named NEW.
> 
> I have been asking myself the same kind of questions. But it's the wine
> project, they are beyond our logic.

Wine does not typically use the ASSIGNED status in bugzilla. It's only in cases
where there is a single, definitive developer responsible for that component.
http://bugs.winehq.org/buglist.cgi?query_format=advanced&order=Importance&list_id=99240&bug_status=NEW&bug_status=ASSIGNED

(In reply to comment #104)
> (In reply to comment #103)
> > By configuring general translucency settings for dialogs to something like 50%
> > I could see the game's directdraw area(?) trough the covering dialog-window. 
> > 
> > I settled for 50% because when I need to undo the workaround, it's not nice to
> > work with completely transparent dialogues. (And for diablo it only matters
> > while navigating the menu. YMMV for other games.)
> 
> Interestingly enough, this is pretty much the same workaround people came up
> with for getting Worms Armageddon to work in Windows 8. I don't think that's a
> coincidence. (However, there are now better workarounds that have been
> discovered but they look Windows-specific).

It may be worthwhile posting the other workarounds here anyway. They may be
useful to users or developers looking at the problem.

> I also don't believe this would work in a virtual desktop

There's no obvious reason why it shouldn't. Please test it.

(In reply to comment #106)
> As to the Wine development and the question on why a 9 year old bug (!) is
> marked as NEW: It appears Wine is dead. No matter what they claim, action speak
> more than words. Does anyone know of a Wine fork by someone who actually gives
> a #$%&?

Mind your language.

This bug is more complicated than it seems on the face of it. It's an
incongruence between the way Windows draws its windows and the way X11 draws
its windows, caused essentially by a bug in native Windows. Implementing the
"hacks" to get it fixed presents two major problems:
1) It would definitely break other programs (solved by making it an
app-specific registry flag)
2) It's simply the "wrong way" to do it

The truth is apps affected by this bug are incorrectly using the desktop
window, triggering the bug that makes them display on native Windows. Wine's
current behaviour is the technically "correct" way; Windows 8 reportedly
suffers from the same problem running these apps. That's not to say that this
bug can't be fixed; it's just a highly complicated and very low priority issue.

There are only four apps reported to suffer from this bug.
http://appdb.winehq.org/viewbugs.php?bug_id=2082 As much as I'd love to see it
get fixed, for the one people are most vocal about (Diablo) it's a minor issue
that does not effect main gameplay (the menu scheme can be
memorised/transcribed from a Windows system if you so wish), and the second
most popular app (Worms Armageddon) has received an official patch that
includes a workaround.

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