sheer output got after some immediate presses of Esc to get back to console:

[/home/s2]$ wine /home/s2/cc/Program Files/Diablo/diablo.exe
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
Could not stat /mnt/fd0 (No such file or directory), ignoring drive A:
fixme:console:SetConsoleCtrlHandler ((nil),1) - no error checking or testing yet
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x402533a8)->(00010021,00000013)
err:x11settings:X11DRV_ChangeDisplaySettingsExW No matching mode found!
(XF86VidMode)
fixme:xvidmode:X11DRV_XF86VM_SetCurrentMode Cannot change screen BPP from 16 to 8
fixme:xvidmode:X11DRV_XF86VM_SetCurrentMode Cannot change screen BPP from 16 to 8
fixme:x11drv:X11DRV_DDHAL_CreatePalette stub
fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x402533a8)->(flags=0x00000001,handle=(nil))
fixme:dsound:IDirectSoundImpl_SetCooperativeLevel level=DSSCL_EXCLUSIVE not
fully supported
err:dialog:EndDialog got invalid window handle (0x10022); buggy app !?
fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x402533a8)->(flags=0x00000001,handle=(nil))
err:dialog:EndDialog got invalid window handle (0x20022); buggy app !?
fixme:winmm:MMDRV_Exit Closing while ll-driver open

Created attachment 562 [details]
WINEDEBUG="+x11settings,+ddraw,+process"

game seems to launch second copy of itself, hence "process" channel was added. 


question: has the problem something to do with some palette stuff?

I can confirm the same bug with wine CVS. Please change status.
For me, ALT-TAB does not help - the black screen will not go away until I manage
to start a game blindly. 

I see a lot of those:

fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x402533a8)->(flags=0x00000001,handle=(nil))

Ivan... Please use the link above the box where you wrote that comment to vote
for the bug...  It says Votes in red.  Then it says show votes for this bug and
"vote for this bug"... Click that 2nd link...  That will confirm the bug.  If
ever you see a bug that has been reported, and you are experiencing the same
issue, but it has not been confirmed, please use that voting button to confirm it..

Doesn't look like it - voted and still unconfirmed.

Dustin, thanks for the tutorial.  I just have voted for my own bug.  yeah! :-]

Ivan, as I've told your bugreport, you may want walking back from date of
"2005/03/21 06:37:00" to the past in your CVS tree.  Or you may try using
official Wine release 20050310.  This should render Diablo UI being more usable.
 The offending patch [1] is OK AFAIK, but X11DRV library should be tuned up more
to get Diablo1 alive and kicking.  I hope this to happen soon.

And yes, Ivan, thanks for correcting me: I need to switch with Alt-Tab (to next
application) and not to the next workspace using Ctrl-Alt-Tab (which doesn't
help much).

And after yesterday's cvs-update I am unable to run the game at all.  It says
being unable to set some video mode or so.  Hence, updating yet another, similar
old bug [2] created by me and reporting to it.


[1] http://www.winehq.org/hypermail/wine-cvs/2005/03/0404.html
[2] http://bugs.winehq.org/show_bug.cgi?id=2081

please re-test with latest version

The bug remains.  Should I try to describe it using another words?  My setup is:

$ rpm -q XFree86 blackbox kernel glibc
| XFree86-4.3.0-45.fdr.3.rh80
| blackbox-0.65.0-fr2
| kernel-2.6.11-1.1369_FC4
| glibc-2.3.5-10

I run game in a fullscreen mode.

The game is launched.  It replays its intro video (using SMACK32 lib), then it
should display large Diablo Logo.  Here occurss bug point number

1 - I see black screen instead of Diablo Logo.

Actually logo can be seen if I switch to next application window and back.  Ok,
going futher.  After I press any key or after some timeout Main Menu of the game
should be display.  Here we have bug point number

2 - I see black screen instead of Main Menu.

Of course, previous tactics mostly works here too - I press Alt-Tab twice and
the see Main Menu was redrawn.  Still, that happens not every time.  On about a
50% of all cases nothing is redrawn and I see just a bitmap-copy of my terminal
window. :-(

Next. Diablo Mini-logo should be rendered above the menu buttons.  It isn't the
case, as this area stays black in a case of succesfull redrawing.  Bug point number

3 - Diablo Mini-logo isn't drawn at most of times.

You can go to another menu screens, and back, but Mino-logo most often stays
black.  Someone may be interested in the difference between this, updated
version (v1.09) of the game and original its version (v1.00), which draws some
garbage in Mini-logo area.  And garbage looks different every time you switch
game screens forth and back. I probably will file another bug report on this
(v1.00) with screenshots attached.

Now on menu.  It should be navigatable using mouse and keyboard, but that's a
hard task.  Keyboard input works, if screen before making input was redrawn OK,
but menu selection indicators stays static, when they should present dynamic
animation (of spinning pentagram) by itself. Though, if you move mouse over
selected menu item, static picture of animation frame sometimes jumps to the
next one.  Note that in v1.00 animation-frame switching is triggered every time
you move mouse over it.  Hence, bug point number

4 - menu selection animation doesn't work.

Mouse stuff...  It is impossible to select menu items by pressing mouse buttons.
 Just nothing happens what can be observed by a plain eye.  But there are
exceptions for some edit-boxes in one screen, where both buttos works OK.  Bug
point number

5 - mouse buttons don't work on most menu and listbox items, which are
self-made, I believe.

In some screens mouse pointer is drawn, but in most of areas it gets hidden.  In
the Main Menu screen it is hidden always.  Though its image can be 'captured' by
blindly moving mouse to the invisible area and switching forth to another X
window and back.  Bug point number

6 - in some screens or some screen areas mouse dissappears.

This can be caused by some strange technology of drawing standard windows
control on the DDraw surfaces (or so).  This can be best seen in the Multiplayer
screen battle.net subscreen, when I get some editboxes to input your name and
password.  I can click right mouse button, and get its standard context menu.  I
pres Esc and see editbox in a previous state, but a background around it stays
painted with a part of context menu, which has already died.  Maybe I name this
bug point number

7 - windows controls and DDraw surfaces do not mix well.

BTW, some nice textures (bitmaps?) are painted on the background of this
subscreen, but only after some intense and long switching.  This is Mandelbug,
as I have no idea how to make those nice bitmaps to be drawn.  It happens very
rarely.  And this is true for the Mini-logo on the main screen.  Bug point number

8 - very rarely all menu-screens stuff is drawn ok, but its quite rare and
stochastic case.

Maybe switching to the next workspace helps it (Ctrl-Alt-Tab)?  That's hard to
prove.  Anyhow, after such switching game loses its kbd input and the only thing
I can do is to killall -9 wine-preloader. :-/

9 - switching BlackBox workspaces disables keyboard input and the screen in most
 cases isn't redrawn at all.  


Now you tell me if I should file additional 9 or 8 bugreports. :-))

I have tested this and seen this problem with several versions of Wine.
Despite the "black screen in menus" bug I had been nicely playing Diablo with
Wine 20050725 and 20050628 at least, version 20050830 had some trouble I can not
remember anymore. These were all Gentoo packaged Wine snapshot releases.

I took the CVS version and tested it twice, dates and reports follow.
The CVS version works just like 20050628, except the CVS version prints some
information.

-----------
Wine from the CVS Sep 27, 2005.

Immediately after starting:
pq@daedalus $ bin/wine 'D:/pelit/Diablo-wine/Diablo.exe'
fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdffb48)->(0x10022,00000013)
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:x11drv:X11DRV_desktop_SetCurrentMode Cannot change screen BPP from 32 to 8
fixme:x11drv:X11DRV_DDHAL_CreatePalette stub
fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x7fdffb48)->(flags=0x00000001,handle=(nil))


The "Blizzard" movie plays ok. After that, black screen. Music plays ok.
Main menu responds to keyboard, screen stays black.
Starting a game by pressing 'enter' three times. Music indicates game started,
but screen stays black. Printed dozens of times the line:
fixme:ddraw:Main_DirectDraw_WaitForVerticalBlank
(0x7fdffb48)->(flags=0x00000001,handle=(nil))

Clicking the game screen makes it appear and draw correctly. The game is now
completely playable, until you try to go back to the pre-game menus, then screen
becomes black again, but keyboard and sounds respond as they should.

After quitting Diablo, the window disapperas, but Wine stays running, not
releasing the terminal it was run from, until Ctrl+c.

------------------

Wine from the CVS, Oct 2, 2005

Works exactly like Sep 27 CVS version, except the address in the output is 
0x7fdffb70 instead of 0x7fdffb48.

------------------

System information:

Gentoo Linux

pq@daedalus $ xdpyinfo
name of display:    :0.0
version number:    11.0
vendor string:    Gentoo (The X.Org Foundation 6.8.2, revision r4-0.1.10.2)
vendor release number:    60802000
X.Org version: 6.8.2
...
default screen number:    0
number of screens:    2

screen #0:
  dimensions:    1280x1024 pixels (339x271 millimeters)
  resolution:    96x96 dots per inch
  depths (7):    24, 1, 4, 8, 15, 16, 32
  root window id:    0x14c
  depth of root window:    24 planes
  number of colormaps:    minimum 1, maximum 1
  default colormap:    0x20
  default number of colormap cells:    256
  preallocated pixels:    black 0, white 16777215
  options:    backing-store NO, save-unders NO
