Re: [GD-Windows] Input thread

[<cas...@ya...>]

I haven't tried that myself either, but Thatcher has some code snipplets and
some notes about that:

http://www.tulrich.com/geekstuff/



Ignacio Castaño
cas...@ya...


Pierre Terdiman wrote:
> Hi,
>
> Here's an old question of mine I never really solved (since it was for
some
> home project I never find enough time to work on :
> www.codercorner.com/Oni.htm)
>
> The question is about keyboard input management, on Windows. The trouble
is
> when you rely on multiple keys beeing pressed in a sequence, to do a combo
> (like in a fighting game).
>
> Currently I use GetAsyncKeyState() and do my own little analysis to detect
> combos. It works well as long as framerate is ok, since I only query
> keyboard values on-the-fly, each frame.
>
> As soon as framerate drops, it happens that some combos are missed, and
> overall controls appear a bit laggy & not responding wery well.
>
> I read somewhere an old MSDN article from 1996 (that I can't seem to find
> again) that advocated the use of a separate thread (actually a multimedia
> timer, as in timeSetEvent) to read keyboard values at a fixed rate.
>
> It sounds like a good idea indeed, but I never bothered implementing it,
> since it also sounds a bit overkill. So before I give it a try, my 2
> questions are :
>
> - is this a standard thing to do ?
> - is this still relevant nowadays, or is there a better alternative ? (in
> particular, using multimedia timers might be an obsolete thing, superseded
> by DirectInput maybe. But I'd like to avoid D.I. since otherwise I never
> needed it in this particular project).