Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » [AL 5] Keyboard Inputs

This thread is locked; no one can reply to it. rss feed Print
[AL 5] Keyboard Inputs
Kisscool
Member #12,505
January 2011

Hi,

I'm just making a litlle Tetris game using Allegro. You'll agree with me : it' easier to play with the keyboard ;D

Thats how I tried to use the keyboard with my program ( apparently, it fail ) :

Firs of all, I installed the keyboard with : al_install_keyboard()
I initilize a "state pointer" : ALLEGRO_KEYBOARD_STATE *etat = NULL;

And I control if LEFT is pressed to output a sentence :

if (al_key_down(state,ALLEGRO_KEY_LEFT)){
cout << "GAUCHE";
}

But last one throw me an error message, telling me that I violate something T_T

Thanks for your future support !

SiegeLord
Member #7,827
October 2006
avatar

Don't use ALLEGRO_KEYBOARD_STATE, use events. See this tutorial.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

X-G
Member #856
December 2000
avatar

And completely aside from whether you use _STATE or events, you didn't initialize the state to anything useful, you just left it null...

--
Since 2008-Jun-18, democracy in Sweden is dead. | 悪霊退散!悪霊退散!怨霊、物の怪、困った時は ドーマン!セーマン!ドーマン!セーマン! 直ぐに呼びましょう陰陽師レッツゴー!

kenmasters1976
Member #8,794
July 2007

When I started using Allegro 5, I used ALLEGRO_KEYBOARD_STATE like this:

ALLEGRO_KEYBOARD_STATE key_state;
...
if (al_key_down(&key_state, ALLEGRO_KEY_LEFT)){
    // Do something
}

However, once you learn to use the new event system it is quite easy so I agree with SiegeLord, you should use events.

Matthew Leverton
Supreme Loser
January 1999
avatar

You must do this:

At that point, you can use the al_key_down function. You need to update (get) the state anytime you want to see if a key has changed, so you would need to call it at least once per logic loop.

23yrold3yrold
Member #1,134
March 2001
avatar

SiegeLord said:

See this tutorial.

Ouch. I think I like Fen/Matthew's idea better. I hope that's considered the standard method; trying to cobble together a rudimentary engine off this new API just now ...

--
Software Development == Church Development
Step 1. Build it.
Step 2. Pray.

Matthew Leverton
Supreme Loser
January 1999
avatar

Events have the advantage of not losing key strokes if you don't poll enough. Also, it's simple to build key state on top of events, but not the other way around.

The key state is more useful when you want to know if some key is currently held down. The events are more useful if you just want to know when a key was pressed. (e.g., Entering a name in a high score.)

In A4 terms, the events are more like keypressed with readkey, and the state is more like the key array.

jmasterx
Member #11,410
October 2009

I noticed that using the keystate, on Windows, if I hold shift, then minimize, let go, then restore, another call to a request to the keystate will yeild that shift is still pressed which it is not. Allegro should clear these or have away to clear them so that al_key_down() is reliable,

Evert
Member #794
November 2000
avatar

jmasterx said:

I noticed that using the keystate, on Windows, if I hold shift, then minimize, let go, then restore, another call to a request to the keystate will yeild that shift is still pressed which it is not. Allegro should clear these or have away to clear them so that al_key_down() is reliable,

Do you get a key up event in that case?

Elias
Member #358
May 2000

The question is more - should there be a key up event? For most games it probably would make sense to get a key-up event for any keys which are still pressed when focus is lost and a key-down event for any keys already pressed when focus is regained. On the other hand with the way each keyboard driver does their own state tracking currently it may not be easy to implement and technically it makes sense that you never receive a key-up for a key when it happens while you don't have keyboard focus.

--
"Either help out or stop whining" - Evert

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Why can't Allegro 5 just refresh the key states when it regains focus? Allegro 4 did it. And by the way, I immensely prefer reading the key states as opposed to reading the key events. Why should I have to pass a key event to every object that listens for key presses when I could have them just check the global state instead? I mention this because I have an input library for A4 that checks the key states and produces key press/release/held/open states based on them.

Elias
Member #358
May 2000

Why should I have to pass a key event to every object that listens for key presses when I could have them just check the global state instead?

