Input Handling |
johnpuppa
|
This forum seems dead... Also I was wondering about another thing. If I have an object which requires a texture in order to be rendered on screen, and this object needs to be created and destroyed often during the game. Is it good to have a Texture within that object each time it is created? Or it is better perhaps to load the texture in another class? What would be a better design/performance choice?
Thanks |
|||||||||||
|
MrTAToad
|
You would keep the texture loaded until the program finishes - if that requires a separate class, then so-be-it. As long as you only load it once, any way will be fine.
|
|||||||||||
|
warownia1
|
Regarding input handling, I usually have input queue processing at the beginning of the main loop which calls
In your case, I assume Main objects contains the game loop. When any event occurs, it should call dispatchEvent(event) of the Game object which handles this input further. You usually handle buttons from the event queue in the order they were pressed. If player gets stuck due to the collision with bomb he is standing on, consider making the bomb "passable" for a few seconds after being planted. Another solution is, check for collision only if player enters impassable terrain, but not when he leaves. |
|||||||||||||
|
johnpuppa
|
Thank you guys for the replies... Regarding input handling at the moment I have the player that moves using the arrows... when I press space, player drops a bomb. Everything works ok... but if I'm running(keep pressing an arrow key) and at the same time I press space the player stop. I suppose because the event handling process only the very last event on the queue and whatever was before is lost... I'm not sure.. At the moment to have it working I have to release the arrow key and press it again, which is kinda annoying.. do you have an example perhaps of how to handling multiple keystate?
Thanks |
|||||||||||
|
warownia1
|
in player class create four boolean flags indicating movement directions left, right, up, down. When SDL_KEY_DOWN event occurs change flag to 1, if SDL_KEY_UP then change to 0. Player movement direction should base on the state of the flag, not the buttons in the event queue. Hence, the character will be moving until button is released.[/code]
|
|||||||||||
|
macrofeet
|
How about somthing like
bool Keymovement[3]; //0 -1 -2- 3 up down left right bool KeyAction[3]; // 0 bomb, 1 kick etc KeyPressed=User.key.keysym.sym; // get the key pressed if/case keypressed == up keymovement[0] =true then do a keyup check keymovement[0] =false also you might want to check out this https://www.microsoft.com/appliedsciences/antighostingexplained.mspx |
|||||||||||
|
johnpuppa
|
Thanks.. I ended up with a similar solution indeed... But thank anyway for the suggestion. On keyUP event I check the current state of the keys, and accordingly fix the state of the player. Instead of booleans I used an integer.. Up 2 Down -2 Left -1 Right 1 It seems to work fine..
SDL_GetKeyboardState seems a good solution. This forum does not seem very active Too bad for a such nice library. Thanks again! |
|||||||||||
|