• ### Popular Now

• 12
• 12
• 9
• 10
• 13

#### Archived

This topic is now archived and is closed to further replies.

# Trying to perfect input handler

This topic is 5747 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Ok, on the game now we have an issue dealing with handling player input. Currently we have all SDL keys mapped to a text equivalent, eg. MAP[SDLK_TAB] = "key:tab" etc. Then we have some of these keys mapped to an action, eg. gInputManager->Map("key:w.hold","forward") etc. Now, when an SDL key event occurs, we determine whether its a key or mouse event, and if it has an action mapped to it, push that onto an action stack. Then, anyone that wants input just calls something like: if( gInputManager->GetAction("r_left") ) rR -= 0.5f; which is:

bool InputManager::GetAction(const char *_val)
{
if( m_Actions.empty() ) return false;

if( m_Actions.front() == _val )
{
m_Actions.pop();
bActionHandled = true;
return true;
}
return false;
}

Ok, here''s the problem, if noone asks for the front action, it never gets popped off the stack, input freezes. Now, one of the deals with the game is it must be repeatable. Currently, the key events are handled once per rendering frame. This is obviously not repeatable, so, one option is to run the input handling and game state updating on a timer, say 10ms. And at the end of each update loop, we remove any unhandled events. OK, now then say if instead of just comparing the requested action with the top item of the stack, we search the whole stack and return whether the action is present then remove it. Of course this will lead to some events not being handled in the order, will this be a problem? If the game state is updating separate from the rendering loop, input will always be sampled at the same time, but the order may change from time to time.. Any thoughts on wether this is an issue or not? Is this a good solution, or is there a much better way to deal with input.. Sorry if this post doesn''t make any sense! ----------------------------- OpenMountains... an open source snowboarding game... One day...

##### Share on other sites
I though of an idea that could help you.. tell me what you think

When you read the keys, why not just take the current time as well? if you timestamp every input then you should be able to repeat that input.

Can you think of any problems with this approach?

##### Share on other sites
Do you even have to timestamp them? Seems to me you could merely number-stamp them -- assign a semirandom integer to each, sort of like "take a number and sit down".
Of course I can see benefits of timestamping, it just seems that it might bog the cpu down overmuch.

Twilight Dragon
Win32 API Expert
www.freewebz.com/j-world

##### Share on other sites
quote:
Original post by _SHO_NUFF
I though of an idea that could help you.. tell me what you think

When you read the keys, why not just take the current time as well? if you timestamp every input then you should be able to repeat that input.

Can you think of any problems with this approach?

I thought of doing this initially (I assume your saying that we can keep the game state update in the rendering loop), but the problem is even if we EXACTLY replay the input, with the game state updating at random intervals we will be reading this input at indeterminate intervals, which means that the overall game state is dependant on when it was updated. You could timestamp the inputs AND the game state update, but then u would be trying to lock the frame rate as well..

I don''t think this is a good solution, but if there is a way to get this to work it would probably be favourable to updating the game state on a timer

-----------------------------
OpenMountains... an open source snowboarding game... One day...

##### Share on other sites
Just curious, why are you using a stack and not a queue?

##### Share on other sites
Did I say stack?? oops, it is a queue

-----------------------------
OpenMountains... an open source snowboarding game... One day...

##### Share on other sites
Are you sure you''d have to lock teh framerate on replay?

I mean it would be complicated, but if everything is predictable, then your renderings could be updated at anay time. It wouldn''t be exactly the same set of pictures, but all the objects would move in the same way.