Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Foreign keyboard handling issues #1391

Open
dreammaster opened this issue Aug 15, 2021 · 4 comments
Open

Foreign keyboard handling issues #1391

dreammaster opened this issue Aug 15, 2021 · 4 comments

Comments

@dreammaster
Copy link

We've had two foreign keyboard related issues issues reported on the ScummVM bug tracker. I found the instructions in both kind of hard to understand, and with other priorities, I left them on the backburner for a while. But in both cases I realized they mention that the problems are also in your standalone engine as well, so I figured best to pass them onto you to review if they're legitimate bugs, or simply something that can't be fixed:
https://bugs.scummvm.org/ticket/12594
https://bugs.scummvm.org/ticket/12604

@ivan-mogilko ivan-mogilko added context: input type: bug unexpected/erroneous behavior in the existing functionality labels Aug 15, 2021
@ivan-mogilko ivan-mogilko added this to the 3.6.0 (SDL2 Port) milestone Aug 15, 2021
@ivan-mogilko ivan-mogilko added res: needs testing issue needs (re)testing to update its status and removed type: bug unexpected/erroneous behavior in the existing functionality labels Aug 15, 2021
@ivan-mogilko
Copy link
Contributor

ivan-mogilko commented Aug 15, 2021

I understand what the 12594 means, but it will be interesting to first find out if this is the engine's or game's behavior, because there's also a possibility that the game script has some kind of transliteration built in.

@ivan-mogilko
Copy link
Contributor

ivan-mogilko commented Jun 26, 2022

There's a newer comment in scummvm's 12594 from HQ author, who confirms that this is a game's behavior.

EDIT: it also matches original behavior of a game exe.

@ivan-mogilko
Copy link
Contributor

ivan-mogilko commented Jun 26, 2022

As for 12604, this is a long known issue in AGS; and I think the bug reporter explains correctly that:

For shortcuts to work as expected, raw keycodes should be used instead of keymap-translated keys

The thing is that changing anything there would likely affect any existing game which does key handling, because AGS script in the past did not make any difference between key as a raw key and key as a character. And if the game uses these keycodes for a custom text input, for example, changing their meaning would break that instead.

There have to be a way to approach this problem for the new versions of AGS, and separate way for backwards support.

  1. For the new versions we might have to update key handling in script again. Since now we have a differentiation between on_key_press and on_text_input, perhaps a solution could be to let on_key_press get "raw keycodes" without keymap translation.
  2. For the old games, maybe this could be done with some config setting, and setup for individual games; as frankly I doubt that we may predict whether game simply uses positional shortcuts, or a custom text input.

@ivan-mogilko
Copy link
Contributor

For the future reference:
https://wiki.libsdl.org/SDL_Keycode
https://wiki.libsdl.org/SDL_Scancode

The scancode identifies the location of a key press and the corresponding SDL_Keycode gives that key press meaning in the context of the current keyboard layout.

For example, on a QWERTY keyboard Keycode and Scancode will be the same, but if using an AZERTY keyboard A should have A keycode and Q scancode, Z should have Z keycode and W scancode, and so forth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants