http://bugs.winehq.org/show_bug.cgi?id=30814
Bug #: 30814 Summary: Age of Empires II scrolling gets stuck after Alt-Tab away and back Product: Wine Version: 1.5.5 Platform: x86-64 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: nemesis@icequake.net Classification: Unclassified
Wine 1.2 did not have this problem but was much slower. Wine 1.5.5 is much faster and just a much better overall experience with this one caveat.
If you start a game and immediately alt-tab away and back, nothing is amiss. You can even click on some things onscreen and there is no problem.
However, once you have scrolled the screen either by moving the mouse towards the edges, or by using the arrow keys on the keyboard, if you alt-tab away and back, upon returning the screen will immediately begin to scroll in an apparently random direction and cannot be stopped.
I did the WINEDEBUG="+cursor,+dinput,+ddraw" winedbg Age2_x1/age2_x1.exe and did not come up with anything obviously wrong while the problem was occurring. A lot of this kind of stuff:
trace:ddraw:surface_lock locked surface returning description : trace:ddraw:DDRAW_dump_members - DDSD_CAPS : DDSCAPS_OFFSCREENPLAIN DDSCAPS_VIDEOMEMORY DDSCAPS_LOCALVIDMEM trace:ddraw:DDRAW_dump_members - DDSD_HEIGHT : 768 trace:ddraw:DDRAW_dump_members - DDSD_WIDTH : 1024 trace:ddraw:DDRAW_dump_members - DDSD_PITCH : 1024 trace:ddraw:DDRAW_dump_members - DDSD_PIXELFORMAT : ( DDPF_PALETTEINDEXED8 DDPF_RGB , RGB bits: 8, R 00 G 00 B 00) trace:ddraw:ddraw_surface1_Unlock iface 0xa2f01a8, data 0xbf44020. trace:ddraw:ddraw_surface7_Unlock iface 0xa2f0198, rect (null). trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:SetCursor (nil) trace:ddraw:ddraw_surface1_Blt iface 0xa303ef8, dst_rect (0,0)-(24,32), src_surface 0xa2f01a8, src_rect (885,649)-(909,681), flags 0x1000000, fx (nil). trace:ddraw:ddraw_surface7_Blt iface 0xa303ee8, dst_rect (0,0)-(24,32), src_surface 0xa2f0198, src_rect (885,649)-(909,681), flags 0x1000000, fx (nil). trace:ddraw:ddraw_surface1_GetClipper iface 0xa2f01a8, clipper 0x33c81c. trace:ddraw:ddraw_surface7_GetClipper iface 0xa2f0198, clipper 0x33c81c. trace:ddraw:ddraw_surface1_SetColorKey iface 0xa305188, flags 0x8, color_key 0x33c7f8. trace:ddraw:ddraw_surface7_SetColorKey iface 0xa305178, flags 0x8, color_key 0x33c7f8. trace:ddraw:ddraw_surface7_EnumAttachedSurfaces iface 0xa305178, context 0x33c7b8, callback 0x7e72abb0. trace:ddraw:ddraw_surface7_EnumAttachedSurfaces end of enumeration. trace:ddraw:ddraw_surface1_BltFast iface 0xa2f01a8, dst_x 885, dst_y 649, src_surface 0xa305188, src_rect (0,0)-(24,32), flags 0x11. trace:ddraw:ddraw_surface7_BltFast iface 0xa2f0198, dst_x 885, dst_y 649, src_surface 0xa305178, src_rect (0,0)-(24,32), flags 0x11. trace:ddraw:ddraw_surface1_Blt iface 0xa4777f0, dst_rect (0,0)-(1024,768), src_surface 0xa2f01a8, src_rect (0,0)-(1024,768), flags 0x1000000, fx (nil). trace:ddraw:ddraw_surface7_Blt iface 0xa4777e0, dst_rect (0,0)-(1024,768), src_surface 0xa2f0198, src_rect (0,0)-(1024,768), flags 0x1000000, fx (nil). trace:ddraw:ddraw_clipper_GetClipList iface 0x151748, rect (0,0)-(1024,768), clip_list (nil), clip_list_size 0x33c7b8. trace:ddraw:ddraw_clipper_GetClipList iface 0x151748, rect (0,0)-(1024,768), clip_list 0xa52ab90, clip_list_size 0x33c7b8. trace:ddraw:ddraw_palette_SetEntries iface 0x143150, flags 0, start 0, count 256, entries 0x9192a0. trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649 trace:cursor:X11DRV_GetCursorPos pointer at (885,649) server pos 885,649
Let me know what I can do to help debug.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #1 from nemesis@icequake.net 2012-05-31 14:19:14 CDT --- Created attachment 40352 --> http://bugs.winehq.org/attachment.cgi?id=40352 Log of session while symptoms are there
http://bugs.winehq.org/show_bug.cgi?id=30814
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #2 from joaopa jeremielapuree@yahoo.fr 2012-05-31 14:20:49 CDT --- Does it happen with the demo http://www.microsoft.com/games/age2/downloads.htm
http://bugs.winehq.org/show_bug.cgi?id=30814
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.microsoft.com/ga | |mes/age2/downloads.htm CC| |00cpxxx@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30814
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #3 from Austin English austinenglish@gmail.com 2012-05-31 15:45:09 CDT --- Please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #4 from nemesis@icequake.net 2012-06-01 12:27:44 CDT --- Bisecting is proving to be difficult since the game crashes on all wine-1.4 revisions and the problem first appears in wine-1.5. What can I use as a starting point between wine-1.4 and wine-1.5?
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #5 from Austin English austinenglish@gmail.com 2012-06-01 21:49:50 CDT --- (In reply to comment #4)
Bisecting is proving to be difficult since the game crashes on all wine-1.4 revisions and the problem first appears in wine-1.5. What can I use as a starting point between wine-1.4 and wine-1.5?
Use 1.2, which you know worked.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #6 from nemesis@icequake.net 2012-06-01 22:06:49 CDT --- ... which bisecting with 1.5.5 ends up somewhere in 1.4 and crashes ...
I found that 1.3.0 works and does not crash while 1.3.37 crashes in the same way as 1.4.x I am bisecting that at the moment attempting to find the guilty patch so I can perhaps apply it to 1.4.x while bisecting between 1.3.0 and 1.5.5
http://bugs.winehq.org/show_bug.cgi?id=30814
PommeGolden lapommegolden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lapommegolden@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #7 from Xhip a25422@ua.pt 2012-08-07 23:40:48 CDT --- Hi :).
Any news on this particular bug?
I'm running Age Empires II on built Wine 1.4.1. It is running absolutely amazing, with only 1 critical bug left, which is this annoying bug :(.
Any progress?
Thx for the help :).
http://bugs.winehq.org/show_bug.cgi?id=30814
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #8 from Dan Kegel dank@kegel.com 2012-08-08 08:37:00 CDT --- Still waiting for results of a regression test, if you can help with that it would speed things up.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #9 from nemesis@icequake.net 2012-08-08 10:24:37 CDT --- I was personally unable to complete the regression test due to too many unbuildable revisions in the bisect. Maybe someone else will have better luck.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #10 from Xhip a25422@ua.pt 2012-08-09 08:34:56 CDT --- Ok :). I'm not an expert on this, but I did the regression testing. I followed the link above, did all the steps very carefully and all went ok. I bisected between 1.2 (which worked ok, like mentioned above) and 1.4.1 (which bugged, for me). I never had any crashes, all went ok :).
I got the following final regression testing report, identifying the faulty patch:
36c76dcc24c1f66ccbfeb55495da4794c74dc868 is the first bad commit commit 36c76dcc24c1f66ccbfeb55495da4794c74dc868 Author: Alexandre Julliard julliard@winehq.org Date: Thu Feb 2 17:19:34 2012 +0100
winex11: Update only the key state on KeymapNotify without sending fake key events.
:040000 040000 754d057e6bda93e0d5c454eb051602eef770444c 8b947217b0b974911319a4c2a1c06c91b2c828f0 M dlls :040000 040000 2431d4efc229ee39ff33c47ac29b6cb8450b561f f9e80019e292e8750db8cc59428370d00d120092 M include :040000 040000 eed994c8640dae494c084ff85c9656949b4a556a 5f737723b41556164f2c06954e30c5b72c718394 M server
Can the issue be fixed with a source patch? Thx for the help! :).
http://bugs.winehq.org/show_bug.cgi?id=30814
Xhip a25422@ua.pt changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=30814
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |36c76dcc24c1f66ccbfeb55495d | |a4794c74dc868
http://bugs.winehq.org/show_bug.cgi?id=30814
Brandon Corujo haku08879@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |haku08879@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30814
bshalm@broadpark.no changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bshalm@broadpark.no
--- Comment #11 from bshalm@broadpark.no 2013-04-07 16:34:32 CDT --- I think the problem is that GetKeyboardState after ALT-TAB returns the 0x40 bit! GetKeyboardState documentation only documents LSB and MSB, so maybe they just do something like "if (state[VK_LEFT])"
I modified the code to remove everything but LSB and MSB, now it is almost perfect: If I ALT-TAB while holding a scrollkey, it will continue scrolling until I hit that key again.
BOOL WINAPI DECLSPEC_HOTPATCH GetKeyboardState( LPBYTE state ) { BOOL ret; BOOL yo; int i;
TRACE("(%p)\n", state);
memset( state, 0, 256 ); SERVER_START_REQ( get_key_state ) { req->tid = GetCurrentThreadId(); req->key = -1; wine_server_set_reply( req, state, 256 ); ret = !wine_server_call_err( req ); } SERVER_END_REQ;
yo = state[VK_LEFT] || state[VK_UP] || state[VK_RIGHT] || state[VK_DOWN];
if (yo) ERR("not-fixed: l=%02x u=%02x r=%02x d=%02x\n", state[VK_LEFT], state[VK_UP], state[VK_RIGHT], state[VK_DOWN]);
for (i = 0; i < 256; ++i) state[i] &= 0x81; // remove everything but LSB and MSB!
if (yo) ERR(" fixed: l=%02x u=%02x r=%02x d=%02x\n", state[VK_LEFT], state[VK_UP], state[VK_RIGHT], state[VK_DOWN]);
return ret; }
*before alt-tab* err:win:GetKeyboardState fixed: l=00 u=00 r=80 d=01 err:win:GetKeyboardState not-fixed: l=00 u=81 r=80 d=01 err:win:GetKeyboardState fixed: l=00 u=81 r=80 d=01 err:win:GetKeyboardState not-fixed: l=00 u=81 r=80 d=01 err:win:GetKeyboardState fixed: l=00 u=81 r=80 d=01 *after alt-tab* err:win:GetKeyboardState not-fixed: l=40 u=41 r=40 d=00 err:win:GetKeyboardState fixed: l=00 u=01 r=00 d=00 err:win:GetKeyboardState not-fixed: l=40 u=41 r=40 d=00 err:win:GetKeyboardState fixed: l=00 u=01 r=00 d=00 err:win:GetKeyboardState not-fixed: l=40 u=41 r=40 d=00 err:win:GetKeyboardState fixed: l=00 u=01 r=00 d=00
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #12 from nemesis@icequake.net 2013-04-07 16:58:31 CDT --- I could be wrong but I think AOE2 always did that key-sticking when you alt-tab, even on windows. The important part is to be able to recover from it when you go back to the game.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #13 from bshalm@broadpark.no 2013-04-07 17:30:44 CDT --- (In reply to comment #12)
I could be wrong but I think AOE2 always did that key-sticking when you alt-tab, even on windows. The important part is to be able to recover from it when you go back to the game.
I tried a bit in VirtualBox now. I was able to get Age of Empires II: The Age of Kings (version 2.0a) to continue scrolling sometimes, but for some reason not (the expansion pack) The Conquerors (version 1.0c).
In Wine, if I first hold an arrow key, ALT-TAB out, release the arrow key, ALT-TAB back into the game, then GetKeyboardState() will still return the arrow key as pressed (0x80|0x40). This looks a bit weird to me, but perhaps WinAPI is supposed to be that way.
http://bugs.winehq.org/show_bug.cgi?id=30814
K1773R K1773R@darkgamex.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |K1773R@darkgamex.ch
--- Comment #14 from K1773R K1773R@darkgamex.ch 2013-04-21 10:44:53 CDT --- (In reply to comment #13)
(In reply to comment #12)
I could be wrong but I think AOE2 always did that key-sticking when you alt-tab, even on windows. The important part is to be able to recover from it when you go back to the game.
I tried a bit in VirtualBox now. I was able to get Age of Empires II: The Age of Kings (version 2.0a) to continue scrolling sometimes, but for some reason not (the expansion pack) The Conquerors (version 1.0c).
In Wine, if I first hold an arrow key, ALT-TAB out, release the arrow key, ALT-TAB back into the game, then GetKeyboardState() will still return the arrow key as pressed (0x80|0x40). This looks a bit weird to me, but perhaps WinAPI is supposed to be that way.
thats correct, WinAPI is supposed to be this way.
But thats no reason to have the same faulty API in wine ;)
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #15 from joaopa jeremielapuree@yahoo.fr 2013-04-21 11:33:33 CDT --- If the bugs occurs in Windows, it is not a wine bug. This bug can be closed as INVALID.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #16 from bshalm@broadpark.no 2013-04-21 11:52:22 CDT --- (In reply to comment #14)
(In reply to comment #13)
(In reply to comment #12) In Wine, if I first hold an arrow key, ALT-TAB out, release the arrow key, ALT-TAB back into the game, then GetKeyboardState() will still return the arrow key as pressed (0x80|0x40). This looks a bit weird to me, but perhaps WinAPI is supposed to be that way.
thats correct, WinAPI is supposed to be this way.
But thats no reason to have the same faulty API in wine ;)
Windows behaves different. It will return the key as pressed until 1) I move the mouse over the window 2) I press some key on the keyboard Wine will return the key as pressed until the same key gets a release event.
(In reply to comment #15)
If the bugs occurs in Windows, it is not a wine bug. This bug can be closed as INVALID.
The main bug is definitely in wine. Wine also behaves slightly different as described above.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #17 from K1773R K1773R@darkgamex.ch 2013-04-21 13:06:01 CDT --- (In reply to comment #15)
If the bugs occurs in Windows, it is not a wine bug. This bug can be closed as INVALID.
thats a horrible statement, why should wine not have a correct implementation? if a WinAPI is broken then ours should be broken too? sure...
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #18 from joaopa jeremielapuree@yahoo.fr 2013-04-21 13:14:49 CDT ---
if a WinAPI is broken then ours should be broken too?
yes, because some applications use workarounds that are not compatible with the supposed correct implementation of the API. This would make the application unworking.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #19 from K1773R K1773R@darkgamex.ch 2013-04-21 13:21:51 CDT --- (In reply to comment #18)
if a WinAPI is broken then ours should be broken too?
yes, because some applications use workarounds that are not compatible with the supposed correct implementation of the API. This would make the application unworking.
i agree, though if this specific part would work OK then all the workarounds (ie, reread current keys) wouldnt be broken too. so it would make the workarounds meaningless (and not break em, they would still be executed but have no effect) since the API does it correct.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #20 from nemesis@icequake.net 2013-04-21 17:57:17 CDT --- (In reply to comment #15)
This bug can be closed as INVALID.
No, don't listen to this. A program that works in Windows should work the same in Wine. This is a regression since the program worked in Wine the same as Windows until a certain revision. The bug is certainly not INVALID and should not be closed.
http://bugs.winehq.org/show_bug.cgi?id=30814
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #21 from Bruno Jesus 00cpxxx@gmail.com 2013-08-16 15:35:59 CDT --- I can confirm this issue in wine 1.7.
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #22 from Raditz12 a25422@ua.pt 2013-09-03 12:31:05 CDT --- This bug is real and present.
A workaround to fix it is this simple patch:
==== diff --git a/dlls/user32/input.c b/dlls/user32/input.c index c6f036f..4fd32ef 100644 --- a/dlls/user32/input.c +++ b/dlls/user32/input.c @@ -601,1 +601,1 @@ SHORT WINAPI DECLSPEC_HOTPATCH GetKeyState(INT vkey) - if (!wine_server_call( req )) retval = (signed char)reply->state; + if (!wine_server_call( req )) retval = (signed char)reply->state & ~0x40; @@ -624,1 +624,3 @@ BOOL WINAPI DECLSPEC_HOTPATCH GetKeyboardState( LPBYTE state ) - ret = !wine_server_call_err( req ); + ret = !wine_server_call_err( req ); + int i = 255; + for (; i >= 0; state[i--] &= ~0x40); ====
It works for me, to fix this issue.
http://bugs.winehq.org/show_bug.cgi?id=30814
Arturo Mann arturo.mann@artgraf.biz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |arturo.mann@artgraf.biz
--- Comment #23 from Arturo Mann arturo.mann@artgraf.biz --- As of wine 1.7.8, i can confirm this issue in Kubuntu 13.04.
http://bugs.winehq.org/show_bug.cgi?id=30814
Jonas Jelten jonas.jelten@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jonas.jelten@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #24 from nemesis@icequake.net --- Maybe this could be tested against this particular bug that was fixed in an unofficial patch? I'm not sure it's the same as the Alt-Tab bug, but it could be related.
http://gaming.stackexchange.com/questions/20826/the-age-of-empires-ii-scroll...
http://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #25 from Raditz12 a25422@ua.pt --- It's not the same bug, altough the effect is the same. I'm using the UserPatch mentioned in the link above and the Wine alt+tab bug is still there by default.. as it's 100% Wine related.
I would like to know if the patch code I presented above works with other people, as it fixes the Wine alt+tab bug 100% for me :). As a matter of fact, that patch code was made by the UserPatch creator himself, specifically for Wine source :).
https://bugs.winehq.org/show_bug.cgi?id=30814
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #26 from Stefan Dösinger stefan@codeweavers.com --- In Wine 1.7.32 alt-tab handling in ddraw games has been improved considerably. The description of this bug seems somewhat unrelated to the changes I made, but it is still worth retesting the bug.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #27 from Bruno Jesus 00cpxxx@gmail.com --- The issue is still present in wine-git, it's simple to reproduce. Just start the Falkirk battle scenario (last from the first campaign), then hold the down key for a few seconds, release it and alt-tab. When you go back to the game the screen will keep moving down forever.
Now alt-tabbing restores the original screen resolution which is awesome.
https://bugs.winehq.org/show_bug.cgi?id=30814
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #28 from Béla Gyebrószki gyebro69@gmail.com --- Bug #27232 describes a similar problem, even the commit that caused the regression in 27232 is the same.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #29 from Stefan Dösinger stefan@codeweavers.com --- Does scrolling stop if you press the down key again?
https://bugs.winehq.org/show_bug.cgi?id=30814
eng442@ymail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |eng442@ymail.com
--- Comment #30 from eng442@ymail.com --- I'm using Wine 1.7.33 and haven't applied any of the patches and the bug is present. A workaround for users of WMs that support workspaces and keyboard shortcuts to switch between them is to have a workspace just for AoE, so instead of Alt+Tab you switch to a different workspace for other things. You can Alt+Tab there as much as you like and the game will run smoothly (just don't Alt+Tab on AoE's workspace). You can also switch workspaces as much as you like. I tested this with xmonad only.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #31 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Stefan Dösinger from comment #29)
Does scrolling stop if you press the down key again?
No, nothing makes it stop.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #32 from eng442@ymail.com --- Bug present in wine-staging too.
https://bugs.winehq.org/show_bug.cgi?id=30814
floydian.embryo@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |floydian.embryo@yahoo.com
--- Comment #33 from floydian.embryo@yahoo.com --- This bug is still present in Wine 1.7.44, but it was there in earlier versions as well (1.7.37 iirc). However, it's strange since it doesn't happen all the time, so I can't reproduce exactly the steps, but it's there.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #34 from bshalm@broadpark.no --- (In reply to Embryo from comment #33)
This bug is still present in Wine 1.7.44, but it was there in earlier versions as well (1.7.37 iirc). However, it's strange since it doesn't happen all the time, so I can't reproduce exactly the steps, but it's there.
For a reproducer just create a simple Windows program ( http://www.winprog.org/tutorial/simple_window.html ) and print the output of GetKeyboardState every second. If you alt-tab while holding keys, the 0x40 bit (which I believe is something wine internal) should stick. I don't have wine or windows available anymore so I can't help you more than this.
https://bugs.winehq.org/show_bug.cgi?id=30814
Jimmy Berry jimmy@boombatower.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jimmy@boombatower.com
--- Comment #35 from Jimmy Berry jimmy@boombatower.com --- If anyone is unclear. I have played lots and lots of AoE II both no-expansion, expansion, various patches, and HD since its release. In the update versions of HD and expansion the alt+tab issue does not result in stuck scrolling on Windows. It does in Wine. Can we please fix this as it is clearly a bug and from the posted patch a trivial one at that.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #36 from Jimmy Berry jimmy@boombatower.com --- Created attachment 52463 --> https://bugs.winehq.org/attachment.cgi?id=52463 Workaround by Raditz12 (rerolled)
From testing against patched wine 1.7.51 I can confirm this patch solves the
scroll lock problem.
On a related note, I see that keyboard shortcuts (like h for tc, or building shortcuts) stop working sometimes (not always) after alt+tab regardless of patch.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #37 from Embryo floydian.embryo@yahoo.com --- I encountered the problem of keyboard shortcuts not working as well after alt+tab, however it's an easy fix, just press Alt (if I recall it correctly, if not Ctrl). It could be you need to press Alt twice after alt+tabbing back into the game.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #38 from Jimmy Berry jimmy@boombatower.com --- What will it take to close out this bug? If someone can clarify what needs to be done perhaps I can take a stab at it. Otherwise, this just seem rather silly.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #39 from Stefan Dösinger stefan@codeweavers.com --- I don't know the keyboard code well enough to give a qualified answer here. The best bet is probably to send the patch to wine-devel for comments, and / or ping Alexandre about it on IRC.
A few questions that are in my mind about it:
*) What is the magic flag 0x40? The existing code already uses it a couple of times, so it's not something you added. Still I have no idea what it does. *) Are there other flags that need to be removed?
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #40 from Raditz12 a25422@ua.pt --- (In reply to Jimmy Berry from comment #36)
On a related note, I see that keyboard shortcuts (like h for tc, or building shortcuts) stop working sometimes (not always) after alt+tab regardless of patch.
Hmmm, I don't have those problems, but I'm using an older version of Wine (1.4.1).
With this version + patch above + http://source.winehq.org/git/wine.git/patch/c09c82b25a3c95e79f23f22571fe9a63... + winetricks directplay, the game is running virtually 100% perfect in all areas, including real multiplayer play.
https://bugs.winehq.org/show_bug.cgi?id=30814
Stefan Dösinger stefandoesinger@gmx.at changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|stefan@codeweavers.com |stefandoesinger@gmx.at
https://bugs.winehq.org/show_bug.cgi?id=30814
mrdeathjr28@yahoo.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es
https://bugs.winehq.org/show_bug.cgi?id=30814
gotziem@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gotziem@gmail.com
--- Comment #41 from gotziem@gmail.com ---
(In reply to Jimmy Berry from comment #36)
On a related note, I see that keyboard shortcuts (like h for tc, or building shortcuts) stop working sometimes (not always) after alt+tab regardless of patch.
Hmmm, I don't have those problems, but I'm using an older version of Wine (1.4.1).
With this version + patch above + http://source.winehq.org/git/wine.git/patch/ c09c82b25a3c95e79f23f22571fe9a63b38b824c + winetricks directplay, the game is running virtually 100% perfect in all areas, including real multiplayer play.
Would you mind explain how to install the patches you have made?(In reply to Raditz12 from comment #40)
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #42 from K1773R K1773R@darkgamex.ch --- (In reply to gotziem from comment #41)
(In reply to Jimmy Berry from comment #36)
On a related note, I see that keyboard shortcuts (like h for tc, or building shortcuts) stop working sometimes (not always) after alt+tab regardless of patch.
Hmmm, I don't have those problems, but I'm using an older version of Wine (1.4.1).
With this version + patch above + http://source.winehq.org/git/wine.git/patch/ c09c82b25a3c95e79f23f22571fe9a63b38b824c + winetricks directplay, the game is running virtually 100% perfect in all areas, including real multiplayer play.
Would you mind explain how to install the patches you have made?(In reply to Raditz12 from comment #40)
https://wiki.winehq.org/Patching https://wiki.winehq.org/Building_Wine
https://bugs.winehq.org/show_bug.cgi?id=30814
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winetest@luukku.com
--- Comment #43 from winetest@luukku.com --- I quickly browsed the bug report. I didnt see anyone mention that this bug report is most likely a dupe of bug 27232. It has the same regression id. And it's reported against 1.3.19 wine. Much older than this here.
https://bugs.winehq.org/show_bug.cgi?id=30814
Michal Suchanek hramrach@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hramrach@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=30814
fouf other@jarmash.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |other@jarmash.com
--- Comment #44 from fouf other@jarmash.com --- I have found a temporary solution for those who do not want to apply a patch. On the top right, hit one of the buttons (such as the objective one that is a bunch of checkmarks in boxes, or the diplomacy tab), and while it is up, just press all the arrow keys and go back. It should un-stick the scrolling. You can do this to reset it anytime it happens.
Still very annoying, but at least it doesn't ruin the whole game.
https://bugs.winehq.org/show_bug.cgi?id=30814
f_bugzilla@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |f_bugzilla@outlook.com
--- Comment #45 from f_bugzilla@outlook.com --- Hi all,
I found this explanation/fix in a post from the Steam forum (thanks, Sulix!), which seems to solve the issue for me, but requires a binary patch to the game: https://steamcommunity.com/app/221380/discussions/2/622954302095447538/#c154...
Does anybody else want to try it and see if it works for them? The game binary has changed since the above post, but I opened AoK HD.exe in a hex editor and instead of going to the specified offset I just searched for the sequence 80 3C 01 01, and there was only a single match (and it wasn't too far off from the offset mentioned in the post).
Of course, the disadvantage is that this needs to be re-done after each update.
Quote from the forum post:
The game is using the GetKeyboardState() function to read the arrow keys (and other keys), and is not checking the result correctly. The MSDN documentation for the function only defines the low bit (0x01, meaning that the key is "toggled" à la Caps Lock) and the high bit (0x80, meaning that the key is pressed). Age of Empires (both 1 and 2) check if the key is pressed by checking if the result is > 1. This works most of the time, as it does not depend on the low bit. However, the undefined "middle" bits are occasionally used by windows/wine internals, and are not guaranteed to be zero. The game should check only the high bit (by ANDing it with 0x80).
I've patched version 5.0 to do this for the arrow keys (replace 80 3C 01 01 at offset 0x4525D4 with 80 24 01 80 and 0F 97 C0 at 0x4525DB with 0F 95 C0 in AoK HD.exe). Note that this doesn't fix the issue across the board — the Tech Tree screen also uses GetKeyboardState() and checks the result in the same way. It'll also need redoing for each version until it's fixed properly by the developers.
https://bugs.winehq.org/show_bug.cgi?id=30814
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #46 from Stefan Dösinger stefan@codeweavers.com --- The way I read the MSDN page it doesn't guarantee that the other bits are 0. Either way it doesn't matter much, the game would still do something wrong.
We have few tests for this function. We have a few tests for GetKeyState and GetAsyncKeyState, but they only test the highest bit. Extending them for the 'undefined' bits could unconver some patterns. Depending on the outcome it may be possible to filter the other flags in our GetKeyboardState implementation or inside wineserver.
https://bugs.winehq.org/show_bug.cgi?id=30814
testforecho test.for.echo1996@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |test.for.echo1996@gmail.com
--- Comment #47 from testforecho test.for.echo1996@gmail.com --- Just tested and this bug happens in 2.11-staging and 2.21-staging, but pressing the arrow keys the screen stops scrolling, similar to the windows bug, thus, pretty playable.
Can confirm the bug happens in 3.2-staging and 2.22, but pressing the arrow keys doesn't stop scrolling, and the game gets unplayable after that.
https://bugs.winehq.org/show_bug.cgi?id=30814
Sylve felix74500@hotmail.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felix74500@hotmail.fr
--- Comment #48 from Sylve felix74500@hotmail.fr --- This bug is still there with Wine 1.8.7-2 32 bits. I'll try to patch my game but it seems a long way to go, as I never used Wine. I don't know if the fix has been implemented yet to the main wine branch, but it would be nice for the future users.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #49 from Sylve felix74500@hotmail.fr --- This bug is still there with Wine 1.8.7-2 32 bits. I'll try to patch my game but it seems a long way to go, as I never used git. I don't know if the fix has been implemented yet to the main wine branch, but it would be nice for the future users.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #50 from Sylve felix74500@hotmail.fr --- Can confirm the workaround works perfectly with Wine 1.8.7.
https://bugs.winehq.org/show_bug.cgi?id=30814
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=30814
Andri Möll andri@dot.ee changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andri@dot.ee
--- Comment #51 from Andri Möll andri@dot.ee --- Still seems to be an issue with WINE v3.17 and the Age of Empires Collector's Edition's installation of AoE 2.
https://bugs.winehq.org/show_bug.cgi?id=30814
Linards linards.liepins@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linards.liepins@gmail.com
--- Comment #52 from Linards linards.liepins@gmail.com --- Cannot reproduce on AoE II: HD Edition (Steam). System details:
$ cat /etc/fedora-release Fedora release 29 (Twenty Nine)
$ wine --version wine-4.0-rc6 (Staging)
$ inxi -Gxxx Graphics: Device-1: AMD Bonaire XT [Radeon HD 7790/8770 / R7 360 / R9 260/360 OEM] vendor: ASUSTeK driver: radeon v: kernel bus ID: 01:00.0 chip ID: 1002:665c Display: x11 server: Fedora Project X.org 1.20.3 driver: radeon compositor: gnome-shell v: 3.30.2 resolution: 1920x1080~60Hz OpenGL: renderer: AMD BONAIRE (DRM 2.50.0 4.20.3-200.fc29.x86_64 LLVM 7.0.0) v: 4.5 Mesa 18.2.8 compat-v: 4.4 direct render: Yes
https://bugs.winehq.org/show_bug.cgi?id=30814
felixmarty@outlook.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |felixmarty@outlook.com
--- Comment #53 from felixmarty@outlook.com --- Hum, I guess this is normal since this bug is about the original Age of Empires II version and not the HD one used through Steam.
https://bugs.winehq.org/show_bug.cgi?id=30814
felix moreno info@justdust.es changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |info@justdust.es
--- Comment #54 from felix moreno info@justdust.es --- (In reply to felixmarty from comment #53)
Hum, I guess this is normal since this bug is about the original Age of Empires II version and not the HD one used through Steam.
no, it happens on steam too build.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #55 from f_bugzilla@outlook.com --- A user on the Steam forum (Tobi, post #11) identified another workaround: https://steamcommunity.com/app/221380/discussions/2/622954302095447538/
This seems to work for me. When the scrolling gets stuck, if I go to the settings and change all 4 of the scrolling hotkeys to different keys, it fixes it and the game becomes playable again.
After doing that, if I Alt-Tab out of the game and back in again (even after restarting the game), the scrolling gets stuck again. And I need to repeat the above by changing the scrolling hotkeys to something else. So it seems like using non-arrow keys for scrolling is insufficient as a workaround - you need to reset the keys to something else each time it happens.
A more "permanent" (at least at the moment, on wine-staging 4.1) workaround is to disable the up/down/left/right hotkeys completely (as mentioned in the Steam post). So I changed all my scrolling keys to F11 (F11 is assigned by default to toggle the in-game time display). This results in three of the four scrolling hotkeys to be set to "???". Then I went back and re-assigned the in-game time hotkey to F11. So now all 4 of my scrolling hotkeys appear as "???" (i.e. unassigned/disabled), and the issue seems to be resolved.
https://bugs.winehq.org/show_bug.cgi?id=30814
Xerus 27jf@web.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |27jf@web.de
--- Comment #56 from Xerus 27jf@web.de --- This bug has been open for 7 years now and it seems to be easily fixable in the sourcecode. I absolutely do not understand why this is still not fixed.
I just started playing AoE on Linux, all seemed fine, until this bug appeared. It ruined the round, because we did not want to restart and I was the host. I also do not want to fiddle with the sourcecode myself, I work with enough code in my life ^^
PLEASE FIX THIS!
https://bugs.winehq.org/show_bug.cgi?id=30814
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=30814
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=30814
Michael Ensslin michael@ensslin.cc changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@ensslin.cc
--- Comment #57 from Michael Ensslin michael@ensslin.cc --- I can confirm that this bug continues to exist with Age of Empires II: Definitive Edition (https://appdb.winehq.org/objectManager.php?sClass=version&iId=38430).
What's the procedure for including Raditz12's patch in wine?
As far as I can tell, there's no reason _not_ to include it.
According to the Win32 API docs, only the bits 0 and 7 have a meaning. Under actual windows, only the bits 0 and 7 are ever set, the other bits are always zero. Some applications (such as Age of Empires) expect that only the bits 0 and 7 are ever set, and will behave badly if an other bit happens to be set, due to sloppy implementation. Yes, wine is currently completely compliant to the spec, but forcing bits 1 through 6 to always be zero, like they are on Windows, would have no negative effects and finally fix those badly-behaved applications.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #58 from Zebediah Figura z.figura12@gmail.com --- As Stefan mentioned, it would be nice to write some tests. And of course, someone actually has to submit it to the mailing lists; patches aren't automatically picked up from Bugzilla.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #59 from Michael Ensslin michael@ensslin.cc --- I have created a patch for Age of Empires where I patch the GetKey(board)?State() API functions to mask out all of the undocumented bits:
https://github.com/SFTtech/sftscrollbugfixer/releases
https://bugs.winehq.org/show_bug.cgi?id=30814
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |d9855df17f905da97b4bd922274 | |27c4f899babf1 Status|NEW |RESOLVED
--- Comment #60 from Matteo Bruni matteo.mystral@gmail.com --- This should be fixed by https://source.winehq.org/git/wine.git/commitdiff/d9855df17f905da97b4bd92227427c4f899babf1, which will be in Wine 5.9. Please retest.
https://bugs.winehq.org/show_bug.cgi?id=30814
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #61 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.9.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #62 from Michael Stefaniuc mstefani@winehq.org --- Removing the 5.0.x milestone from bug fixes included in 5.0.2.
https://bugs.winehq.org/show_bug.cgi?id=30814
Lucas Tanure ltanure@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ltanure@gmail.com
--- Comment #63 from Lucas Tanure ltanure@gmail.com --- I still see this issue running Age of Empires 2 Definitive Edition from Steam using Arch. By just pressing Alt + Up the maps scroll until the corner without stoping.
https://bugs.winehq.org/show_bug.cgi?id=30814
--- Comment #64 from Lucas Tanure ltanure@gmail.com --- Created attachment 71001 --> https://bugs.winehq.org/attachment.cgi?id=71001 Steam log for 8 Nov 2021 Scroll Issue Age of Empires
By just pressing alt + up the scroll never stops
https://bugs.winehq.org/show_bug.cgi?id=30814
David Gow david@davidgow.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidgow.net
--- Comment #65 from David Gow david@davidgow.net --- (In reply to Lucas Tanure from comment #63)
I still see this issue running Age of Empires 2 Definitive Edition from Steam using Arch. By just pressing Alt + Up the maps scroll until the corner without stoping.
The "regression" you're seeing is Proton Experimental specific: it shouldn't occur in upstream Wine, nor in Proton 6.3.
There's a more full description of it in the Proton bugtracker for the 2013 Age of Empires II HD version: https://github.com/ValveSoftware/Proton/issues/72#issuecomment-1007899929
Basically, the workaround for the bug (which really is a game bug), is no longer used in the fast "shared memory" path Proton Experimental has added in this commit: https://github.com/ValveSoftware/wine/commit/d2cbafab08fc0d6de0faed945130990...
Adding the "for (i = 0; i < 256; i++) state[i] &= 0x81;" to the new path should, in theory, fix it (there's a patch in the linked Proton issue, but I wasn't able to get the Proton experimental wine tree to build, so haven't tested it.)
Otherwise, there are a number of patches and tools for different Age of Empires versions to work around the issue here: https://davidgow.net/hacks/aoescroll.html
(Though note that the 'Definitive Edition' has enough code obfuscation that I haven't been able to make a patched executable, and it may have anti-cheat/anti-tamper features which could cause problems with DLL injection, so good luck!)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla