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!

  • 2
    \$\begingroup\$ Sounds like a typical issue from matrix keyboards. IOW, that's a hardware issue. \$\endgroup\$ – Quentin May 11 '17 at 12:00
  • \$\begingroup\$ @Quentin thanks for the tip. But I have a ghosting-free gaming keyboard, so it's unlikely the issue IMO. But i'll check it out to be sure. \$\endgroup\$ – Petr Abdulin May 11 '17 at 16:29
  • \$\begingroup\$ Is there a reason you can't use the event system instead of manually handling the key state? \$\endgroup\$ – Pharap May 11 '17 at 16:36
  • \$\begingroup\$ @Pharap thanks for the option, but I'm happy with my implementation, would not change it unless there is unfixable bug :) \$\endgroup\$ – Petr Abdulin May 11 '17 at 17:04
  • 1
    \$\begingroup\$ @PetrAbdulin glad to help! but I doubt "your keyboard is busted, get a new one" is a useful answer for future devs ;) \$\endgroup\$ – Quentin May 12 '17 at 8:16

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

| improve this answer | |
  • \$\begingroup\$ Thanks for the answer. But that's exactly how SDL's keyboard state works internally! It simplifies keyboard handling by great amount. It's much more likely for me to implement it poorly than SDL. So I see no reason to try fixing that is not broken (unless you can say what is wroing with my code now). \$\endgroup\$ – Petr Abdulin May 11 '17 at 16:38

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.