I made this sample program that demonstrates that Allegro has some serious input delay, I tested it on Windows (no other OS nearby now, sorry )

You can play "normally" and you will notice that the controls are not tight as they should (for a action game at least), but you can REALLY see the effect if you just press arrow keys in random directions as fast as you can (like if you was making a fighting game input), and then just watch the screen, the longer you made your "combo", the longer the ship will move on its own.

EDIT: Fixed a bug in the example code that Elias noticed.

You should put brackets around the value of UPDATE_TIME, just in case it ever trips you up.

As for the delay problem, what happens if you attach the keyboard event source to that event queue? (Obviously your existing code would ignore the new events you get, but I wonder if it will cause some voodoo changes inside Allegro.)

I THINK that with your code you're only checking for input change every time your timer fires up an event, so you're processing only the last event in the Keyboard state when this happens and not the Keyboard events themselves.

So basically, what Bruce said....changing your code accordingly.

pkrcel that was my intention all along.

But what I got to see instead is a accumulation of keyboard input, that keeps acting on the game even after you let them go.

Source delving by me and others suggest that is because of misuse of WinAPI, for example every time a key is pressed it calls GetKeyboardState, plus GetKeyState three times. And in WinAPI itself it alread warns that those functions have delays.

I have reproduced this delay on my system, and it stems from some odd design choices in the D3D backend as well as keyboard handling. I have created a proof-of-concept set of changes to both to try to eliminate this lag as much as possible. It requires a lot more testing before I feel comfortable committing it to Allegro proper.

That said, attached is a version of the program in the OP with the changed Allegro alongside it, as well as the patch to Allegro (relative to 5.1) just so you can see what I did. I'm not sure it can get much better than that, but even going as far as I did has basically eliminated the lag for me. See if it does so on your system as well.

EDIT:

I should note, when you run speeder.exe you can pass in any argument to cause it to launch in fullscreen, if you want. Also, the allegro5.cfg alongside it can be used to force it into OpenGL mode.

EDIT2:

The diff wasn't quite right. Fixed it.

SiegeLord whatever you did, it worked here. I think I don't see any delay on this test exe

Yeah, now that I took more time to look at it, I understand the underlying desing...I misunderstood your description of the problem.

I like the patch, also the UNICODE part. I think this also will fix http://sourceforge.net/p/alleg/bugs/376/ - for example al_set_window_title will work under Windows when the string contains non-ASCII letters.

Ok, so fixing the keyboard is turning out to be very difficult. The issue is that Allegro emits ALLEGRO_EVENT_CHAR for both printable characters and for other keys. The "proper" and fast way of handling input on Windows uses WM_CHAR to do the unicode characters... unfortunately Windows only sends WM_CHAR for printable characters, e.g. it won't send them for arrow keys and other such non-character keys. It is turning out to be very hard to not send superfluous ALLEGRO_EVENT_CHAR events. E.g. if you use the US-international keyboard you can press Shift+6 followed by an e to get an ê. Using WM_CHAR and my best attempt you will get an extra ALLEGRO_EVENT_CHAR when you do the Shift+6.

Anyway, the keyboard wasn't really the major component of this delay, rather it was the display loss checking code. Attached is the patch and binaries of the code that only fixes that (and enables unicode along the way). Please check it to see if it has appreciable input lag (maybe compare it with the binary in my earlier post).

Does ALLEGRO_EVENT_CHAR work correctly for shift+6+e right now?

Yes. The only issue with the current approach is that it is supposedly laggy (I think I can perceive it, but it's hard to tell) and I also noted that it doesn't work with IME... i.e. if you try to enter Chinese characters using IME, the little IME window won't show up (I haven't determined what part of my work handles the IME window... if it's just TranslateMessage, then I could put it in without actually handling WM_CHAR's).

Great work SiegeLord

The lag is not random anymore (random lag is TERRIBLE) and is now 1 frame.

Not zero yet... but good enough for most games and players I guess.

Out of curiosity, how are you measuring the lag?

Just perceptually. I guess I could look at the original timestamp of the MSG structure and compare it to when we emit the Allegro event.

EDIT: I tried it with this code: printf("Lag %ld\n", GetTickCount() - GetMessageTime()); at the spot where the keyboard events are emitted, and it showed a reduction from as much as 400 ms to 0 ms with an occasional 16 ms.

EDIT2: Committed the above patch.