[Bug 4009] Worms Armageddon installs fine, but won't start
wine-bugs at winehq.org
Sun Jun 4 14:23:49 CDT 2006
------- Additional Comments From madewokherd at gmail.com 2006-04-06 14:23 -------
Created an attachment (id=2583)
Ok, it finally occurred to me to get a +win log, and I'm pretty sure I
understand this now. No more guesswork.
The window passed to SetCooperativeLevel is called "Worms Armageddon"
(0x10028). While the menu is showing, this window has some child windows
representing controls on the screen. The heiarchy looks something like this:
0x10028 "Worms Armageddon"
|- Single player button
|- Hotseat game button
|- Quit button
The immediate child is destroyed and a new one is created every time the
"layout" of the menu changes. Its size is always the same as Worms Armageddon's
size, and it always obscures the entire window.
Someone (I don't know if it's the game or Wine doing this) appears to check
which window the mouse is on whenever it moves. The result is always a child of
I tried the demo of Diablo (see bug 2082), and it follows the same pattern: a
main window passed to SetCooperativeLevel, a child window the same size, and
child controls on that window. It also has the same problem, fixed by the same
hack (yay Byte).
Since the hwnds appear to be the same every time, I tried modifying ddraw to
draw to 0x10023, the immediate child of Worms Armageddon. The menu showed up
fine (this is a little odd; I expected only part of the menu to show up and
part of it to be obscured by that window's children).
So the problem seems to be that ddraw is drawing to the area of the SCL window
that isn't obscured by children. I don't know why it's doing this. It already
uses a call to GetDCEx without the DCX_CLIPCHILDREN flag. I also don't know how
to make a test for this or correct the problem.
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the wine-bugs