Handling keyboard input in SDL2

Question

I'm using SDL2 with .NET bindings. Keyboard handling is encapsulated in static class, and keyboard handling code part looks like this:

// class members
private static int _numkeys;
private static IntPtr _keysBuffer;
private static byte[] _keysCurr = new byte[(int)SDL_Scancode.SDL_NUM_SCANCODES];
private static byte[] _keysPrev = new byte[(int)SDL_Scancode.SDL_NUM_SCANCODES];

// called once, to get buffer pointer
_keysBuffer = SDL_GetKeyboardState(out _numkeys);

// update keyboard state each frame
var tmp = _keysPrev;
_keysPrev = _keysCurr;
_keysCurr = tmp;
// copy new state
Marshal.Copy(_keysBuffer, _keysCurr, 0, _numkeys);

all is workig as expected mostly, however once in while one of the following behavior occurs:

1. Physical key is pressed, but no key press is detected. Keypress is detected after key repeat interval.
2. Physical key is pressed, but no key press is detected. Lasts for infinite amount of time.

For example, I press Right (D), the movement to right starts, shortly after I press Fire (SPACE), movement is stopped, no firing occurs, then after key repeat interval firing starts, but movement to Right is stopped despite key is also still pressed.

Unfortunatelly I have both 1) not discovered 100% reproducible pattern for the bug yet (seems like it happens on burst sequental presses), 2) have no ideas what is the cause.

For now I just want, a fresh view on my code (is it solid?) and maybe some ideas on what to check. Thanks!

Answer 1

This could be a hardware issue as stated by @Quentin.

Anyways, you could write a workaround tracking the KEYDOWN and KEYUP events instead of trying to fetch the keyboard state, i'm not pretty sure how it works in C#, i've never worked with SDL2 in that language, but here's an example of how do I manage it in C++, i suppose it's pretty similar.

Instead of doing that, what you would need is an array of unsigned char, writting 1 into the key code index when pressed and 0 when released.

After that you will have the state of the keyboard with no hardware state dependency

Answer 2

Surprisingly it actually turned out that Quentin was right is some sense. It was not keyboard ghosting however, but pure keyboard malfunction. It just happened that it really not reporting some keys pressed then they are. And it was incosistent as the "bug" was.

I used Keyboard Ghosting Demonstration page and Keyboard Ghosting & Rollover Test windows app for the test.

The costly piece of garbage was replaced by my old good membrane keyboard and the "bug" is gone now.