...

Linux 2.6.12.6 #1 Sun Sep 4 15:58:14 EEST 2005 i686
nvidia binary drivers version 1.0.7167

I tested with 16 bit depth, same behaviour (cannot change from 16 to 8 BPP). I
could not test with 8 bit depth as the nVidia drivers apparently refuse to
cooperate.

Pekka, despite that you are talking about v1.00 (and not v1.09) I can offer try
using my patch [3], which helped me from a crash in libGL.so in 8 bit video
mode.  It maybe incorrect patch, but it worked for me. ;)

No, it didn't help me, but you can never know about another box and its setup. :-)


[3] http://www.winehq.com/hypermail/wine-patches/2005/08/0520.html

I mean the patch didn't make game any better. :-/

Thanks Saulius, but my 8-bit problem has nothing to do Wine but Xorg. I'd have
to rewrite the config and probably reboot to get rid of the nvidia binaries to
test it. But this is off-topic.

I forgot to mention that my Diablo is v1.09, originally installed and updated
with Wine, and no Windows anywhere.

I have not been able to force it to draw anything while in "black screen", I
cannot confirm that behaviour.

v1.09 of the game launches secondary process of Diablo.exe and it detaches from
its parent terminal (let me say so).  Once game is launched, you see its
messages in the terminal, but you can run another programs and cannot kill it
with Ctrl-C.  Is your version exactly v1.09 ?  I am very interested in this
possible difference.

On the offtopic: I am very curious - what is happening, when you launch 'wine
Diablo.exe' in 8-bit mode using nvidias native drivers.  If answer will be more
of an offtopic, please write me an e-mail message.  Thanks. :)

Changing URL to a specific version of the app.

*** Bug 2448 has been marked as a duplicate of this bug. ***

Can anyone attach an update +ddraw,+tid log with a recent Wine CVS tree ?
And is there a demo that reproduces this issue ?

Demo [50MB]:  
  
http://ftp.blizzard.com/pub/demos/diablosw.exe   
  
Seems to have the same issue.  
  

Apologies for not including this in the previous comment -- this updates the 
demo to v1.09... though I believe the issue is also in v1.00 of the demo. 
 
http://ftp.blizzard.com/Pub/diablo/patches/pc/dshr109.exe 

Created attachment 1166 [details]
WINEDEBUG=+ddraw,+tid

Here it goes (if not too late).  What do you think about the bug, Lionel?

Created attachment 1243 [details]
WINEDEBUG=+region,+clipping  (one 'iteration' from the huge output I got)

Adding +region debug switch spits out huge amount of region debug messages. 
Adding +clipping also enriches output.	Because of this I think this possibly
may be a region handling/clipping mechanism related bug. :-\

How close is that tied to DDraw clipping is still unkown to me.  Attaching

Confirming this is still an issue with CVS version as of 2/5/06.  The game
"runs", but nothing is visible after the intro screen.  The main menu is all
black.  If I happen to click on the right spot, it will display a button
outline, but that's about it.

I'm on a Gentoo system with the exact same problem. Blindly moving around in the
menu got me to the game, but the game screen did not appear on the monitor until
I used the mouse and moved around a little bit. (As a side note, I'm on wine 0.9.12.

I just wanted to mention, real quick, that cedega also has a serious diablo 1
menu problem where the game will actually crash and not even load the menu's if
the 'Freetype/Xrender' option is turn on. Turning it off makes the menus appear,
although they are corrupted. I was wondering if this could be related?

Created attachment 2466 [details]
patch which makes Diablo menu happy under Wine 0.9.13

Michał Kazior discovered [6], that patch from Vincent Povirk [7] makes
Diablo run ok under Wine using default cfg.  Actually, I've tested this and
trimmed the patch down to one-liner.  Attaching it and including inline for a
review:

--- dlls/ddraw/surface_user.c	26 Jul 2005 20:10:51 -0000	1.2
+++ dlls/ddraw/surface_user.c	23 Apr 2006 05:09:47 -0000
@@ -394,6 +394,7 @@
 #endif
	return priv->user.window;
 #else
+    return GetDesktopWindow();
	return This->ddraw_owner->window;
 #endif
     }


[6] http://appdb.winehq.org/appview.php?versionId=3498
[7] http://www.nanacide.com/wahelp/wa_ddraw.tar.bz2

Created attachment 2585 [details]
WINEDEBUG=+win log

I think I know what's happening here.

I've explained in detail at http://bugs.winehq.org/show_bug.cgi?id=4009#c22

Summary of that comment: The main window passed to SetCooperativeLevel has a
child window that obscures all of it. Wine's ddraw does not draw to the area
obscured by child windows. Presumably Windows' ddraw does. I do not have the
skills needed to do anything about that.

Created attachment 2673 [details]
patch which makes Diablo menu happy after DDraw rewrite

After the DDraw rewrite [8] old menu hack isn't possible to apply.  This is
updated and somewhat working hack:


--- a/dlls/wined3d/surface_gdi.c
+++ b/dlls/wined3d/surface_gdi.c
@@ -60,7 +60,7 @@ x11_copy_to_screen(IWineD3DSurfaceImpl *
 
	 hSurfaceDC = This->hDC;
 
-	 hDisplayWnd = This->resource.wineD3DDevice->ddraw_window;
+	 hDisplayWnd = GetDesktopWindow();
	 hDisplayDC = GetDCEx(hDisplayWnd, 0, DCX_CLIPSIBLINGS|DCX_CACHE);
	 if(rc)
	 {


[8]http://source.winehq.org/git/?p=wine.git;a=commit;h=c8901d6f6253f6c97610eb1068ac4ff89758ed0a

That hack doesn't work with opengl as the DirectDrawRenderer.

Thanks for the 2466 patch, using Gentoo-Wiki's wine-cvs ebuild and this patch,
the menu becomes visible (with a lot of glitches and missing text in the
Battle.net Menu), and the mouse can be used to select items. At least this way I
can actually get into the game, which works flawlessly.

This bug affects multiple apps so changing the title to be less application
specific.

CCing Stefan at his request.

*** Bug 4009 has been marked as a duplicate of this bug. ***

http://repo.or.cz/w/wine/hacks.git (use link with browser not git) now contains
a similar hack that can be enabled by a registry key.

From the patch log:
ddraw: Hack to draw to the desktop window.
This can be enabled by setting the registry key
HKCU\Software\Wine\Direct3D\DirectDrawDesktopHack to "Y".

This bug still exists in wine 0.9.40 and the original Diablo, both version 1.0
and a fully patched version.

I get an error when trying to run the game world in conflict

Unless World in Conflict is a directdraw game (seems very unlikely), that's a different bug.

I had the same issue with Diablo, voting this bug.
The 'render to desktop' workaround worked, but I'd like to say,
the state of the bug is not 'new'.
After three years, why don't you change the state to confirmed,
and eventually start to implement a fix in the main wine?

Regarding the status, that is just a bugzilla category. A new bug is "UNCONFIRMED", when people confirm it it becomes "NEW". The next step is "RESOLVED" - with various reasons, e.g. FIXED, WONTFIX, ABANDONED, ..., after that CLOSED. So "NEW" doesn't mean that the bug isn't older than $DAYS. The "NEW" is what you mean with confirmed propably.

As far as fixing this bug is concerned, an open source project isn't something where you can drop in and order something to be done. Possible reasons why this bug isn't fixed could be

a) None of the developer has personal or commercial interest in the specific games
b) None of the developers has time to fix it. Remember, many are working on Wine in their free time.
c) No volunteer got around to fix it yet(as everyone only demands that it gets fixed)
d) The bug is harder to fix than the simple workaround suggests. There might even be architectural differences between Windows and X11 which make it impossible to fix correctly.

In case of this bug, it's a combination of all 3 issues.

I successfully made Diablo flawlessly render the menu using the hacked ddraw.dll and disabling the window manager controlling the windows and enabled the emulation of a virtual desktop.

I had a blank screen that only rendered when I alt-tabbed to other applications until I did those things but the ingame it worked fine.

However after doing these things I have to left-click once on the window to catch it ingame and from there it is on top of the virtual desktop, running perfectly. The menu now works perfectly from start. If I launch Diablo from winefile I sometimes have to pull the window out of the way once I launch an ingame session, and the left-click on the spot it occupied.

My best guess is that the window manager does not handle all games running ddraw perfectly, leaving you with a blank screen. Using a hacked ddraw.dll, disabling the window manager and emulating a virtual desktop seem to fix it for Diablo, anyone up for trying it with other games?

(In reply to comment #35)
> Regarding the status, that is just a bugzilla category. A new bug is
> "UNCONFIRMED", when people confirm it it becomes "NEW". The next step is
> "RESOLVED" - with various reasons, e.g. FIXED, WONTFIX, ABANDONED, ..., after
> that CLOSED. So "NEW" doesn't mean that the bug isn't older than $DAYS. The
> "NEW" is what you mean with confirmed propably.

Ok. The category names confused me.
Thanks for your explanation.
 
> As far as fixing this bug is concerned, an open source project isn't
> something where you can drop in and order something to be done.

I know. I work on free software projects of my own.
I did not mean to order anyone to do anything. 
Through my vote and comment I meant to suggest to change the status
(based on a wrong understanding of the categories),
and morph the current workarounds in a fix available for default wine.

> Possible reasons why this
> bug isn't fixed could be
> 
> a) None of the developer has personal or commercial interest in the specific
> games
> b) None of the developers has time to fix it. Remember, many are working on
> Wine in their free time.
> c) No volunteer got around to fix it yet(as everyone only demands that it gets
> fixed)
> d) The bug is harder to fix than the simple workaround suggests. There might
> even be architectural differences between Windows and X11 which make it
> impossible to fix correctly.

This is one of the main problems with wine for me.
I do not have the time to try to fix wine bugs myself.
More so since I tried to invest time once to do that,
but my patches remained out of tree (which is fine by itself),
but I did not reach an open, satisfying discussions about the
issues underlying them.

So say I want some bugs fixed (not workarounds, but
fixes in order to make the api behave as the MS implementation),
by paying wine developers to do that. 
I think there _is_ a company behind wine. So do you have 
anything in place? Is paying for each bug enough to 
generate the commercial interest in fixing them?

> In case of this bug, it's a combination of all 3 issues.

My main interest is for vanilla wine to be better, as I see Wine
as a powerful tool to facilitate the move towards free software.
But it has a long way to go to reach the level of compatibility
with the win32 API I (and I guess many others) would like to see.

(In reply to comment #37)
> So say I want some bugs fixed (not workarounds, but
> fixes in order to make the api behave as the MS implementation),
> by paying wine developers to do that. 
> I think there _is_ a company behind wine. So do you have 
> anything in place? Is paying for each bug enough to 
> generate the commercial interest in fixing them?
This is discussed quite often, but there is no real bugfix bounty system. The problem with it is that getting a bug fixed is quite expensive in the end. At codeweavers we have some metric that fixing a minor bug costs us between 1000-1500 USD, which is way too much for a user to offer for a bugfix.

One might argue that such bounties sum up, but unfortunately, everyone wants a different bug fixed. The problem of Wine is that it has such a broad aim, so everyone has different problems he wants fixed.

So my personal way of dealing with this is that if I do not have any specific apps to get running, I'm implementing missing features without focusing on specific application, or I am picking random bugs, but that is rather rare though.

I've been helping sponsor some work on Wine for the last year
or two.  The way I go about it is 
a) be a fairly good wine developer and do lots of QA 
myself, so I can direct the work intelligently;
b) hire interns to work on subsystems that are obviously 
important but not obviously urgent (e.g. widl, com/ole, msi,
gdiplus, crypt32, bits).  This only works because of (a) above,
and because my company looks on hiring interns as a recruiting
expense.
c) hire codeweavers to work on apps that are important to 
my company (e.g. picasa).
But that's kind of big-time.

More commonly, Codeweavers fixes the bugs that the average
Crossover user runs into. 
That's why Microsoft Office bugs get fixed - because jillions
of Crossover users need it, and because Crossover users pay
for support.

So if you're an individual or small business looking to
support Wine, but who can't work on the code directly,
often the simplest way to do it is to
buy Crossover licenses.

This is still an issue in 0.9.58

I'm hitting this bug too with wine-0.9.60 (black screen).
Anyone else?

Yes, in Diablo (original 1.09, IIRC) the menus are still black with Wine 0.9.61. I've memorised the menus in vmware player. It plays fine in Wine after blind-walking the menus and clicking once. Just spent a couple of hours playing, again.

Created attachment 13285 [details]
Worms Amagedon Black Screen Bug

I hope this the same Bug

Created attachment 14000 [details]
Debug log for Diablo shareware for wine-1.0-rc5

I can confirm the blank screens and i'm testing with wine-1.0-rc5 with the Diablo demo. I haven't bothered to memorize the menus and start a new game like Pekka Paalanen.

The video starts up fine showing the Blizzard logo. The video itself is off center from the screen by almost half an inch to the right. (This seems to be common to me as Diablo 2 and Star Trek Armada have this as well with past releases.)

Then the screen is blank for a moment, then I hear the music that plays during the main menu(screen is still blank). I press up and then enter to exit, blind, the game exits properly.

Please keep in mind i'm new at this so a helpful link to any debugging instructions would be nice. Debug log included.

(In reply to comment #43)
> Created an attachment (id=13285) [details]
> Worms Amagedon Black Screen Bug
> 
> I hope this the same Bug
> 

Yes, this is the same bug. There's a rather hacky hack that gets Worms Armageddon working well enough to play (but the Team Editor and other advanced settings crash). This hack can also be applied to Diablo 1, but it doesn't seem to perform as well there.

So in short, yes, Worms Armageddon and Diablo are both affected by this same bug :)

I copied the ddraw.dll file to the Diablo directory, and my screen is still black. I can't even see at least text, so that I can get in the game properly. Is there an alternate solution to get this working?

I like Woms Armageddon. But DirectDraw patch don't works since 0.9.52 version. I'm using older versions of Wine. LiveCD's! It is possible to play in newest versions of Wine with old patch + user32 patch, but... At the begining, this is 2x patches to source code. After this, putting this dll's to WA directory and recompiling Wine without patches! The best version toplay is 0.9.41-0.9.44 - you can change sound volume in the game. In 0.9.30 I can't do this. After 0.9.44 (I don't remember right version), I see some troubles. I can't press any button after clicking "Cancel" when WA is making connect to a game. With Wine newest that 0.9.52, with patches, I have MANY bugs! I can't write texts on IRC chat before game. I can't change scheme of the game. Game uses 70% of processor time... I see slow when activate Indian Nuclear test.
I don't test this game after 1.0-rc1. It was silver, it is bronze now.

Created attachment 17710 [details]
Worms Armageddon hack for Wine 1.1.10

The attached patch should do what the previous patches has done. The only thing is that the game will crash when you try to enter submenus like configure weapon settings or game settings. I don't know if it's related.

* In reply to comment #48:
> 
> It is possible to play in newest versions of Wine with old patch + user32 patch,
> but... At the begining, this is 2x patches to source code. After this, putting 
> this dll's to WA directory and recompiling Wine without patches!

Zhenya, patching source code which is going to compile is quite equivalent to putting dlls that already works in the "patched way".

> The best version toplay is 0.9.41-0.9.44 - you can change sound volume in the 
> game. In 0.9.30 I can't do this. After 0.9.44 (I don't remember right version), 
> I see some troubles. I can't press any button after clicking "Cancel" when WA is
> making connect to a game. With Wine newest that 0.9.52, with patches, I have 
> MANY bugs! I can't write texts on IRC chat before game. I can't change scheme of
> the game. Game uses 70% of processor time... I see slow when activate Indian 
> Nuclear test.

Firsty, try Wine-1.1.10, it was released some days ago.  

If newer bugs are still present, you could help Wine project by writing up individual (atomic) bugs into a list and then doing regression test [10] for every such bug (separately).  

Once you identify offending commit ID, search it up in the Bugzilla.  If that's not a case, also try looking at the list of known Wine issues [11].  It may be someone already has filed appropriate bugreport.  If it's not, file your own one about the issue.

Repeat this for every symptom of regression you've noticed.  Thanks for looking into a bug :)


[10]http://wiki.winehq.org/Regression
[11]http://wiki.winehq.org/KnownIssues

Created attachment 17739 [details]
Worms Armageddon full fix patch for Wine 1.1.3+

This fixes the other issue with crashing sub menus as well. I don't know if the crashing issue is related to the black screen hack.

>This fixes the other issue with crashing sub menus as well.
>I don't know if the crashing issue is related to the black
>screen hack.

I patched and build wine 1.1.10 with that patch, but I am still getting black screen. I can hear the sounds, but everything is black.

