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.

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,

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,

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.

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.

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.

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.

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.

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.