https://bugs.winehq.org/show_bug.cgi?id=50370
Bug ID: 50370 Summary: Gothic 1 doesn't start correctly when screen resolution of the game matches display resolution Product: Wine Version: 5.13 Hardware: x86-64 URL: https://www.fileplanet.com/archive/p-5260/Gothic-Demo- English OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com CC: rbernon@codeweavers.com Regression SHA1: f90d607c67768f19e36d9d74b498594252faa3fd Distribution: ---
I'm starting Gothic 1 v1.08k using in-game resolution 1440x900 which matches my native display resolution. The game does start up because I can hear the sound of the intro movie, but no visible window is created (the screen is black).
This used to work up until commit f90d607c67768f19e36d9d74b498594252faa3fd ddraw: Use the WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES flag.
Reverting that commit on top of 6.0-rc3 fixes the problem for me.
To reproduce the problem in the demo: 1. Before starting the game modify GOTHIC.INI located in the Program Files/Piranha Bytes/Gothic 1 Demo/system directory. Look for the section [Video] and change in-game screen resolution there so that it matches your display resolution: zVidResFullscreenX= zVidResFullscreenY=
You also need to set 32-bit color depth (the problem doesn't occur with 16-bit): zVidResFullscreenBPP=32
2. run gothic.exe
setupg1demo-en.exe md5sum: 2932bcb79118abadca0d394a7a86c096
wine-6.0-rc3 OpenGL vendor string: NVIDIA Corporation OpenGL renderer string: GeForce GT 730/PCIe/SSE2 OpenGL core profile version string: 4.6.0 NVIDIA 455.46.04
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #1 from Béla Gyebrószki gyebro69@gmail.com --- The same commit also breaks the game Black and White (2001) especially when running the game in virtual desktop mode. After the intro clip ends the game completely "disappears" from the virtual desktop albeit it is running. In fullscreen mode the game is minimized to the taskbar after the intro and I can restore it by clicking on it. This doesn't occur with the commit reverted.
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael B toxatec@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gabrielopcode@gmail.com, | |toxatec@web.de
--- Comment #2 from Michael B toxatec@web.de --- I dug around a bit to see if I can help. Now at least I know it's a little complicated.
I think this is the call stack where something is missing (not where the window would appear, that seems to come later):
=> user32:SetWindowPos(.., flags) # here the SWP_SHOWWINDOW flag is not set d3d:wined3d_swapchain_state_setup_fullscreen() d3d:wined3d_device_reset() ddraw:ddraw7_CreateSurface() GOTHIC.EXE
So first, WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES is not being set in ddraw:ddraw_attach_d3d_device() since commit f90d607c67768f19e36d9d74b498594252faa3fd
As a result, in d3d:wined3d_swapchain_state_setup_fullscreen(), SWP_SHOWWINDOW is not being set in the flags passed to user32:SetWindowPos(), a check introduced in the preceding commit e041ff1f91f2143c9710b70cbdc128c9a40e7a09
I'm not sure what SetWindowPos() does with that flag, but when I use winedbg to sneak it in before it is called by wined3d_swapchain_state_setup_fullscreen() or just revert e041ff1f91f2143c9710b70cbdc128c9a40e7a09, the window will appear.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #3 from Michael B toxatec@web.de --- (In reply to Michael B from comment #2)
So first, WINED3D_SWAPCHAIN_NO_WINDOW_CHANGES is not being set in ddraw:ddraw_attach_d3d_device() since commit f90d607c67768f19e36d9d74b498594252faa3fd
Of course that flag *is* being set since that commit, sorry. I submitted by accident before I could check it again.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #4 from Henri Verbeet hverbeet@gmail.com --- Created attachment 69102 --> https://bugs.winehq.org/attachment.cgi?id=69102 patch
The attached patch helps here. Still needs tests.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Henri Verbeet from comment #4)
Created attachment 69102 [details] patch
The attached patch helps here. Still needs tests.
Thanks for your time for looking into this. The patch indeed fixes the issue in Gothic. The problem remains in Black & White, though.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #6 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Created attachment 69123 --> https://bugs.winehq.org/attachment.cgi?id=69123 Show the window and change its topmost style when changing exclusive cooperative mode.
Does this patch help? According to tests, when changing exclusive cooperative mode, the window becomes visible and topmost (and non-topmost when it is removed, but not hidden).
Note that the tests have todo_wine because the other styles don't match up (this is a known issue, other tests also suffer from it), however the important styles which are WS_VISIBLE and WS_EX_TOPMOST *do* match up with this patch.
If it doesn't fix the regression I'll send it after code freeze, though.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #7 from Michael B toxatec@web.de --- (In reply to Gabriel Ivăncescu from comment #6)
Created attachment 69123 [details] Show the window and change its topmost style when changing exclusive cooperative mode.
Does this patch help? According to tests, when changing exclusive cooperative mode, the window becomes visible and topmost (and non-topmost when it is removed, but not hidden).
Gabriel, thanks for getting back at this. It does fix Gothic 1 for me. I can't test Black & White, though. Béla?
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #8 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Gabriel Ivăncescu from comment #6)
Created attachment 69123 [details] Show the window and change its topmost style when changing exclusive cooperative mode.
Does this patch help? According to tests, when changing exclusive cooperative mode, the window becomes visible and topmost (and non-topmost when it is removed, but not hidden).
Note that the tests have todo_wine because the other styles don't match up (this is a known issue, other tests also suffer from it), however the important styles which are WS_VISIBLE and WS_EX_TOPMOST *do* match up with this patch.
If it doesn't fix the regression I'll send it after code freeze, though.
The patch fixes the issue in Black & White, too.
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #9 from Gabriel Ivăncescu gabrielopcode@gmail.com --- Thanks for testing! I sent it to wine-devel (hopefully makes it to wine-6.0).
https://bugs.winehq.org/show_bug.cgi?id=50370
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=50370
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fgouget@codeweavers.com Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=50370
--- Comment #10 from Michael B toxatec@web.de --- I just tested it with wine-6.12 and the bug is still present. Not surprising since the patch wasn't accepted. For reference here is the discussion on wine-devel: https://www.winehq.org/pipermail/wine-devel/2021-January/179018.html
https://bugs.winehq.org/show_bug.cgi?id=50370
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |a384da88655aa6e8e063c5eb361 | |a2339af7ffe6f Resolution|--- |FIXED
--- Comment #11 from Béla Gyebrószki gyebro69@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commit/a384da88655aa6e8e063c5eb361a23...
Thank you Gabriel for your hard work in fixing this bug.
https://bugs.winehq.org/show_bug.cgi?id=50370
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 7.1.
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6.0.x
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|6.0.x |7.0.x
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|7.0.x |---
--- Comment #13 from Michael Stefaniuc mstefani@winehq.org --- Removing the 6.0.x milestone from bug fixes included in 6.0.4.
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |7.0.x
https://bugs.winehq.org/show_bug.cgi?id=50370
Michael Stefaniuc mstefani@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|7.0.x |---
--- Comment #14 from Michael Stefaniuc mstefani@winehq.org --- Removing the 7.0.x milestone from bug fixes included in 7.0.1.