(In reply to comment #52)
> >This fixes the other issue with crashing sub menus as well.
> >I don't know if the crashing issue is related to the black
> >screen hack.
> 
> I patched and build wine 1.1.10 with that patch, but I am still getting black
> screen. I can hear the sounds, but everything is black.
> 

Remember to set the DirectDrawRenderer registry key to "gdi".

[HKEY_CURRENT_USER\Software\Wine\AppDefaults\wa.exe\Direct3D]
DirectDrawRenderer = "gdi"

>Remember to set the DirectDrawRenderer registry key to "gdi".

Yay! It works! Thanks.

Since you are talking about patching Wine-1.1.10 and getting Worms working... are you not affected witch the slow frame rate bug on Wine-1.1.3 and newer http://bugs.winehq.org/show_bug.cgi?id=15789 ?
If not and you've got Worms working smooth on Wine-1.1.3+ can you write here your system specs please? CPU and GPU + graphics driver?

Please retest in current git. If still present, update version field to earliest known version of wine that had this bug. Thanks!

Still confirming in wine-1.1.13-272-gf63d950.

1.1.16 bump. Tested both renderers, gdi and opengl.

Both renderers output this fixme:
fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible

OpenGL output specific:
fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface
fixme:d3d_surface:surface_get_gl_buffer Higher back buffer, returning GL_BACK

Still seeing only black screen.

Why is this bug not marked as a regression because it used to work with older versions of Wine?

Zdeněk, it's probably because no one could report the exact version of Wine.

I meant the version which works OK in this regard.

Reference fix for problem.  It was a patched version of Wine 1.1.10.  The patch may or may not still work with later releases of Wine.

This code appears in several bugs.  I don't have the ability to combine them all into one bug report:

fixme:d3d:IWineD3DDeviceImpl_CreateSwapChain The app requests more than one
back buffer, this can't be supported properly. Please configure the application
to use double buffering(=1 back buffer) if possible

I just updated a different bug with this phrase in it for dOOm.

There is very little useful information here thanks to all the pointless noise, so it's hard to see what the problem is.

This looks and sounds a lot like Bug 1347.

Present in Wine-1.1.35.

Latest patch: http://glados.iwanek.co.uk/dokuwiki/projects/wine-hacks/ddraw
With Wine 1.1.35 Enter doesn't work.

(In reply to comment #66)
> With Wine 1.1.35 Enter doesn't work.

Probably bug 21025.

(In reply to comment #67)
>> With Wine 1.1.35 Enter doesn't work.
>
>Probably bug 21025.

It was one year ago too. I don't know what version of Wine was with this bug (maybe 0.9.52 or 1.0rc), but it was fixed with WA 3.6.29 patch.

(In reply to comment #66)

> With Wine 1.1.35 Enter doesn't work.

Zhenya, do you mean pressing Enter key produces no effect?

> It was one year ago too. I don't know what version of Wine was with this bug
> (maybe 0.9.52 or 1.0rc), but it was fixed with WA 3.6.29 patch.

What is this patch about?

Still a bug with wine 1.1.43.

Still present in wine 1.1.44

Applied this http://bugs.winehq.org/attachment.cgi?id=17739 patch to wine 1.2 - everything works fine, Worms Armageddon runs awesome! Please include this patch in the wine sources.
http://rghost.ru/2249287
Here is compiled wined3d.dll.so for wine 1.2 with this patch. Enjoy!

(In reply to comment #72)
> Applied this http://bugs.winehq.org/attachment.cgi?id=17739 patch to wine 1.2 -
> everything works fine, Worms Armageddon runs awesome! Please include this patch
> in the wine sources.
> http://rghost.ru/2249287
> Here is compiled wined3d.dll.so for wine 1.2 with this patch. Enjoy!

For reference, this patch will not be accepted to Wine sources. It is a hack that is known to cause more problems than it solves (only a handful of apps benefit from the hack, but many more would be adversely affected).

Created attachment 31498 [details]
Worms World Party fix for wine 1.1.42

This patch fixes the black screen problem for Worms World Party under wine 1.1.42.
It also forces the DirectDrawRenderer to use GDI, thus no registry setting needed.
It's just a collection of fixes published by other guys from the Worms Armageddon tread. So, thanks go to these guys.
I rebased these patches to wine 1.1.42 to perfectly fit for (K)Ubuntu 10.04 (Lucid).

doedeluser

Created attachment 31558 [details]
Worms World Party fix for wine 1.2

Worms World Party fix for wine 1.2

(K)Ubuntu 10.04 has updated its wine version to 1.2 today ...

This patch fixes the black screen problem for Worms World Party under wine 1.2.
It also forces the DirectDrawRenderer to use GDI, thus no registry setting needed.
It's just a collection of fixes published by other guys from the Worms Armageddon tread. So, thanks go to these guys.
I rebased these patches to wine 1.2 to perfectly fit for (K)Ubuntu 10.04 (Lucid).

doedeluser

There is a workaround for this bug included in Worms Armageddon version 3.6.30.0. Wine is detected on startup and the game offers to enable compatibility options, which can alternatively be configured via .reg scripts, or (if you can access the frontend) via the new Advanced options menu.

This is still an issue with Diablo 1 and wine 1.3.15 

Using the  Worms World Party fix for wine 1.2   (2.90 KB, patch) and the wine source od 1.2.2 does fix it but you have to change the stuff manualy cause because of version mismatch patch does not work.

The patch does not work on recent wine source (1.3.15)

Hello folks.

Lets transfer talks on the hacky patch to the AppDB.  This is bugreport and only technical details _related to the bug directly_ are interesting here.

So please stop talking about workarounds.

There are only 20 usefull comments (at most) in this report.  Please keep the noise lower :)

Thank you :)


Now the tech-details.

Vincent Povirk and Jesse Allen have investigated on the bug.  Jesse has made a standalone and interactive test-case:
http://bugs.winehq.org/show_bug.cgi?id=4009#c27

It would be nice to transform it into autonomous WRT block.  Though I am not sure about the way to read and interpret the resulting image (to make difference between bug and normal case).

Gangsters 2 is also affected by the bug.
Patch from comment #51 let me get the game working (however, mouse is sluggish, but this is another bug).

(In reply to comment #0)
> ..and in stalled rendering of graphics. after running game i see black screen.
> when i am switching to another apps with an Alt-TAB and back i can see rendered
> image. pressing key should lead to change of the image and it leads to y.a.
> blackout :-(
> 
> (to download right patch for use with a demo version you should choose a link
> from [Spawn] section on mentioned page)

I have had that ALT-TAB experience in Diablo 1! Maybe it is nearing a solution?

Created attachment 35469 [details]
Test case which consistently fails.

After some work with Diablo Spawn's traces I was able to find a test case which consistently fails against current wine git.

Build with:
winegcc main.c -lddraw -lgdi32

Expected result: Flashing screen from black to white and back to black.
Wine results: Same results, except with a black square in the corner.

Now someone just have to find where in wine this bug is...

I looked at your test case and it doesn't seem to work on windows 7. The screen is completely gray with no animation, UNLESS I click on the part where the main window should be. That seems to kick it off. However, clicking on the area where the child window should be doesn't do anything (the screen stays blank).

In WINE, the animation starts immediately, although there is a black rectangle in the top-left corner. However, when I click anywhere on the main window, the child window is sent to the background and then animation plays out on the whole screen. However, similar to the windows behavior, when I click on the child window, nothing happens (the child window continues to obscure the animation below).

Hope that helps.

(In reply to comment #82)
> I looked at your test case and it doesn't seem to work on windows 7. The screen
> is completely gray with no animation, UNLESS I click on the part where the main
> window should be. That seems to kick it off. However, clicking on the area
> where the child window should be doesn't do anything (the screen stays blank).

This actually makes sense, although unexpected. Windows 7 doesn't start drawing immediately for some reason. That's why you have to click. Some fiddling with the test case should probably fix that. That's irrelevant to the bug.
 
> In WINE, the animation starts immediately, although there is a black rectangle
> in the top-left corner. However, when I click anywhere on the main window, the
> child window is sent to the background and then animation plays out on the
> whole screen. However, similar to the windows behavior, when I click on the
> child window, nothing happens (the child window continues to obscure the
> animation below).

This is expected. You do expect a window to come forward when you click it. Although this only happens in virtual desktop mode.

Created attachment 35470 [details]
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)

Just pinging this as it's currently still a problem in 1.3.27.

There is no changes in WINE 1.3.29?

The hack can't be applied to the latest git. Stefan, is it possible to get an updated temporary hack? Thanks!

Are there some new patches for worms world party?

Gangsters 2 Demo is now working out of box in vanilla wine-1.3.37. Can anyone re-test Worms World Party or Worms Armageddon?

I just tried with the test program in comment 81 and the problem persists, ie, I get a flashing screen from black to white and back to black, with a black square in the top-left corner.

Bugs still there wit Worms Armaggedon demo.

I forgot to mention that I used Wine-1.3.37.

Remove Lionel as owner of open bugs as he isn't active anymore (and that for years).

It is very hard to contribute to solving this because it contains references to all directX games. Shouldnt this be closed an individual program specific issues to be opened ?

no since this isnt a program specific problem, its a directdraw problem.

For what it's worth, running Fedora 16 with gnome shell and wine 1.5.2
Running Diablo, menu screen doesn't get rendered (black screen) but if use the hotcorner and display all running windows in the workspace the menu screen is rendered. Clicking back on the Diablo window still result in black screen.

I can confirm that this is still happening in wine 1.5.5, both x86 and amd64 builds.

Diablo 1.09b full install and Hellfire 1.01 exhibit the same behaviour: game starts up fine, intro movies play, and then black screen. The game is still running and the menus can be navigated blind with the keyboard. If you manage to actually load/start a game without being able to see the menus, it starts rendering just fine and the game is totally playable.

Can confirm the problem with wine 1.3.9, wine 1.5.6 and wine git d35cb8164a7635201c2ccdf73de2a78cebf6cb94 (which appears to be 1.5.7) on Gentoo with both Diablo 1.00 (vanilla after install) and Diablo 1.09 (latest patch). Exactly as the other posters have described it (intro works, menus don't).

Tried to apply the "slightly nicer hack", but HUNKs failed; the patch says it's from bde3703 -> a7d4fc8, but I can find neither commit in the history. Can somebody help me apply that patch against latest git head in order to try if it works?

This is still an issue in 1.5.14. None of the hacks in this bug report can be applied to current git. 

Stefan, do you have time to rebase your hack to the latest git? Thank you!

It's probably not the right place to post a message about this and i've read this "NEW
    This bug has recently been added to the assignee's list of bugs and must be processed. Bugs in this state may be accepted, and become ASSIGNED, passed on to someone else, and remain NEW, or resolved and marked RESOLVED."

But i still fail to understand how a bug that was reported in year 2004 has its status named NEW.

(In reply to comment #100)
> It's probably not the right place to post a message about this and i've read
> this "NEW
>     This bug has recently been added to the assignee's list of bugs and must be
> processed. Bugs in this state may be accepted, and become ASSIGNED, passed on
> to someone else, and remain NEW, or resolved and marked RESOLVED."
> 
> 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.

(In reply to comment #101)
> (In reply to comment #100)
> > "NEW
> >   This bug has recently been added to the assignee's list of bugs and must be
> > processed. Bugs in this state may be accepted, and become ASSIGNED, passed on
> > to someone else, and remain NEW, or resolved and marked RESOLVED."
> > 
> > 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.

Quoting next item:

"ASSIGNED
This bug is not yet resolved, but is assigned to the proper person who is working on the bug."

So combined this basically means there is still no proper person to work on the bug.

(In reply to comment #96)
> For what it's worth, running Fedora 16 with gnome shell and wine 1.5.2
> Running Diablo, menu screen doesn't get rendered (black screen) but if use the
> hotcorner and display all running windows in the workspace the menu screen is
> rendered. Clicking back on the Diablo window still result in black screen.

Interesting! Your find inspired me to go look for some similar effect that could be used to work around the problem, and I found it could be done trough KDE's settings for the translucency effect.

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

(In reply to comment #103)
> (In reply to comment #96)
> > For what it's worth, running Fedora 16 with gnome shell and wine 1.5.2
> > Running Diablo, menu screen doesn't get rendered (black screen) but if use the
> > hotcorner and display all running windows in the workspace the menu screen is
> > rendered. Clicking back on the Diablo window still result in black screen.
> 
> Interesting! Your find inspired me to go look for some similar effect that
> could be used to work around the problem, and I found it could be done trough
> KDE's settings for the translucency effect.
> 
> 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).

I also don't believe this would work in a virtual desktop, which people with multiple monitors (well, on my setup at least) pretty much require because otherwise nothing can get the damn resolution correct.

However, it's worth noting if nobody has already that the Worms Armageddon maintainers have implemented the "Use DesktopWindow" workaround (essentially the same effect as the wine patches that were going around ages ago) into Worms Armageddon itself (the game suggests you enable it when you first start it with the newest update) so that the game will work in wine, at the cost of ingame minimisation.

Any chance we can get a registry key put into mainline for this yet?

(In reply to comment #104)

> However, it's worth noting if nobody has already that the Worms Armageddon
> maintainers have implemented the "Use DesktopWindow" workaround (essentially
> the same effect as the wine patches that were going around ages ago) into Worms
> Armageddon itself (the game suggests you enable it when you first start it with
> the newest update) so that the game will work in wine, at the cost of ingame
> minimisation.

Could you maybe elaborate on how that can be achieved? What do you mean by "ingame minimisation"? Would be happy to try out your suggestion.

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 fuck?

Johannes

Wine's still very much under active development.  Just because your favorite bug hasn't been fixed doesn't mean a project is dead.
See also comments 35-39 above.

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

(In reply to comment #106)
> Could you maybe elaborate on how that can be achieved? What do you mean by
> "ingame minimisation"? Would be happy to try out your suggestion.

Well, the maintainers for the game added an option to change the SetCooperativeLevel call to pass the desktop window as the parameter. This breaks ingame minimisation because the only way to minimise ingame due to other weirdness with the game itself is to set the desktop window as the currently active window.



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

I believe Windows 8 essentially has a registry key to enable old ddraw behaviour/emulation/something special at least, which is what this workaround does (sets that key). Here's the reg file:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\\Team17\\Worms Armageddon\\WA.exe"="$ DWM8And16BitMitigation Layer_ForceDirectDrawEmulation"



So, if Windows has a registry workaround, wine might benefit one too ;)




Weirdly enough, WA has implemented new renderers recently - DirectDraw 32-bit (previous was 8-bit), Direct3D 7, Direct3D 9 with CPU palette conversion, and Direct3D 9 with Shader palette conversion. The weird thing is, these also exhibit a black screen in wine, and there appears to be no workaround (apart from DirectDraw 32-bit which has the same workaround as the old 8-bit renderer, that is the SetCooperativeLevel thing described above). I don't know if this is the same bug - if there's some legacy function in DirectDraw that enables the same sort of behaviour - or something completely unrelated, but they do definitely work in Win8. I could have sworn there used to be some debug output that looks related but I can't find it now (the only seemingly-relevant line is fixme:d3d:wined3d_get_adapter_raster_status wined3d 0x14f8e0, adapter_idx 0, raster_status 0x33ef40 semi-stub!). However, I digress, this probably belongs in a new bug.

> 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 fuck?
> 
> Johannes

wine is not dead, but the project is run in a way that does not put priority in actually getting applications to run and continue running for the users.
The goals of us users and of most of the developers are just not aligned.

My wild guess is that since most of the project is in the hands of a company that makes money out of "last mile" support, it would make little commercial sense to put effort in prioritizing applications and regressions. 

See my little rant at

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

I was thinking about forking wine a few times in the past, since I had to keep patching it in multiple areas to get my stuff working, and I have recognized the project as dysfunctional a long time ago.

However it is a huge task, one that would absorb most of the energies of anyone attempting it, and one that requires multiple talented people for different areas (3D graphics in particular but there are many other complex areas).

It seems more realistic to keep stacking, updating and rebasing those out of tree patches, until someone actually does fork wine, but I doubt it will happen, even more because the project becomes less and less important every day, as the importance of the windows PC wanes.

(In reply to comment #110)
> wine is not dead, but the project is run in a way that does not put priority in
> actually getting applications to run and continue running for the users.
> The goals of us users and of most of the developers are just not aligned.

False. The goal is to produce a Win32/Win64 implementation for Unix-like systems that allows native Windows applications to run without modification. Bigger, newer games work very well (or better) than Diablo and Worms Armageddon. Please read my post above outlining the difficulties in fixing this particular bug. There are other bugs that cannot be fixed (in the forseeable future) due to architectural differences between Windows and Unix-likes.

> My wild guess is that since most of the project is in the hands of a company
> that makes money out of "last mile" support, it would make little commercial
> sense to put effort in prioritizing applications and regressions. 

That is indeed wild. You actually have it the wrong way around: Codeweavers uses Wine as a base for their Crossover products (e.g. Crossover Office, Crossover Games). They include hacks that don't pass the rigorous scrutiny of Wine developers to get applications to work that wouldn't otherwise work in Wine. Codeweavers devs are also actively involved in maintaining Wine upstream, as they have a vested interest in ensuring maximum compatibility with the latest Windows software.

> See my little rant at

Bugzilla is not the place for rants.

BACK ON TOPIC: You're welcome to attempt your own fixes or workarounds for this bug and post your results here.

My suggestion till this bug is fixed officially:

Someone who can code, should code a patch that works with the current wine 1.5.25, or modify one of the earlier ones so it works with the 1.5.25 version and not a git version.

then we write a appdb note how to 

- get and compile 1.5.25 wine with this patch locally installed maybe in the Diablo folder
- describe how to start  D1 with this version of patched wine.
- Link this discussion so everybody can read why their is no easy fix

We could run Diablo 1 again and as the patch is for an official version and not git this would work as long as wine does not delete the 1.5.25 version from the sourceforge servers, so quite long.

I could do all of the above except coding the patch to work with wine 1.2.25

Thanks for consideration

Created attachment 45086 [details]
hack for black menus in Diablo

The attached patch worksforme for wine-1.6-rc2 (and most likely also for successive release candidates) and Diablo: The Hell. Feedback is welcome.

(In reply to comment #113)
> Created attachment 45086 [details]
> hack for black menus in Diablo
> 
> The attached patch worksforme for wine-1.6-rc2 (and most likely also for
> successive release candidates) and Diablo: The Hell. Feedback is welcome.

For what it's worth, this doesn't seem to be working for me. Either same behavior, or a white screen instead of black.

Have you tried doing the transparent-dialog-hack from #c103? It makes the menus in Diablo visible when transparency is set to something like 50%, but become progressively darker with opacity applied.

i think i cant' try this hack because i would have to recompile wine to try it :(

Hello subscribers. 

Quoting myself (comment #78):
> 
> Lets transfer talks on the hacky patch to the AppDB.  This is bugreport and
> only technical details _related to the bug directly_ are interesting here.
> 
> So please stop talking about workarounds.
> 
> There are only 20 usefull comments (at most) in this report.  Please keep the
> noise lower :)
> 
> Thank you :)

Confirmed issue in wine-1.4.1 with unpatched Diablo and 1.09b patched Diablo.

Wine devs: Thanks for your hard work. I know this bug has been open for awhile, but it sounds like it's been a difficult bug to track down. 

I can potentially offer a bounty if that would help and is allowed on this project. Message me and we can discuss the details.

Someone correct me if I'm wrong, but I believe the bug has been known for a *long* time, but nobody has thought of a way to fix it that won't break other apps. And for some weird reason wine still doesn't want to do something Microsoft themselves do, that is have specific fixes for particular apps - which would make this easy.

A friend of mine, however, has created a ddraw.dll replacement that seems to work for the games I own that are affected by the problem (admittedly it was created entirely for these games). As far as I remember, it works by wrapping certain calls, so it's not something that will become outdated. I'll talk to him again about releasing it.

Releasing it might be useful.
Someone was looking at implementing AppHelp
( http://www.winehq.org/pipermail/wine-devel/2013-August/100773.html )
so perhaps the workaround could be included there for popular affected apps.

Does http://bugs.winehq.org/attachment.cgi?id=39566 attached to bug 30062 make any difference here? It sounds like it's essentially the same issue.

(In reply to comment #119)
> Someone correct me if I'm wrong, but I believe the bug has been known for a
> *long* time, but nobody has thought of a way to fix it that won't break other
> apps. And for some weird reason wine still doesn't want to do something
> Microsoft themselves do, that is have specific fixes for particular apps -
> which would make this easy.
> 
> A friend of mine, however, has created a ddraw.dll replacement that seems to
> work for the games I own that are affected by the problem (admittedly it was
> created entirely for these games). As far as I remember, it works by wrapping
> certain calls, so it's not something that will become outdated. I'll talk to
> him again about releasing it.

Fantastic! 

I managed to find an apparently patched ddraw.dll from a years old tarball that was sitting on my system the last time I encountered this issue, but after putting it into ~/.wine/drive_c/windows/system32 I still had the same issue. If I could get a tarball from you with a tested ddraw.dll, (plus correct instructions, not sure if I'm just supposed to put it into system32) that would be awesome. 

Cheers!

(In reply to comment #122)
> 
> Fantastic! 
> 
> I managed to find an apparently patched ddraw.dll from a years old tarball 

Please stop.  Workarounds has nothing to do with fixing bugs.  So these talks belongs to AppDB.  Thank you:)

(In reply to comment #121)
> Does http://bugs.winehq.org/attachment.cgi?id=39566 attached to bug 30062 make
> any difference here? It sounds like it's essentially the same issue.

Tested in current git, your hack does not make a difference unfortunately..

I've been looking into this bug as it affects Worms Armageddon.  That game has built-in Wine-specific tweaks to work around the problem, but they don't work with the Mac driver because the Mac driver doesn't support a virtual desktop window.  For testing purposes, I'm using the X11 driver with WA's tweaks disabled.

I'm going to summarize what I have found (which has also been demonstrated by some of the test cases):

* WA creates window A.
* WA creates a dialog window D, which is owned by window A.  This has sometimes been described as a child window but it's not.  It's a top-level window.  Being owned by window A means that it is kept in front of window A.
* The dialog D has various controls, including buttons, etc.
* WA calls IDirectDraw::SetCooperativeLevel(window A, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN).  The presence of DDSCL_FULLSCREEN should mean that it draws directly to the screen, bypassing all normal (GDI) drawing of other windows.  So, even though dialog D is in front of window A, the drawing to window A should appear on screen.
* Wine's ddraw calls wined3d_device_setup_fullscreen_window() to set window A up as a full-screen window.  This attempts to order window A to the front of all windows by calling SetWindowPos(window A, HWND_TOPMOST, ...).  However, because dialog D is owned by window A, user32 keeps D in front.

The ultimate result is that dialog D obscures window A.  I haven't investigated why dialog D is all black as opposed to looking like a typical user32 dialog window with controls.

I have confirmed this with a gross hack.  In dlls/user32/dialog.c:DIALOG_CreateIndirect(), I have modified the two calls to CreateWindowEx[AW]() to pass NULL for the owner.  This means that dialog D is not owned by window A and window A can be moved in front of it.  The result is that you can see the rendering.  However, clicks on the window are ignored.  That's because window A isn't prepared to respond to the clicks.  The dialog D is supposed to receive those clicks.

I think that Stefan was on the right path.  I think that, when ddraw/wined3d goes to set up window A for full-screen, it should not attempt to change the Win32 window.  I think it needs to work with the user driver to set up a full-screen OpenGL surface that's outside of the Win32 window hierarchy.  This surface would have to avoid interfering with mouse events.  Those should still be delivered to whatever Win32 window is under the cursor.

It may be that targeting the desktop window is the most appropriate way for ddraw/wined3d to communicate the need to draw to the full screen to the user driver, although Stefan mentioned that that has its own problems.  Given that ddraw (and d3d?) has a need to bypass the normal windowing and graphics, I think it makes sense for it to communicate directly with the user driver.

Created attachment 46977 [details]
Use desktop window for fullscreen ddraw, with support in Mac driver

This is a hack that a) makes ddraw target the desktop window when DDSCL_FULLSCREEN is specified and doesn't treat it differently from other windows; and b) adds support in the Mac driver for doing OpenGL on the desktop window.

This allows Worms Armageddon to work with the Mac driver without its Wine-specific tweaks.  It's sort of a proof of concept of the plan I mentioned in my last reply.

NOTE: This will not work with the X11 driver because it doesn't have support for doing OpenGL on the desktop window.  (The X11 driver actually has code specifically to reject attempts to do so, as did the Mac driver before this hack.)  The ddraw hacks will actually break the ability of the X11 driver to run WA when its tweaks are active.

I also don't expect this to work with DirectDrawRenderer=gdi.

d3d8/9 drawing to the desktop window is not valid, unless D3DDEVTYPE_NULLREF is used. Which is what some applications do, and we don't implement NULLREF and just treat it as HAL.

I believe we have tests that demonstrate that opengl rendering on the desktop window is not valid on Windows. I might be mistaken though, I haven't checked the code.

I'm not entirely sure about the ddraw behavior. This needs some additional tests for clippers. Specifically we'll have to check what clippers do in fullscreen mode, and if clippers affect primary surface locks (and not just blits). The current behavior is to render to the clipper window if a clipper is assigned to the primary, and it has a clip window and not a clip list.

What may be the correct behavior:
*) Always render to the device window, which is NULL by default unless the application explicitly sets it with SetCoopLevel(DDSCL_SETDEVICEWINDOW) or asks ddraw to create one with SetCoopLevel(DDSCL_CREATEDEVICEWINDOW). I think SetCoopLevel(window, FULLSCREEN | EXCLUSIVE) just sets the focus window, not the device window.
*) Never render to the clipper window.
*) Use the clipper window only in surface::blt to limit the written area.

> The ultimate result is that dialog D obscures window A.  I haven't
> investigated why dialog D is all black as opposed to looking like a typical
> user32 dialog window with controls.

This is because (on Windows, at least before compositing was introduced and before Windows 8), although ddraw will ignore clipping and draw over other windows, it does not prevent those other windows from also drawing. To prevent ddraw from fighting user32 and causing flicker, WA intentionally prevents the dialog from drawing (on older versions that prevention was flawed and you'd sometimes get flicker anyway, but they may have fixed that). It happens that WA does not need to do any gdi drawing at all, but other programs use clipping to mix ddraw with gdi, and there may be a few that do not use clipping but instead manually synchronize ddraw and gdi drawing (diablo maybe?).

Could anyone rebase patch which makes worms work for wine 1.6 or 1.7+?
Sims started working since 1.6-rc2 and showed similar symptoms to Gangsters 2, blank areas at game screen and it need to be tested if the bug concerns Sims.

(In reply to comment #125)

> I think that Stefan was on the right path.  I think that, when ddraw/wined3d
> goes to set up window A for full-screen, it should not attempt to change the
> Win32 window.  I think it needs to work with the user driver to set up a
> full-screen OpenGL surface that's outside of the Win32 window hierarchy. 
> This surface would have to avoid interfering with mouse events.  Those
> should still be delivered to whatever Win32 window is under the cursor.

Another approach would be for ddraw to create a Win32 device window that can actually go in front for DDSCL_FULLSCREEN.  As mentioned, it would have to avoid interfering with mouse events.  I think that WS_EX_TRANSPARENT should have that effect.  The docs are unclear but numerous sources on the net say that's how WS_EX_TRANSPARENT works.  In Wine it seems to only work that way when combined with WS_EX_LAYERED.  We would probably need tests to confirm how it's supposed to work.

Besides handling WS_EX_TRANSPARENT correctly in user32 and the wineserver, the user drivers might need to add special support for WS_EX_TRANSPARENT windows.

The problem with any approach that uses a Win32 window, though, is that it will be visible and accessible to the game.  For example, the game might enumerate all windows of the thread, encounter the device window, and get confused.  The window is also vulnerable to window ordering.  For example, if WA does SetWindowPos(dialog D, HWND_TOPMOST, ...) then the dialog will once again be in front of the drawing.

(In reply to comment #125)
> I think that Stefan was on the right path.  I think that, when ddraw/wined3d
> goes to set up window A for full-screen, it should not attempt to change the
> Win32 window.  I think it needs to work with the user driver to set up a
> full-screen OpenGL surface that's outside of the Win32 window hierarchy. 
> This surface would have to avoid interfering with mouse events.  Those
> should still be delivered to whatever Win32 window is under the cursor.
> 
More or less. We have tests that show that setting a fullscreen / exclusive cooperative level shouldn't mess with the window styles. E.g. test_window_style() in ddraw/tests/ddraw7.c. We also have tests that show that switching to fullscreen does have an effect on e.g. window dimensions, z-order and focus.

The proper mechanism for communicating with the user / GL driver is probably a WGL extension, somewhat similar to how we currently have WGL_WINE_pixel_format_passthrough for resetting the pixel format. (Although that specific extension has some issues.)

(In reply to comment #131)

> We also have tests that show that switching to fullscreen does have an effect
> on e.g. window dimensions, z-order and focus.

I found tests for the foreground window in dlls/ddraw/tests/ddrawmodes.c, testcooperativelevels_normal() and testcooperativelevels_exclusive().  I didn't find other tests related to z-order.  Please let me know if I missed them.

As we've seen with this bug, a window may be the foreground window without being front-most, in particular if it owns other windows.  Also if it's non-topmost and there are topmost windows.

I'll try to extend the tests to test some possibilities with respect to actual z-order viz-a-viz owned, topmost, and other windows.


With respect to a WGL extension, were you thinking of something like an alternative to wglMakeCurrent() such as wglMakeCurrentFullScreenWINE()?

Created attachment 47148 [details]
Test z-order in ddraw tests

To my surprise, SetForegroundWindow() has nothing to do with z-order, at all.  It just affects foreground/active statuses which are related to focus.

This patch modifies the ddraw tests to check z-order.  In all of the places that used to call SetForegroundWindow(), I now also call SetWindowPos(…, HWND_TOP, …).  In all of the places that checked the window returned from GetForegroundWindow(), I now also check the window order.  I also check the z-order immediately after attempting to set it to verify that it's working.

The tests marked "todo_wine" in testcooperativelevels_normal() are due to ddraw/wined3d setting the window topmost for fullscreen and, in some cases, not restoring it.

For testcooperativelevels_exclusive(), I make sure neither window is topmost before proceeding.  I also create two other windows, one topmost and one owned by the main window.  I test that both remain in front of the main window even when it's fullscreen.  Wine keeps the owned one in front (which is at the root of this bug) but, as expected, promotes the main window to topmost, bringing it in front of the other topmost window, when it shouldn't.

(In reply to comment #133)
> Created attachment 47148 [details]
> Test z-order in ddraw tests
> 
> To my surprise, SetForegroundWindow() has nothing to do with z-order, at
> all.  It just affects foreground/active statuses which are related to focus.
> 
> This patch modifies the ddraw tests to check z-order.  In all of the places
> that used to call SetForegroundWindow(), I now also call SetWindowPos(…,
> HWND_TOP, …).  In all of the places that checked the window returned from
> GetForegroundWindow(), I now also check the window order.  I also check the
> z-order immediately after attempting to set it to verify that it's working.
> 
We don't want new tests to go anywhere that isn't ddraw[1247].c. (And the existing ones should get cleaned up and moved over to there eventually as well.)

> The tests marked "todo_wine" in testcooperativelevels_normal() are due to
> ddraw/wined3d setting the window topmost for fullscreen and, in some cases,
> not restoring it.
> 
Right, setting WS_EX_TOPMOST is correct for d3d8 and d3d9, it isn't for ddraw. (See also the various versions of test_window_style().)

Created attachment 47154 [details]
Implement WGL extension to get fullscreen DC, use it in WineD3D

(In reply to comment #132)

I said (to Henri):
> With respect to a WGL extension, were you thinking of something like an
> alternative to wglMakeCurrent() such as wglMakeCurrentFullScreenWINE()?

In looking at the code, I decided it makes more sense for the extension to provide a full-screen DC which can then be used pretty much as normal.  The attached patch adds a Wine WGL extension named WGL_WINE_fullscreen_dc.  It provides two functions: wglCreateFullscreenDCWINE() and wglDeleteFullscreenDCWINE().

The patch makes WineD3D aware of the extension and makes it use it instead of GetDC()/wined3d_release_dc() if the swapchain is not windowed.

Then the extension is implemented in the Mac driver.

Taken together, this gets Worms Armageddon to show its rendering without the use of any of its tweaks.  Since the extension hasn't been implemented for the X11 driver it doesn't help there but, unlike my previous patch, it shouldn't break X11 either.  It should work just like it has.  If the extension is implemented for X11, then it should start working, too.

(In reply to comment #135)
> Created attachment 47154 [details]
> Implement WGL extension to get fullscreen DC, use it in WineD3D
> 
I think that mostly works for me, from a wined3d point of view.

  - 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.
  - If we do want to pass a device name to wglCreateFullscreenDCWINE(), it should probably take a WCHAR[], and you can get at that from the context as "context->swapchain->device->adapter->DeviceName".
  - wglDeleteFullscreenDCWINE() seems to just be a wrapper around DeleteDC(). If possible I think it would be preferable to be able to just call ReleaseDC() on the DC returned by wglCreateFullscreenDCWINE(), and then just use wined3d_release_dc().
  - If we can just use wined3d_release_dc(), context->hdc_fullscreen can just go away, but otherwise it should probably be part of the other context bitfields like current/destroyed/valid.
  - 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? wglGetFullscreenDCWINE() might be a more appropriate name for how we're using this.

(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.
Is there a device window in those ddraw cases? My impression is that SetCooperativeLevel(DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE, hwnd_that_will_never_be_visible) sets the focus window, not the device window. It would be interesting what ddraw does when an application calls SetCooperativeLevel(DDSCL_SETDEVICEWINDOW, hwnd_that_will_never_be_visible). Similarly, what do d3d8/9 do when they are passed a window like the one Worms Armageddon uses?

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

>   - If we do want to pass a device name to wglCreateFullscreenDCWINE(), it
> should probably take a WCHAR[], and you can get at that from the context as
> "context->swapchain->device->adapter->DeviceName".

I would have used a WCHAR string but make_opengl doesn't currently know about WCHARs.  It could be taught.  (Actually, I'd probably use "LPCWSTR" because it's easier to teach make_opengl how to handle that than "const WCHAR*".)

I didn't know about getting the device name.  Thanks for that.

>   - wglDeleteFullscreenDCWINE() seems to just be a wrapper around
> DeleteDC(). If possible I think it would be preferable to be able to just
> call ReleaseDC() on the DC returned by wglCreateFullscreenDCWINE(), and then
> just use wined3d_release_dc().

Well, DeleteDC() and ReleaseDC() are for different purposes.  ReleaseDC() is from user32 and, conceptually, user32 doesn't know anything about the DC provided by the extension and so we shouldn't ask it to release any DCs we didn't get from it (even if ReleaseDC() were a simple wrapper around DeleteDC(), which it's not).

Beyond that, wined3d_release_dc() checks if WindowFromDC() matches the passed-in window and does nothing if not.  I'm not aware of any way for the WGL extension to create a DC such that WindowFromDC() returns a window, except by using GetDC() and that defeats the point.

Finally, although the implementation of the extension in the Mac driver is just a thin wrapper around DeleteDC(), I wanted to provide for the possibility that it might not be for some other implementation.  That said, the driver does already have a pDeleteDC entry in its GDI function table, so it could put custom cleanup there.

>   - If we can just use wined3d_release_dc(), context->hdc_fullscreen can
> just go away, but otherwise it should probably be part of the other context
> bitfields like current/destroyed/valid.

Indeed.  I just failed to see that group of bitfields.

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

> wglGetFullscreenDCWINE() might be a more appropriate name for how
> we're using this.

The implication being that there should be one full-screen DC and all callers would share it?  Maybe that's OK.  I'm not sure.  It has the issue with the pixel format – over its lifetime, can a shared DC have different pixel formats at different times?  (Leaving aside the question of whether different callers would want to set different pixel formats simultaneously.)

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

The implementation in the driver would detect the screen DC using WindowFromDC(hdc) == GetDesktopWindow() much like what I did in attachment 46977 [details] (which isn't that different from the newer patch).  In other words, the driver-side behavior would be just the same, just with a different means of detecting when a DC was full-screen.

Would that work?  What about the issue with the pixel format?  Are there other issues?

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

If we're reasonably sure that there's always a meaningful device window, then we can change the extension to just provide a function:

BOOL wglEnableFullScreenWINE(HDC hdc, BOOL enable);

WineD3D would continue to use GetDC() to get the window's DC, but for full-screen it would use the above function to tell the driver to use the full-screen behavior.  In wined3d_release_dc(), it would disable full-screen to reset the DC back to normal.  (Since DCs are cached, the full-screen state would otherwise leak through to the next caller to reuse that DC.)

In the drivers, tracking the pixel format would proceed as normal.  It would be associated with the DC's window and could normally only be set once.  (Or do we have a need for tracking the pixel format separately to avoid "contaminating" the window?  If so, we could do that.)

(In reply to comment #139)
> 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.

Hmm.  It seems quite unlikely that an app would call that while one of WineD3D's contexts was current.  And if it did, what could it expect to be true about the returned DC?  I guess it could assume it's a window DC and go astray.  Anyway, with this altered proposal the DC would be the same as the current code, although it would be marked for full-screen behavior for OpenGL.

> Also slightly related to this bug are bug 29301 and bug 30062.

For bug 29301, using the proposed full-screen rendering mode in the driver would allow WineD3D to not muck with the window styles.  The existing patches didn't make that change but it can certainly be done.

I didn't understand the issue in bug 30062 well enough to know how it relates.

(In reply to comment #140)
> If we're reasonably sure that there's always a meaningful device window,
> then we can change the extension to just provide a function:
> 
> BOOL wglEnableFullScreenWINE(HDC hdc, BOOL enable);

After thinking about it some more, I've changed my mind about this suggestion.  Such a function implies that the full-screen state can be toggled on or off at any point during the DC's life.  Really, we want it set immediately upon the DC being obtained and cleared just before it's released.  So, it should be part of obtaining and releasing it.

My initial idea was a custom MakeCurrent, but I don't think that works well.  The DC needs to be "special" for operations that precede making the context current.

(In reply to Ken Thomases from comment #135)
> Created attachment 47154 [details]

Thank you Ken. This patch and the verbeet noflicker from bug #34166 fixes Diablo on MacOS. The black menu is gone. I can see the menu, it's dead slow but it's there :-D

Please see bug 35718, comment 39, which has a patch to test which should also work for this bug.  It's a more sophisticated and complete version of the approach previously discussed and demonstrated with attachment 47154 [details].  Thanks.

This bug also affects Lucas Arts Outlaws. Screen stays black, you can hear the menu sounds as you move the mouse around.

The patch from bug 35718, comment 61 makes the game work again.

A demo can be found here, if someone wants to investigate:

http://www.gamefront.com/files/846030/outdemo_v2_exe

Hello everyone,

main menu still doesn't show in "Diablo" Shareware version. I have attached my console output and wine version as follows:

mwagner@linux-kfgs:~> wine .wine/drive_c/Diablo/Spawn/diablo_s.exe 
fixme:win:EnumDisplayDevicesW ((null),0,0x32f6e8,0x00000000), stub!
fixme:ddraw:ddraw7_WaitForVerticalBlank iface 0x12d930, flags 0x1, event (nil) stub!
fixme:d3d_shader:upload_palette P8 surface loaded without a palette.
mwagner@linux-kfgs:~> wine --version
wine-1.7.29

Created attachment 51248 [details]
minimal hack patch

Here is minimal hack patch for Diablo. Works for me for both 3d and gdi rendering with minor glitches caused by some menu graphics not getting erased when changing screens.

(In reply to Grazvydas Ignotas from comment #146)
> Works for me for both 3d and gdi
Whoops it looks like my 3d setup was hosed, so no it won't work in 3d mode, you still need the DirectDrawRenderer=gdi registry setting to use this.

I just submitted a bug report for another problem with DirectDraw which was resulting in a black screen being drawn, bug 38875.  Let me know if that should be marked as a duplicate of this bug, or it should be considered as a separate issue.

Being the original reporter, I am all for marking this bloated bug report dependent on bug 38875.  When the 38875 gets fixed, this one could be closed too.

But then some patches from here (Charles Welton, Stefan Doesinger, Ken Thomases, Gražvydas Ignotas and probably from related bug reports) will need to be linked to the new report.  I already lost the track of technical discussion to be exact (for a while).

Are there any objections?

I can confirm that this issue still occurs with Diablo retail (both unpatched and patched) in wine-staging 1.7.52, regardless of DirectDraw renderer mode.

This came as a surprise, as I thought that Wine generally handled Win9x-era games better than modern Windows does.

It's doubly surprising that the issue has been known for over 11 years. It must be a tough one.

Created attachment 53524 [details]
ddrawhack for wine 1.9.2

This is a backport of the patch I found somewhere to build wined3d.dll and ddraw.dll with wine 1.9.2. The result is the known buggy menu that only animates on mousebove in case of Diablo 1, but I can play the game with it which is a start. The flip buffer shouldn't be black though but start with the base image, however I have no idea how this could be achieved in the code as I'm not familiar with the codebase.

I copied the two modified dll.so files to the game directory and as a proof, here's a screenshot [0].

[0] http://i.imgur.com/dLUJ3eO.png

Also note that for the patch to work the DirectDrawRenderer=gdi must be set, as far as I interpreted the former version of the patch.

(In reply to mysatyre from comment #151)
> I copied the two modified dll.so files to the game directory and as a proof,
> here's a screenshot [0].

Also they need to be renamed to .dll, otherwise they won't be loaded by wine.

Thank you for backport! But Codeweavers will broke ddraw.dll again in next release. The're think that Diablo I must work only in Crossover, not in Wine. In 2016!

(In reply to Zhenya from comment #155)
> Thank you for backport! But Codeweavers will broke ddraw.dll again in next
> release. The're think that Diablo I must work only in Crossover, not in
> Wine. In 2016!

I call bullshit. If you comment in that tone again you belong banned from this bug tracker.
The refactor that must have lead up to the 1.9.2 codebase looks superior to any version before. If you want to see piece, patch and guesswork, look at the old codebase.

mysatyre@gmail.com, they're really made a huge update of ddraw code started 30 Jan: http://i.imgur.com/dTTHqEy.png http://i.imgur.com/dTTHqEy.png

Is your patch still working?

This bug also appears to affect the game "Anno 1602".  Tested with wine 1.9.7 on Ubuntu 14.04, Nvidia GTX 750Ti video card.

Further information:  "Anno 1602" runs fine on wine 1.9.7 when configured with a virtual desktop.  It's only in the default fullscreen mode with no virtual desktop that the game displays nothing but a black screen.

Still an issue in Diablo on Wine 1.9.22.

Still present in wine-1.9.23 (Staging)

Still present on wine-2.0rc (current version on Arch Linux x64)

Created attachment 56474 [details]
HACK: Blit ddraw surface to window at (1,1)

Seems that many of the older hacks don't work anymore (or need gdi32 renderer), so here's a new one. Works with Wine 2.0-rc2 and probably any later versions as well.

This hack copies ddraw surface to the window at (1,1) when the ddraw surface is unlocked. This needs to be enabled with DDRAW_HACK=1 on runtime, so this doesn't interfere with other applications.

This works at least for Diablo (partially, not neatly).

Correct me if I'm wrong, but my understanding of the issue is that it can't be implemented correctly because ddraw allows you to draw arbitrarily on the screen, something that doesn't make sense on modern composited environments.

IIRC from what I've read in the past, old display servers were implemented as a single framebuffer, and applications had access to a small portion of that framebuffer (that's why we have an Expose event in X11).

Nowadays, applications draw on their own framebuffer. Even if the wine devs tried to implement this "correctly", it would be impossible on composited desktops or in Wayland.

However, is there any reason this can't be implemented correctly for virtual desktops, at least for older Windows versions?

Actually, I think the virtual desktop windows aren't as decoupled from the underlying display server as I'd hope. Fullscreen applications still make xrandr calls, for example, and I've noticed bugs where applications can escape the virtual desktop.

Still an issue in 2.0.2. In 2.11-staging Diablo just crashes.

Plain wine 2.11 (without staging patches on top of it) does launch, though, but the issue still persists.

Still an issue as of Wine 3.5. The game doesn't crash on launch (which was an issue for a time) but does still only display a black screen as originally described.

Wine 3.11 - the problem is still here.

But is also present in version 3.0, tried with Diablo, the intro movies render, the menu does not (blank screen), if I blindly enter the game, loading screen and gameplay is displayed.

Found some MSDN article called "Redirecting GDI, DirectX, and WPF applications" [4].  How do devs think, can it bring some simplicity for the situation?

--- quote ---
Mixed DirectX and GDI Windows

The other reasonably common rendering to a top level window involves mixing DirectX and GDI.  There are two forms of "mixing" here, one is perfectly fine, and the other is problematic. 


_The form of mixing that is fine_ is when there is a window tree of the top level HWND and child HWNDs (and further children, etc), where each individual HWND is either rendered by DirectX or by GDI.  In this situation, the redirection component of the DWM forms its own "composition tree" where each node in the tree represents a node or a set of "homogenously rendered nodes" in the "window tree" rooted at the top level HWND.  Rendering occurs by having each of these render to their own surface, and then compositing this tree of surfaces to the desktop.  Thus, mixed DirectX and GDI rendering works well, so long as the boundary between them is at least at the child HWND level.


_The form of mixing that _doesn't work well_ is when an application uses DirectX and GDI to target the same HWND.  This has never been a supported scenario with DirectX, but there have been scenarios where it has happened to work.  Under the DWM, this is much more problematic, because there can be no guarantee of ordering between the DirectX and the GDI rendering.  This is most troublesome when GDI and DirectX are not only rendering to the same HWND, but to overlapping areas of the same HWND.  As such, this usage pattern is not supported.  Note that there is an alternative that can often work for an application -- DirectX is capable of handing back a DC to a DirectX surface, and applications can perform GDI rendering to that DC.  From the DWM's perspective, that DirectX surface remains purely rendered by DirectX, and all is well.
--- quote ---

[4] https://blogs.msdn.microsoft.com/greg_schechter/2006/05/03/redirecting-gdi-directx-and-wpf-applications/

The Devilution project is trying to restore the original source code of Diablo  (1).  As it widened focus from the main .exe file to include diabloui.dll too, during a cleanup [5] of the latter it encountered IMO a quite insightful screenshot [6] showing usual WinAPI contols drawn over the DDraw surface (if I get it right).

Not that it helps finding a solution to this bug very much – just somewhat technical fun.


[5] https://github.com/diasurgical/devilution/pull/300
[6] https://camo.githubusercontent.com/6636ae49e627291fa3ef67536c75b05f9b50df8f/68747470733a2f2f692e706f7374696d672e63632f37506439317951382f436170747572652e706e67

Looks like the bug still occurs with wine-6.19.

Reproduced with Diablo v1.09b (and Hellfire mod v1.01) on Wine 7 (winehq package).  It is improved in that the menus can be repainted by switching menu items with the keyboard or most of the screen using the mouse cursor.

System:

Xubuntu 20.04.3 x86_64

AMD Phenom 9550

GeForce GTX 750 Ti using Nvidia 470.57.02 driver