[Bug 47036] New: Game Yuri' s Revenge Work perfectly in wine-4.5-1 but has problem in wine-4.6-1
https://bugs.winehq.org/show_bug.cgi?id=47036
Bug ID: 47036 Summary: Game Yuri's Revenge Work perfectly in wine-4.5-1 but has problem in wine-4.6-1 Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: zhoujian8585169@126.com Distribution: ---
See https://bugs.archlinux.org/task/62365
Description: Game Command & Conquer: Yuri's Revenge (https://en.wikipedia.org/wiki/Command_%26_Conquer:_Yuri%27s_Revenge) run perfectly in wine-4.5-1 but has problem in wine-4.6-1
Steps to reproduce:
1. sudo pacman -U /var/cache/pacman/pkg/wine-4.5-1-x86_64.pkg.tar.xz 2. WINEARCH=win32 WINEPREFIX=~/.win32 wine ~/sda4/games/yuri/yuri/YURI.EXE run perfectly see image 1 in attach file
3. sudo pacman -U /var/cache/pacman/pkg/wine-4.6-1-x86_64.pkg.tar.xz 4. WINEARCH=win32 WINEPREFIX=~/.win32 wine ~/sda4/games/yuri/yuri/YURI.EXE has problem see image 2.
https://bugs.winehq.org/show_bug.cgi?id=47036
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |4.6 Keywords| |regression CC| |o.dierick@piezo-forte.be Summary|Game Yuri's Revenge Work |C&C Red Alert 2 Yuri's |perfectly in wine-4.5-1 but |Revenge missing graphical |has problem in wine-4.6-1 |elements since wine 4.6 | |(regression)
--- Comment #1 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Please, attach full terminal output from running the game with wine 4.6. Here are instructions: https://wiki.winehq.org/FAQ#How_can_I_get_a_debugging_log_.28a.k.a._terminal...
Performing a regression test between 4.5 and 4.6 could greatly help debug the issue. See how to do it there: https://wiki.winehq.org/Regression_Testing
Regards
https://bugs.winehq.org/show_bug.cgi?id=47036
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
--- Comment #2 from Paul Gofman gofmanp@gmail.com --- Created attachment 64208 --> https://bugs.winehq.org/attachment.cgi?id=64208 +wgl log (current git and current git with the patch reverted)
I tested the game and could reproduce the issue. I've bisected it to commit 0cb79db12ac7c48477518dcff269ccc5d6b745e0 (winex11.drv: Recreate gl_drawable for top-level windows as non-top level when clipping for child windows is required.). Reverting the patch fixes the issue. I am attaching +wgl logs from the run with the current git and with the commit reverted.
https://bugs.winehq.org/show_bug.cgi?id=47036
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mgorrell@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=47036
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |0cb79db12ac7c48477518dcff26 | |9ccc5d6b745e0
https://bugs.winehq.org/show_bug.cgi?id=47036
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|C&C Red Alert 2 Yuri's |C&C Red Alert 2 Yuri's |Revenge missing graphical |Revenge missing graphical |elements since wine 4.6 |elements |(regression) | Component|-unknown |winex11.drv
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #3 from Micah N Gorrell mgorrell@codeweavers.com --- Can you give any more detail on what is missing? I don't have access to the game so I can't try to reproduce the problem myself currently. A screenshot might be helpful.
The commit in question corrects missing graphical elements in other games. I can see from the traces attached that it did recreate the drawable, which means that it found child windows.
I wonder if the problem is caused by the drawable being recreated or by the drawable being created as a DC_GL_CHILD_WIN instead of a DC_GL_WINDOW.
I can provide an alternative version of the patch that always creates windows as DC_GL_CHILD_WIN to determine this. If that patch works then a different method of detecting that there are child windows may be needed. If that patch doesn't work then we need to determine why the rendering fails in this case.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #4 from Paul Gofman gofmanp@gmail.com --- Created attachment 64252 --> https://bugs.winehq.org/attachment.cgi?id=64252 test patch
(In reply to Micah N Gorrell from comment #3)
Can you give any more detail on what is missing?
It draws some skeleton display but text in buttons and some radar inside the main area (child windows probably?) are missing.
I can provide an alternative version of the patch that always creates windows as DC_GL_CHILD_WIN to determine this.
Yes, it works, the attach patch fixes it.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #5 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #4)
Yes, it works, the attach patch fixes it.
Very interesting! So, the act of recreating the drawable appears to be at fault in this case. Unfortunately always creating a DC_GL_CHILD_WIN would likely have a very negative effect on performance for many games.
I wonder if recreating the drawable for any child windows would as well would make it behave.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #6 from Paul Gofman gofmanp@gmail.com --- Created attachment 64253 --> https://bugs.winehq.org/attachment.cgi?id=64253 Test patch 2
(In reply to Micah N Gorrell from comment #5)
I wonder if recreating the drawable for any child windows would as well would make it behave.
Yes, the patch attached fixes it as well.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #7 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #6)
Created attachment 64253 [details] Test patch 2
(In reply to Micah N Gorrell from comment #5)
I wonder if recreating the drawable for any child windows would as well would make it behave.
Yes, the patch attached fixes it as well.
That is different than what I was thinking. I was thinking to let it get recreated, but when you do to find its child windows and recreate their drawables as well at the same time.
Since I don't have access to the game I am going to attempt to create a test app that reproduces the problem along with the issue with clipping for child control windows.
If I can reproduce the problem then I'll experiment a bit and see if I can find a solution that works in both situations.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #8 from Micah N Gorrell mgorrell@codeweavers.com --- Created attachment 64254 --> https://bugs.winehq.org/attachment.cgi?id=64254 Recreate child drawables patch
The attached patch attempts to recreate the drawables of any children along with the parent. Can you try this and see if it helps?
I haven't been able to reproduce the problem with a test app yet, so this solution is just a hunch at this point.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #9 from Paul Gofman gofmanp@gmail.com --- Created attachment 64255 --> https://bugs.winehq.org/attachment.cgi?id=64255 Logs with the patch applied
(In reply to Micah N Gorrell from comment #8)
Created attachment 64254 [details] Recreate child drawables patch
The attached patch attempts to recreate the drawables of any children along with the parent. Can you try this and see if it helps?
No, the issue is still there with the patch. I am attaching +wgl log with the patch applied just in case.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #10 from Paul Gofman gofmanp@gmail.com --- Created attachment 64256 --> https://bugs.winehq.org/attachment.cgi?id=64256 Another tweak which fixes the issue
Here is another tweak which fixes the issue as well. I didn't really go deep into this, but can it be that it is related somehow to child windows clipping flags? Do you need +win log?
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #11 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #10)
Created attachment 64256 [details] Another tweak which fixes the issue
Here is another tweak which fixes the issue as well. I didn't really go deep into this, but can it be that it is related somehow to child windows clipping flags? Do you need +win log?
That patch breaks AoE 2 HD (which is one of the games my patch fixed).
Yeah, +win would help a lot. Recreating the drawables should really only be needed if the parent window has WS_CLIPCHILDREN set.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #12 from Paul Gofman gofmanp@gmail.com --- Created attachment 64259 --> https://bugs.winehq.org/attachment.cgi?id=64259 +wgl,win log
https://bugs.winehq.org/show_bug.cgi?id=47036
Micah N Gorrell mgorrell@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64254|0 |1 is obsolete| |
--- Comment #13 from Micah N Gorrell mgorrell@codeweavers.com --- Created attachment 64260 --> https://bugs.winehq.org/attachment.cgi?id=64260 Only recreate drawables if WS_CLIPCHILDREN is set
If you have time, try this one. This modifies the behavior of my original patch so that it will a window with children can still be created as DC_GL_WINDOW if WS_CLIPCHILDREN isn't set.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #14 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #12)
Created attachment 64259 [details] +wgl,win log
Thanks. I'll look through and see if I can find the flags that were used for the window in question.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #15 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Micah N Gorrell from comment #14)
(In reply to Paul Gofman from comment #12)
Created attachment 64259 [details] +wgl,win log
Thanks. I'll look through and see if I can find the flags that were used for the window in question.
If I'm reading this correctly the window in question was created with WS_POPUP WS_DISABLED WS_CLIPSIBLINGS, so that makes me think my most recent patch may be the right approach.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #16 from Paul Gofman gofmanp@gmail.com --- (In reply to Micah N Gorrell from comment #15)
(In reply to Micah N Gorrell from comment #14)
(In reply to Paul Gofman from comment #12)
Created attachment 64259 [details] +wgl,win log
Thanks. I'll look through and see if I can find the flags that were used for the window in question.
If I'm reading this correctly the window in question was created with WS_POPUP WS_DISABLED WS_CLIPSIBLINGS, so that makes me think my most recent patch may be the right approach.
No, this patch does not fix it. But it seems to me it does not do what you say, if the window is with children this patch change nothing for it.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #17 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #16)
(In reply to Micah N Gorrell from comment #15)
(In reply to Micah N Gorrell from comment #14)
(In reply to Paul Gofman from comment #12)
Created attachment 64259 [details] +wgl,win log
Thanks. I'll look through and see if I can find the flags that were used for the window in question.
If I'm reading this correctly the window in question was created with WS_POPUP WS_DISABLED WS_CLIPSIBLINGS, so that makes me think my most recent patch may be the right approach.
No, this patch does not fix it. But it seems to me it does not do what you say, if the window is with children this patch change nothing for it.
The patch checks for the WS_CLIPCHILDREN flag, and if that is not set then it ignores the known_child bool since that is only needed if WS_CLIPCHILDREN is set.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #18 from Paul Gofman gofmanp@gmail.com --- (In reply to Micah N Gorrell from comment #17)
The patch checks for the WS_CLIPCHILDREN flag, and if that is not set then it ignores the known_child bool since that is only needed if WS_CLIPCHILDREN is set.
Yes, but unless I am missing something if the window has children it won't go into 1st 'if' due to !GetWindow( hwnd, GW_CHILD ), there are just '&&' there. And known_child is not used after.
If you don't mind you can email me directly to reduce the number of messages here.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #19 from Micah N Gorrell mgorrell@codeweavers.com --- (In reply to Paul Gofman from comment #18)
(In reply to Micah N Gorrell from comment #17)
The patch checks for the WS_CLIPCHILDREN flag, and if that is not set then it ignores the known_child bool since that is only needed if WS_CLIPCHILDREN is set.
Yes, but unless I am missing something if the window has children it won't go into 1st 'if' due to !GetWindow( hwnd, GW_CHILD ), there are just '&&' there. And known_child is not used after.
If you don't mind you can email me directly to reduce the number of messages here.
Oh, of course. I'm still on my first cup of coffee for the day :) I'll email you a new version in just a moment.
https://bugs.winehq.org/show_bug.cgi?id=47036
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=47036
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |i@tetsai.net
--- Comment #20 from Fabian Maurer dark.shadow4@web.de --- *** Bug 48058 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47036
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Commander.Alchemy@gmail.com
--- Comment #21 from Fabian Maurer dark.shadow4@web.de --- *** Bug 47683 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=47036
Fabian Maurer dark.shadow4@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download CC| |dark.shadow4@web.de Status|UNCONFIRMED |NEW URL| |https://www.moddb.com/games | |/cc-tiberian-sun/downloads/ | |cc-tiberian-sun-with-firest | |orm-free-full-game Ever confirmed|0 |1
--- Comment #22 from Fabian Maurer dark.shadow4@web.de --- Confirming and adding free download from the other bugreport.
https://bugs.winehq.org/show_bug.cgi?id=47036
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #64208|0 |1 is obsolete| | Attachment #64252|0 |1 is obsolete| | Attachment #64253|0 |1 is obsolete| | Attachment #64255|0 |1 is obsolete| | Attachment #64256|0 |1 is obsolete| | Attachment #64259|0 |1 is obsolete| |
--- Comment #23 from Paul Gofman gofmanp@gmail.com --- Created attachment 65930 --> https://bugs.winehq.org/attachment.cgi?id=65930 Test showing the problem (no fix)
I've retested the issue and found what seems to be actually wrong here.
It seems that the referenced commit which triggered the regression in this game is not the real source of the problem.
The game is using ddraw7 and works in exclusive fullscreen mode. The window which was specified in SetCooperativeLevel has child windows. Clipping of those children in GL drawable was not performed before referenced commit but happens now. That might be correct behaviour for Opengl which does not have exclusive fullscreen mode the same way Directx has. But with Directx the drawing to the primary surface in exclusive mode goes directly to the hardware screen and bypasses gdi, i. e., is rendered on top of anything else on the screen. At the same time, the other windows can still receive input events. The game updates the screen by locking primary surface.
This is somewhat similar to the Bug #11999, with the difference that in Endless Online the rendering window is covered by another top level window, not its child, so the issue was visible and stays there regardless of the commit referenced here. EO works fine in windowed mode. EO is seemingly a Delphi program which creates two top level windows, TApplication and TMainForm. The latter contains clickable GUI elements. In a fullscreen mode ddraw7 SetCooperativeLevel gets TApplication window, while TMainForm is maintained on top and receives user input. Thus under Wine rendering window is hidden behind TMainForm. In windowed mode this wouldn't work on Windows either, so application passes TMainForm window to ddraw in this case.
The workaround which works for both games is to set HKCU\Software\Wine\Direct3D\DirectDrawRenderer to gdi.
I am attaching an interactive test which draws the window on top of the fullscreen exclusive window and does some ddraw rendering by filling primary surface with color. It is a bit unstable for a unit test, as I don't yet see a sure way to read the pixel from the screen as it is seen: reading it from screen DC in Wine after a single draw sometimes returns random values (some sync is seemingly missing). Also one time window creation / ddraw update looks not entirely stable both under Windows and Wine. But with repeated draws it looks stable: the primary surface fill always goes above everything on Windows and on the contrary the second window is always visible with Wine.
Unfortunately I don't yet see a sure fix for that. Both games can be fixed by taking screen DC blit path in ddraw/surface.c:ddraw_surface_update_frontbuffer(), but I suppose this would be just terrible. Ideally we would need some way to get exclusive window from display driver, but I don't yet see any straightforward way to do it. Ensuring somehow that the rendering window is on top through user32 calls is likely not an option, as the windows which are currently on top are supposed to be foreground and receive user input which will be broken if we hide them behind. Maybe it is possible to pass some window property to display driver so that child windows clipping introduced by the referenced commit won't occur for the exclusive fullscreen drawing, but this would be only the partial solution.
https://bugs.winehq.org/show_bug.cgi?id=47036
Bob Duke wine@hiyh.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@hiyh.com
--- Comment #24 from Bob Duke wine@hiyh.com --- Thank you Paul for the detailed investigation and summary.
For those of you affected by this issue, the workaround is to "set HKCU\Software\Wine\Direct3D\DirectDrawRenderer to gdi" as explained by Paul. I've confirmed this works for me with wine-5.0-rc4.
If you are unfamiliar with how to do this, you can run the registry editor by using:
$ wine regedit.exe
In the regedit window, navigate to:
HKEY_CURRENT_USERS\Software\Wine
In the Wine directory, you will see various folders (e.g. Drivers, Debug, etc.). If you do not see a folder named "Direct3D," right click on the Wine folder and select New->Key. A new folder will appear under Wine which you can name "Direct3D."
Then, select Direct3D and in the right pane, right click and select New->StringValue. A new entry will appear in the right pane that you can name "DirectDrawRenderer." Press enter to finish the rename, then right click on DirectDrawRenderer and select Modify. In the pop-up, type "gdi" (with no quotes) in the value data box and select ok.
Finally, select Registry->Exit in the top menubar. The Wine window should close automatically.
Once you do this, you should be able to run the game as usual and the title screen menus will be present.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #25 from Bob Duke wine@hiyh.com --- After updating wine to wine-5.1-1.fc31.x86_64 in Fedora 31, the gdi workaround no longer works. The main menu entries are missing again.
The game appears to play OK if you can (blindly) get past the main menus.
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #26 from Henri Verbeet hverbeet@gmail.com --- (In reply to Bob Duke from comment #25)
After updating wine to wine-5.1-1.fc31.x86_64 in Fedora 31, the gdi workaround no longer works. The main menu entries are missing again.
The issue is likely that you're using the "DirectDrawRenderer" registry setting (as mentioned in comments 23 and 24). That setting was deprecated in Wine 4.0, in favour of the more generic "renderer" setting. In Wine 5.1, the "DirectDrawRenderer" setting was removed.
I.e., try renaming "DirectDrawRenderer" to "renderer".
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #27 from Bob Duke wine@hiyh.com --- Thank you Henri, that fixes it.
https://bugs.winehq.org/show_bug.cgi?id=47036
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #28 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-7.2?
https://bugs.winehq.org/show_bug.cgi?id=47036
--- Comment #29 from Bob Duke wine@hiyh.com --- The game continues to work in 7.2 so it did not break my configuration. Note that I am running with the registry mods suggested in comments 24 and 26.
When I reset my .wine directory, however, the graphical menu glitch returns. So, it is still a problem with version 7.2 "out of the box."
https://bugs.winehq.org/show_bug.cgi?id=47036
mo78@abv.bg changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mo78@abv.bg
--- Comment #30 from mo78@abv.bg --- Running fine with Wine 7.7 and renderer set to gdi. Thanks.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla