Old Keyboard State in Input Handler

iceman76 · 2014-07-06T19:29:06

I've been working on an input handler, using SDL2 and C++. Right now I'm testing it with a Pong clone, but I want to be able to use it my next games. Right now it detects if a key is currently down or not, but I start running into issues when I try to see if a key was pressed or released that frame. I'm using two arrays, one for the current state and another for the state the previous frame. Every update, I use memcpy to copy the new state to the old state, and then use SDL_PumpEvents to update the current array. The issue is that this actually isn't keeping an array of the old keyboard state. Instead, the old and new arrays are always the same, so the keys are never able to be tagged as "pressed" or "released". (I did some debugging and can confirm that keyboardOld is changing) I'm sure this is an issue with memcpy and constant pointers and all of that fun stuff, I just don't have enough experience with them to figure out what's going wrong. So, why are keyboardOld and keyboardNew always the same, even though I copy New to Old before updating New, and how can I fix it? Thanks in advance! Here's the code: Input.h #ifndef Input_h #define Input_h #include <SDL.h> #include <cstring> #include <stdio.h> class Input{ public: enum keys{ A = SDL_SCANCODE_A, B = SDL_SCANCODE_B, C = SDL_SCANCODE_C, D = SDL_SCANCODE_D, E = SDL_SCANCODE_E, F = SDL_SCANCODE_F, G = SDL_SCANCODE_G, H = SDL_SCANCODE_H, I = SDL_SCANCODE_I, J = SDL_SCANCODE_J, K = SDL_SCANCODE_K, L = SDL_SCANCODE_L, M = SDL_SCANCODE_M, N = SDL_SCANCODE_N, O = SDL_SCANCODE_O, P = SDL_SCANCODE_P, Q = SDL_SCANCODE_Q, R = SDL_SCANCODE_R, S = SDL_SCANCODE_S, T = SDL_SCANCODE_T, U = SDL_SCANCODE_U, V = SDL_SCANCODE_V, W = SDL_SCANCODE_W, X = SDL_SCANCODE_X, Y = SDL_SCANCODE_Y, Z = SDL_SCANCODE_Z, UP = SDL_SCANCODE_UP, DOWN = SDL_SCANCODE_DOWN, LEFT = SDL_SCANCODE_LEFT, RIGHT = SDL_SCANCODE_RIGHT, }; void init(); void update(); void close(); //True if a key is pressed bool keyDown(int key); //True if the key was pressed this frame bool keyPressed(int key); //True if the key was released this frame bool keyReleased(int key); private: //Length of keyboard arrays (given by SDL_getKeyboardState) int length; //State of keyboard last frame Uint8* keyboardOld; //State of keyboard this frame const Uint8* keyboardNew; }; #endif Input.cpp #include "Input.h" void Input::init(){ keyboardNew = SDL_GetKeyboardState(&length); keyboardOld = new Uint8[length]; } void Input::update(){ std::memcpy(keyboardOld, keyboardNew, length); SDL_PumpEvents(); } void Input::close(){ delete keyboardOld; keyboardOld = nullptr; } //Returns true if the key is currently pressed bool Input::keyDown(int key){ return keyboardNew[key]; } //Returns true if the key was pressed this frame bool Input::keyPressed(int key){ return (keyboardNew[key] && !keyboardOld[key]); } //Returns true if the key was released this frame bool Input::keyReleased(int key){ return (!keyboardNew[key] && keyboardOld[key]); } And the relevant code from the main program: //Handle player input input.update(); if(input.keyPressed(input.UP)){ player->y -=50; } if(input.keyReleased(input.UP)){ player->y -=50; } if(input.keyDown(input.DOWN)){ player->y +=1; } if(input.keyDown(input.LEFT)){ player->x -=1; } if(input.keyDown(input.RIGHT)){ player->x +=1; }

SmkViper

5,396

July 05, 2014 02:34 PM

There's one strange thing so far: if I hold both the g and b keys and then press h, the h isn't registered. I have no idea why that is at this point.

This is a common problem with non-mechanical and/or cheap keyboards. Due to the way they're constructed, they can only register a certain number of key presses at once, and pressing certain keys prevents other keys from being registered. The only solution (short of getting a better keyboard) is to allow users to change their keyboard bindings to avoid these issues.

yellowsputnik

1,526

July 05, 2014 04:31 PM

There's one strange thing so far: if I hold both the g and b keys and then press h, the h isn't registered. I have no idea why that is at this point.

This is a common problem with non-mechanical and/or cheap keyboards. Due to the way they're constructed, they can only register a certain number of key presses at once, and pressing certain keys prevents other keys from being registered. The only solution (short of getting a better keyboard) is to allow users to change their keyboard bindings to avoid these issues.

Yes, I thought it might be something like that. It seems strange that it happens for two very specific combinations (of the ones I've tried), but I guess that may be due to the way the keyboard is wired.

Lactose

11,696

July 05, 2014 04:42 PM

but I guess that may be due to the way the keyboard is wired.

You can test your keyboard for ghosting issues (and read more about the issue) here:

http://www.microsoft.com/appliedsciences/antighostingexplained.mspx

Hello to all my stalkers.

iceman76

Author

170

July 05, 2014 09:07 PM

Haegarr, you're right- the problem was that I was accidentally calling SDL_PumpEvents. Right before I check for the input in main program, there's this little snippet to exit when the user presses X:


//Handle events on the queue
while( SDL_PollEvent( &e ) != 0 ){
	//User requests quit
	if( e.type == SDL_QUIT ){
		quit = true;
	}
}

I read online several times that SDL_PollEvent calls SDL_PumpEvents internally, but it completely slipped my mind! Serves me right for purposefully ignoring this from the FAQ:

When posting code (which you should do if the problem is at all code-related), post it verbatim without transcribing or omitted code you believe is relevant as you can easily hide the problem that way.

Anyways, commenting out the above lines worked, so I can detect keyPressed and keyReleased to my heart's content! Of course, that means that you can't quit my program without resorting to the Windows Task Manager, but that's a feature, right? =P I've also changed the delete to delete[]

Thanks to everybody for helping me figure this out!

Buckeye

10,754

July 06, 2014 03:49 PM

you can't quit my program without resorting to the Windows Task Manager, but that's a feature, right? =P

One man's feature is another man's bug. That, IMHO, is a bad "feature." Maybe just me, but I would remove your app (or not download it to be begin with) the moment I discovered that was the only method to terminate it.

Also just my humble opinion, but if an app (particularly a game) isn't dedicated to user convenience as it's first priority, it's not ready for distribution.

Please don't PM me with questions. Post them in the forums for everyone's benefit, and I can embarrass myself publicly.

You don't forget how to play when you grow old; you grow old when you forget how to play.

haegarr

7,408

July 06, 2014 03:58 PM

One man's feature is another man's bug. That, IMHO, is a bad "feature." Maybe just me, but I would remove your app (or not download it to be begin with) the moment I discovered that was the only method to terminate it.

Not only that, but letting the "feature" inside is just a time bomb. After a while the developer things of new features based on input … and suddenly keyboard input is again no longer running. Such things should be wiped out at the roots.

iceman76

Author

170

July 06, 2014 07:29 PM

Oh, don't worry, I am most certainly going to fix that. I was just joking about the same thing Buckeye said, actually- calling it a feature when it is so obviously a bug. Sorry that I wasn't clear. Also, this isn't something I'm planning on distributing, this is just me learning how to use SDL2 in the first place.

Old Keyboard State in Input Handler

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Old Keyboard State in Input Handler

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines