I am working on my Allegro 5 game, which is coming along nicely, I am really loving the library.
I do have one "problem" which I am not sure there is a solution to, but I thought I would throw this out there and see if anyone has any ideas.
I had the same "problem" with Allegro 4. It's not a library problem really though, at least I don't think so.
What happens in my Pacman style game is that a player can be moving along, say to the right in the maze. They wish to turn up. They get so wrapped up in the game and the ghosts chasing them that they forget to let go of the right cursor key and press UP key, so they have both keys pressed at the same time. This is fairly common. To their dismay, their character keeps going right and doesn't turn up at all and they end up dying and cursing the programmer.
I have tried to change how I code this, by clearing the key_pressed[] array when a new key is pressed and the player will then turn as expected, even with a new key pressed, but then the game won't respond to the right keypress until that key is released. Now obviously they should have released it and I have advised against holding keys down as you don't need to hold a key down at all in my game, just tap the direction you wish to go then let go of the key and your character will happily travel in that direction unless told otherwise. But is there a better solution to this do you think? I haven't tested if this happens in other games yet. Just thought I would throw this out there just in case there is something I am missing.
Thanks in advance.
Example code I use (edited to keep things brief)
I'd probably have a variable that can only hold 4 states, and the last direction key would set that state. Otherwise, you might check out the keyboard.timestamp field to see which was pressed last.
I modified your code to reflect Arthur's suggestion.
If you want to make it more advanced, you would check which directions are available, and if that key is pressed you allow pacman to move that direction (so if you press left and up and he can only move up, he still moves up)
I'd probably have a variable that can only hold 4 states, and the last direction key would set that state. Otherwise, you might check out the keyboard.timestamp field to see which was pressed last.
Oooh... that looks interesting. I'm just not exactly sure how I would implement it. Make a struct for the key_pressed[] array perhaps which would include a member to store the time it was pressed perhaps...
Edit: ph03nix, I don't see how your code changes anything.
Edit2: Okay, fixed the problem! Thanks for the great idea with the timestamp! I remade my key_pressed[] array so that it used a struct which included a bool for whether or not it was pressed and a double for the timestamp.
I then check the time for each direction and set a direction variable based on which key was pressed most recently and act accordingly...
Thanks for the ideas.
Sounds like these gentlemen have you sorted out, but do keep in mind that some keyboards won't correctly report multiple keypresses on the hardware level - I've actually had one or two that report completely incorrect keys when the left and up arrows are pressed - so if anyone reports problems, make sure to rule out the keyboard they're using before you stress too much over your code.
could also just have a direction variable.. as Arthur was aluding to. With an enum for DIR_NORTH, DIR_SOUTH, etc.
Actually, the direction code won't make a lick of difference because if I am pressing UP and LEFT at the same time, and it hits the code that tests for UP and finds it is pressed, it will set the direction to UP and ignore the other tests, which is what it is doing already.
With the timestamp it sets the time the key was pressed and then can respond to the most recent keypress. I set a direction variable with the new code based on the most recent timestamp.
As for the keyboard problem, I'll keep that in mind, thanks.
You'd set the direction variable when you get the key_down event, so it has the "last key pressed" functionality built in. no need to check a key array or key state.
Bear in mind that you can have several different event loops, based on what you're doing (selecting from menus vs. playing the game, etc.).
You'd set the direction variable when you get the key_down event, so it has the "last key pressed" functionality built in. no need to check a key array or key state.
Ah, okay, I see what you mean now. The key array will hold the fact that both keys are pressed, where as the direction variable is a result of only the last key pressed.
I guess it's a result of rewriting old Allegro 4 code that brought this problem on in the first place.
I'll give that a go then. I suppose had I started programming with Allegro 5 in the first place and never even seen Allegro 4 or earlier this is probably the way I would have went now that I think about it.
Thanks.
It looked the same to me when you first mentioned it, I couldn't understand where there was a difference until now. D'OH
Bear in mind that you can have several different event loops, based on what you're doing (selecting from menus vs. playing the game, etc.).
Thanks for that. And I like your idea of adding the keypad, I think I'll add that as well, nice idea.