[Windows AMD64]Space key suddenly stops to work

[HiroKoni]

Problem

In King's Cross, the game sometimes suddenly stops responding to the space key; pressing Escape does not fix this.　After restarting the game, it becomes active again.
The detailed trigger is not clear, but from my few attempts, it seems to be triggered by pressing Shift/Ctrl just before descending from the step.

Version

aaaaxy-windows-amd64-v1.5.23

System

Windows 10 Home 22H2 (19045.4046)

Screen Record

[divVerent]

I am going to see if I can reproduce it.

If the game is stuck like this, does the X key still jump successfully (this is from the alternate key mapping using X and Z keys that reminds of a bunch of NES/Famicom emulators)?

[divVerent]

Another thing worth trying: if the game is stuck like this, does Alt-Tab out and back into the game fix it?

[HiroKoni]

While testing the X key, I think I figured out the cause.
This issue would only be relevant to the CJK language area, and I don't know if this can be solved on the game side.

In my environment, Microsoft IME is installed for Japanese input. When this is in "full-width mode", the game does not seem to recognize key input, except for functional keys like arrows.
I assume that the reason this problem was so frequent in this part of the game was simply because I tended to accidentally press the shortcut (Shift + "無変換") for switching the function.

In summary, neither X nor Alt+Tab solved the problem, but changing the IME settings did.

[divVerent]

Oh... I was just trying to reproduce it on my German Windows 10 install on the "all the OSes" laptop, but couldn't reproduce it. But then I indeed thought of IMEs too - as Ctrl-Space is a common key combination to toggle layouts.

I wonder if it'd help to call this:

https://learn.microsoft.com/en-us/windows/win32/api/imm/nf-imm-immdisableime

Given the game has no text input fields, this might actually be the right solution.

[HiroKoni]

Cool, sounds like that is the solution.

[divVerent]

Hm... I can't seem to coerce Ebitengine to let me do that, as ImmDisableIME can only be safely called before ever receiving a WM_CREATE message, and Ebitengine already creates a window in its global init() handlers.

Not giving up yet, as there may be a workaround, but right now I have not yet found a way to inject code to run before Ebitengine's own initialization.

[HiroKoni]

How about https://learn.microsoft.com/en-us/windows/win32/api/imm/nf-imm-immassociatecontext? I'm not familiar with Win32 API, but it appears to be able to disable IMEs as well.

[divVerent]

Hm... possibly. It isn't even well documented, so not sure if it'd even allow disabling IME or just switching to another IME context.

Another thing we can try - any chance you can run the ebitengine "keyboard" example (https://github.com/hajimehoshi/ebiten/tree/main/examples/keyboard)?

In there, try switching IME settings around with the kanji key and see what the following keys then might do:

W A S D E Z X H J K L F Space Tab Enter

I attached the executable for convenience, but if you can compile it yourself, that'd probably be even better.

keyboard-exe.zip

If we're lucky and this still shows some key identifier for the not-working keys, I can just add them to AAAAXY's controls setup and work around the issue that way.

[HiroKoni]

Now tried the example by go run github.com/hajimehoshi/ebiten/v2/examples/keyboard@latest. Nothing showed up in the full-width mode, unfortunately. Shift, Tab, Ctrl, Alt and Enter worked!

PS

I first thought none of the key worked. Here's why. When you type some letters with the full-width mode enabled on a software does not support IME, a small window appears, working something like a buffer. During that small window is displayed, it appears that all the keys are not recognized on ebiten. When not, the keys -- Shift, Tab, Ctrl, Alt and Enter -- can be recognized while keys referring to letters still cannot.

[divVerent]

So basically the IME is working as it should - it takes input focus, handles events on its own, and sends the result to the application when done.

Just that we're not in a text input field and thus the IME shouldn't be active in the first place.

[divVerent]

For reference, this is the bug tracked in Ebitengine: hajimehoshi/ebiten#2918