http://bugs.winehq.org/show_bug.cgi?id=17215
Summary: Regression in Sid Meier's Alpha Centauri Product: Wine Version: 1.1.3 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-ddraw AssignedTo: wine-bugs@winehq.org ReportedBy: johan.gill@gmail.com
Starting Sid Meier's Alpha Centauri, the title screen is garbage.
A regression test says that fd0e60180a1979e3dd8730bd4922556a73353ea6 is first bad commit commit fd0e60180a1979e3dd8730bd4922556a73353ea6 Author: Roderick Colenbrander thunderbird2k@gmx.net Date: Thu Aug 21 20:51:18 2008 +0000
wined3d: Fix window rewrite regression.
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #1 from Roderick Colenbrander thunderbird2k@gmx.net 2009-02-01 03:42:05 --- It isn't clear to me whether this is the end-result of the regression test or the first patch for which the issue appeared? If it is the last then continue the regression test until you find the real patch.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #2 from Johan Gill johan.gill@gmail.com 2009-02-01 03:45:39 --- It is the first patch.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #3 from Johan Gill johan.gill@gmail.com 2009-02-01 03:48:44 --- And I got that result from running git bisect a number of times. Isn't that the end-result of the regression test?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #4 from Johan Gill johan.gill@gmail.com 2009-02-01 03:55:18 --- Created an attachment (id=19144) --> (http://bugs.winehq.org/attachment.cgi?id=19144) Screenshot showing bad SMAC title screen
"Garbage" may lead the thoughts wrong, so here's a screenshot.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #5 from Johan Gill johan.gill@gmail.com 2009-02-01 03:59:34 --- Restoring ShowWindow after SetWindowPos fixes the title screen. Now what was the issue causing the patch?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #6 from Roderick Colenbrander thunderbird2k@gmx.net 2009-02-01 04:23:25 --- I think it fixed an issue introduced by Stefan his rewrite of the ddraw windowing code. If I remember correctly there was some positioning issue in Red Alert I. Personally I think that some change in the windowing code is the real bug as really hundreds of lines got changed.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #7 from Johan Gill johan.gill@gmail.com 2009-02-01 04:43:13 --- Sounds reasonable. MSDN seems to agree that SetWindowPos could be solely used. This is probably just the trigger commit.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #8 from Johan Gill johan.gill@gmail.com 2009-02-02 13:32:24 --- I'm taking a closer look.
Can someone assign me to this?
http://bugs.winehq.org/show_bug.cgi?id=17215
Michael Mc Donnell michael@mcdonnell.dk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@mcdonnell.dk
--- Comment #9 from Michael Mc Donnell michael@mcdonnell.dk 2009-04-18 04:50:04 --- (In reply to comment #8)
I'm taking a closer look.
John can you reproduce this with wine-1.1.19? I can't reproduce the error.
http://bugs.winehq.org/show_bug.cgi?id=17215
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Regression in Sid Meier's |Sid Meier's Alpha Centauri - |Alpha Centauri |title screen is garbage
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Sid Meier's Alpha Centauri -|Sid Meier's Alpha Centauri - |title screen is garbage |excessive clipping of title | |screen
--- Comment #10 from Johan Gill johan.gill@gmail.com 2009-04-18 16:33:39 --- Beats me, the installer fails now.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #11 from Austin English austinenglish@gmail.com 2009-04-18 17:18:18 --- (In reply to comment #10)
Beats me, the installer fails now.
Bug number?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #12 from Johan Gill johan.gill@gmail.com 2009-04-19 10:35:51 --- I'll create one when I got the time to do the bisect.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #13 from Johan Gill johan.gill@gmail.com 2009-04-24 08:37:36 --- Install seems to work now when an absolute path is given. The clipping seems to be OK with default settings, but *not* in desktop mode.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #14 from Michael Mc Donnell michael@mcdonnell.dk 2009-04-25 03:25:29 --- (In reply to comment #13)
The clipping seems to be OK with default settings, but *not* in desktop mode.
Which resolution are you using? The game doesn't handle being run at other than the default resolutions very well. Your desktop size in winecfg should be set to 1024x768 which is the default resolution. You can alternatively force it to 800x600 if you add the line "Video Mode=800" (with out the quotes) to the section "[Alpha Centauri]" in the "Alpha\ Centauri.Ini" file. See http://apolyton.net/forums/showthread.php?t=143989
I've tried the game in windows in order to see what the correct behavior should be. It's able to switch automatically to 800x600 in windows, if the resolution of the desktop is set to this in windows. The game, however, doesn't show this behavior with wine. It only tries to start the game in 1024x768 even though the desktop size is set to 800x600(unless you force it with the mentioned option).
It seems like this bug might have something to do with desktop screen resolution detection instead? If the game starts up and tries to render at 1024x768 but the resolution is smaller than that, then it pretty obvious why the rest of the screen gets clipped.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #15 from Johan Gill johan.gill@gmail.com 2009-04-25 10:21:20 --- Created an attachment (id=20699) --> (http://bugs.winehq.org/attachment.cgi?id=20699) Screen clipping in 1024x768 desktop
It is 1024x768. Here's a snapshot.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #16 from Johan Gill johan.gill@gmail.com 2009-04-25 10:49:10 --- I forgot to mention that this only happens if the intro movie is run. The intro movie plays in 640x480 resolution.
Coincidence? I think not.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #17 from Michael Mc Donnell michael@mcdonnell.dk 2009-04-27 08:42:21 --- (In reply to comment #16)
I forgot to mention that this only happens if the intro movie is run. The intro movie plays in 640x480 resolution.
Coincidence? I think not.
Ok I can reproduce it now with the following steps:
1. Switch to 1024x768 emulated desktop via winecfg. 2. Start SMAC with the CD inserted. 3. The games switches the resolution to 640x480 and plays the intro. 4. The game switches the resolution back to 1024x768.
The area outside the previous 640x480 surface gets clipped, which is an error.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #18 from Johan Gill johan.gill@gmail.com 2009-07-13 19:29:22 --- Created an attachment (id=22366) --> (http://bugs.winehq.org/attachment.cgi?id=22366) Test program for wine bug
I have created a small test program exposing the bug.
Basically, it goes like this:
Create a 1024x768 window Create a DirectDraw object and associate it to the window Set display mode to 640x480 Create a DirectDraw surface Restore the display mode
On Windows 98 with DirectX 7, GetClientRect gives a 1024x768 rect On Wine, GetClientRect gives a 640x480 rect.
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22366|0 |1 is obsolete| |
--- Comment #19 from Johan Gill johan.gill@gmail.com 2009-07-13 19:32:28 --- Created an attachment (id=22367) --> (http://bugs.winehq.org/attachment.cgi?id=22367) Test program for wine bug
Here's a cleaner version
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22367|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #20 from Johan Gill johan.gill@gmail.com 2009-07-19 17:22:59 --- It seems Wine and Windows handles sizing of fullscreen windows quite differently.
Windows 98 resizes a fullscreen window on mode change, even if there is no surface.
Wine resizes the window when a surface is added, but not on a mode change.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #21 from Johan Gill johan.gill@gmail.com 2009-07-21 09:29:05 --- Created an attachment (id=22501) --> (http://bugs.winehq.org/attachment.cgi?id=22501) Patch to resize fullscreen window when DirectDraw changes the display mode
Patch sent to wine-patches
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22501|0 |1 is obsolete| |
--- Comment #22 from Johan Gill johan.gill@gmail.com 2009-07-21 13:27:35 --- Created an attachment (id=22510) --> (http://bugs.winehq.org/attachment.cgi?id=22510) Patch to resize fullscreen window when DirectDraw changes the display mode
Updated patch, checking that the display mode was changed successfully.
http://bugs.winehq.org/show_bug.cgi?id=17215
Johan Gill johan.gill@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #22510|0 |1 is obsolete| |
--- Comment #23 from Johan Gill johan.gill@gmail.com 2009-07-27 18:32:42 --- Created an attachment (id=22651) --> (http://bugs.winehq.org/attachment.cgi?id=22651) Patch to resize fullscreen window when DirectDraw changes the display mode
Changes are below:
*) Attempted to comment the patch better *) Added a test to show that windows are not resized in the DDSCL_NORMAL case.
http://bugs.winehq.org/show_bug.cgi?id=17215
sub.mesa@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sub.mesa@gmail.com
--- Comment #24 from sub.mesa@gmail.com 2009-08-08 10:24:04 --- Was there any feedback to your patch Johan?
With this bug fixed, SMAC is perfectly playable again with the additional DIB-engine patches enabled. Could your patch be integrated before 1.1.28 release?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #25 from Johan Gill johan.gill@gmail.com 2009-08-10 11:16:08 --- I got feedback, and I'll try to act on them before 1.1.28.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #26 from Johan Gill johan.gill@gmail.com 2009-09-07 16:00:20 --- I've been covered in work lately, so there has been no progress with this. The people responsible want to cover some more issues before changing the code in question, so you'll have to bear with the patch attached here for the moment.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #27 from Johan Gill johan.gill@gmail.com 2010-03-07 02:25:36 --- This got worse for me now: I don't need to use desktop mode to reproduce this on current git.
Stefan: what missing pieces do you need to determine a proper patch?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #28 from Johan Gill johan.gill@gmail.com 2010-03-11 02:28:46 --- Pasting old TODO-list provided by Stefan, so I have it all in one place:
*) Does ddraw change the window params at all, and if yes, when(your test already answers part of that). *) How does restoredisplaymode behave *) Does ddraw restore the display mode on SetCooperativeLevel(DDSCL_NORMAL) *) Does ddraw restore the display mode on ddraw device release? On primary surface release? *) Who restores the display mode on app exit if the ddraw iface is not released? What happens with the window in that case? *) Who restores the display mode on an app crash? *) How does User32.ChangeDisplaySettingsEx FULLSCREEN flag(= temporary mode change) work? *) What happens if two different apps set conflicting FULLSCREEN modes? *) How does the CDS FULLSCREEN flag affect the window?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #29 from Johan Gill johan.gill@gmail.com 2010-03-22 10:39:56 ---
*) Does ddraw restore the display mode on SetCooperativeLevel(DDSCL_NORMAL)
The answer to this seems to be "yes". I have been unsuccessful to create an automated test case for it though, as all my attempts to call IDirectDraw->GetDisplayMode result in DDERR_INVALIDPARAMS.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #30 from Johan Gill johan.gill@gmail.com 2010-03-23 10:49:28 --- Ok, I've solved my testing problems, so here are some results:
Setting the cooperative level back to DDSCL_NORMAL does NOT restore the display mode.
However, releasing the ddraw interface does restore the display mode
Exiting an app without releasing the interface also restores the display mode
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #31 from Johan Gill johan.gill@gmail.com 2010-04-01 06:10:37 --- I've looked further at what happens to the window rect when doing various mode changes:
In DDSCL_NORMAL, the window rect stays the same during all display mode changes In FULLSCREEN/EXCLUSIVE, the window rect is changed whenever the app changes display mode, be it Set or Restore. However, going to FULLSCREEN, changing the display mode and then releasing the ddraw interface without explicitly restoring the display mode does NOT resize the window. The display mode is however restored.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #32 from Johan Gill johan.gill@gmail.com 2010-05-17 05:55:58 --- A correction of SetCooperativeLevel(..., DDSCL_NORMAL) behaviour was committed a while ago.
I have some tests in the pipeline showing that SetCooperativeLevel(..., DDSCL_FULLSCREEN | DDSCL_EXCLUSIVE) should resize and show the window being passed when called, so I think it would be acceptable to add a function to ddraw/<somefile>.c that calls SetWindowPos(hwnd, HWND_TOP, 0, 0, screenx, screeny, SWP_SHOWWINDOW), and then call that from SetCooperativeLevel and SetDisplayModeNoOverride in the fullscreen case.
Any comments? I'd like to have this put out before the 1.2 gets too frozen.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #33 from Johan Gill johan.gill@gmail.com 2010-07-26 17:26:07 --- Patch submitted to wine-patches, although too late for 1.2.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #34 from Michael Mc Donnell michael@mcdonnell.dk 2011-01-22 11:57:03 CST --- (In reply to comment #17)
(In reply to comment #16)
I forgot to mention that this only happens if the intro movie is run. The intro movie plays in 640x480 resolution.
Coincidence? I think not.
Ok I can reproduce it now with the following steps:
- Switch to 1024x768 emulated desktop via winecfg.
- Start SMAC with the CD inserted.
- The games switches the resolution to 640x480 and plays the intro.
- The game switches the resolution back to 1024x768.
The area outside the previous 640x480 surface gets clipped, which is an error.
Can someone please change the status to NEW?
http://bugs.winehq.org/show_bug.cgi?id=17215
Jerome Leclanche adys.wh@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adys.wh@gmail.com
--- Comment #35 from Jerome Leclanche adys.wh@gmail.com 2011-04-01 09:27:28 CDT --- (In reply to comment #33)
Patch submitted to wine-patches, although too late for 1.2.
It seems the patch hasn't been committed: http://source.winehq.org/git/wine.git/?a=search&h=HEAD&st=author&...
Any update?
http://bugs.winehq.org/show_bug.cgi?id=17215
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #36 from Dmitry Timoshkov dmitry@codeweavers.com 2011-04-01 09:46:20 CDT --- Multiple people affected, changing state to NEW.
http://bugs.winehq.org/show_bug.cgi?id=17215
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #37 from joaopa jeremielapuree@yahoo.fr 2011-07-20 15:12:31 CDT --- still a bug in current wine?
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #38 from Michael Mc Donnell michael@mcdonnell.dk 2011-07-23 11:26:22 CDT --- (In reply to comment #37)
still a bug in current wine?
Looks fixed to me. I can't reproduce it in wine-1.3.24.
http://bugs.winehq.org/show_bug.cgi?id=17215
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |wylda@volny.cz Resolution| |FIXED
--- Comment #39 from Wylda wylda@volny.cz 2011-07-23 12:17:45 CDT ---
Reported fixed. Johan feel free to reopen if the problem persist for you.
http://bugs.winehq.org/show_bug.cgi?id=17215
--- Comment #40 from Henri Verbeet hverbeet@gmail.com 2011-07-23 13:24:21 CDT --- Probably 04d541c26d4f50af2bf306dc11943bd12b26f233 or 84413298de371a9e9b9ecfe0dd01f580b7521222.
http://bugs.winehq.org/show_bug.cgi?id=17215
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #41 from Alexandre Julliard julliard@winehq.org 2011-08-05 12:38:05 CDT --- Closing bugs fixed in 1.3.26.
http://bugs.winehq.org/show_bug.cgi?id=17215
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-ddraw |directx-d3d