Because key state is inherently broken. For example if you press the keys left,left,right,left fast and read the key state in each game tick (marked with *):

*       *       *
left left right left

Then your game will work as if you pressed left 3 times. For some games, this would not matter much. But for some it would mean they completely break (e.g. classic-style fighter where left,left,right,left might be some special attack combo). With events you never can miss anything.

Another example is a touchpad which implements touch-to-click as a mouse press and release at the same time when you first touch the pad. With events it's no problem, but with mouse state you will never catch the click as it's simply not long enough in a pressed state to ever catch it.

And there's many more examples where state will just mean your game is broken, especially when you consider that in some situation the game may slow down because some background process uses CPU or disk access. With events nothing is lost even if the game would skip for say, half a second. With state whatever happened in that half second is completely lost... and it could mean you die in the game whenever it stutters just for a bit.

--
"Either help out or stop whining" - Evert

Evert
Member #794
November 2000
avatar

Elias said:

The question is more - should there be a key up event?

One could argue either way on that, with the argument that if you don't you will think that keys that were once pressed are never released perhaps deciding in favour of saying that you should.
But my question was actually much more down-to-earth than that. Assuming the Windows port is the same as the OS X port, we simply pass along events that we receive from the operating system. If the OS never tells us that the key is no longer held down, then we need to do something special. If it does, there is a bug in the recording of the key state (I doubt that, if it's done the same as on OS X anyway, since the keyboard state should be updated as soon as the event is received, but worth checking anyway).
For what it's worth, the behaviour on OS X (with ex_keyboard_events) seems to be that a KEY_UP event is generated the next time the same key is pressed after we regain keyboard focus, which is also weird. Haven't looked into this.

Why can't Allegro 5 just refresh the key states when it regains focus?

Who says it can't? But the way it currently works is that Allegro keeps track of key up/down events for you. The keyboard state is updated incrementally.
The problem is actually not straightforward. When should Allegro send up/down events (and update the keyboard state)? Probably when the program re-gains focus. In that case you need to compare the keyboard states before and after the switch and then generate events that will make up the differences.

Quote:

I immensely prefer reading the key states as opposed to reading the key events.

You are free to do that.
After getting used to it, I vastly prefer using the events rather than the state, mostly because with A4, I was converting that into up/down events anyway.

Quote:

I mention this because I have an input library for A4 that checks the key states and produces key press/release/held/open states based on them.

So did I and it now updates them based on the keyboard event it gets passed. It really doesn't make that much of a difference and has the aesthetic advantage of only updating stuff when it knows that there is stuff to update (or we wouldn't have received a keyboard event in the first place). The rest of the time we can idle/sleep.

jmasterx
Member #11,410
October 2009

I personally do prefer the event system, but, most API's (or atleast WinAPI) provides weather or not CTRL, ALT, and Shift are pressed at the time of a mouse event, and in WinAPI it is always accurate. This is really the only reason I use the key states. It is because when I get mouse events I want to know about those 3 keys. Given this situation however, I will have to keep track of these myself.

The only flaw however, is that using this method rather than getting the key state is that if I return (regain Window focus) and shift is still pressed, it will now be unpressed until I get a key down with mouse again. For me that is the biggest problem. There should be a way for me to atleast accurately know the states at a given time so I can do this, and for shift to be set to pressed if it is when I regain focus. I know it is not easy, but I think some kind of solution should be found before AL5 release.

Evert
Member #794
November 2000
avatar

jmasterx said:

The only flaw however, is that using this method rather than getting the key state is that if I return (regain Window focus) and shift is still pressed, it will now be unpressed until I get a key down with mouse again.

Right; that's why the update should be done when keyboard focus is returned to the application, not when keyboard focus is lost. Probably.

jmasterx
Member #11,410
October 2009

Evert said:

Right; that's why the update should be done when keyboard focus is returned to the application, not when keyboard focus is lost. Probably.

Yes I completely agree, there's no sense in doing it when it is lost, but I do hope it is fixed.

Kisscool
Member #12,505
January 2011

Ok, thanks to all of you

PS : OMAGAD IT'S WORKIN'
:dance: :dance: :dance:

( Back to a more serious face )

Go to: