Re: [GD-Windows] Input thread
Brought to you by:
vexxed72
From: <cas...@ya...> - 2003-06-04 21:54:30
|
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). |