Keyboard input problem for games

[tanoxyz]

Hi!
I was trying to use the CPC emulator to bundle a web version of a game I made, but I've noticed that there is a problem with the input handling. Maybe you already know about this problem and that there is no clear solution .

The problem

In

chips-test/examples/sokol/cpc.c

Line 198 in b8a46cc

case SAPP_EVENTTYPE_CHAR:

you check most keys in the keyboard from char events, as they don't specify key down/up, the key up and down event are sent in the same frame. This seems mostly fine on the default CPC's firmware but some games may need to hold the key for more than 1 frame, for example our game's jump height varies based on how long you have been pressing the key. Our game
I suppose that you did it that way in order to map any keyboard layout to the original, for example on the CPC's case the symbol " is on the Key 2 but on today's keyboards it may vary.

Solutions?

For our game, I've ignored the char events from A to Z and used the usual key down/up events to detect them, code here. But a more robust solution would be to just map the all key up/down events to the original keyboard's position. Although some keys won't match in some keyboards, it will be the "real position", in Retro Virtual Machine works that way.
We can also add a toggle to change the layout to "physically correct" or not.

Thanks for these emulators by the way!

[floooh]

Thanks for the input, I need to think about this a bit :)

In general, I was hoping that most games would be able to use the joystick emulation (when this is activated, some host keys are intepreted as joystick input instead of keyboard input, but this also has issues - namely that the arrow keys and Spacebar no longer work as regular keys).

The reason that CHAR input is used is indeed that this provides an automatic key mapping for international (host) keyboards, instead of trying to map the home computer keyboards to modern 'physical' keyboards.

Another thing I have somewhere down on the todo list is virtual onscreen keyboards and joysticks, this would mainly be useful for mobile devices, but would also help to make 'exotic keys' on some home computers accessible which are currently ignored. This would not help with your specific problem though :)

I guess the best solution is - as you mentioned - a separate input mode which would use key up/down events instead of CHAR for all keyboard input.

[karlvr]

I wonder if this is related to what I'm seeing, playing BASIC games on the CPC like Moon Base Alpha & Englebert where pressing the keys to do things (start engines, open door etc) don't always register. Sometimes I need to hold down the key for what feels like a second before the game registers. Maybe it's just BASIC being slow and not checking INKEY often enough... but it feels a bit weird and quite awkward to play which doesn't match my memory!

[floooh]

You can inspect the keyboard matrix emulation here https://floooh.github.io/tiny8bit/cpc-ui.html via the menu item "Hardware => Keyboard Matrix".

In general, the keyboard matrix emulation has a 'sticky time' config parameter. This means that even short host system key presses are lenghtened so that the emulated system has enough time to scan the keyboard matrix (which is needed for the current CHAR input since this sends a key down/up pair immediately to the emulator).

On the CPC emulation the stickiness duration is currently set to 1 60Hz frame here, which for regular keyboard input seems to be enough (I don't quite remember if the CPC scans the keyboard matrix once per 50 Hz frame, or once in each raster interrupt, e.g. each 52 scanlines):

https://github.com/floooh/chips/blob/92e79dd7a2ffe472f415816c886c1349f267aed8/systems/cpc.h#L675

One thing you could try is to increase this stickiness duration and see if it helps with your problem.

Another option might be to introduce a 'raw' keyboard mode up in cpc.c which switches to using KEY_UP/DOWN events for keyboard input instead of CHAR events (but then cannot handle international keyboards - e.g. it would mostly be useful for game input, but not regular text input). Could be handled like enabling the joystick emulation (e.g. a cmdline parameter plus a Dear ImGui menu item for the 'ui versions'.

[floooh]

PS: there's also definitely weird stuff going on in the keyboard input when pressing multiple keys simultaniously...