Re: [AD] Keyboard timing problem

["Julien Cugnière" <julien.cugniere@xxxxxxxxxx>]

2007/6/1, Colin Ward <lists@xxxxxxxxxx>:
> ie.  The main (user's) thread is paused waiting for vsync(), then the input
> thread sees that key "x" has been pressed, marks key[x] as being pressed
> and goes back to sleep.  The user then lets go of key "x" and the input
> thread wakes up and marks key[x] as being unpressed.  Then the main thread
> wakes up, checks key[x] which of couse is now marked unpressed, and so the
> user thread has missed the keypress.

I haven't used Allegro in quite some time, but here are my thoughts on
the matter.

The problem you describe is possible, but you have to put it into
context. If your screen is set to a refresh rate of 60 Hz (a minimum
nowadays), a vertical sync will happen roughly every 17 ms. In other
words, a call vsync() should theoretically only wait between 0 and 17
ms. Managing to press and then release a key in this short a time is
quite an accomplishment :-)

And if you look at it the other way, any keypress that lasts longer
than 16 ms should be detected for sure by the main thread. So, if it
takes your programs half a second (500 ms!) to detect a keypress, you
have a problem somewhere else.

Maybe your program doesn't poll the key[] array frequentlty enough.
This be might because your implementation of vsync is incorrect, and
waits for far too long, or it might be fine, and the program is
spending its time elsewhere. Or maybe the program and the vsync
implementation are both fine, and it's your input thread that doesn't
handle events fast enough, letting them accumulate, and applying them
by group from time to time.

All in all, polling an array of key states is not the best input
method out there, but it's definitely workable, and shouldn't produces
results as catastrophic as you describe... I think you should
investigate some more!

Hope that helps,

--
Julien Cugnière