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.