Thread: RE: [GD-Windows] GetAsyncKeyState / DI
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Gareth L. <GL...@cl...> - 2002-11-05 12:32:56
|
DI can give you buffered input, which has it's benefits. But DirectInput exists mainly for gamepads/joysticks/other input devices, so that you can have your game treat all input in a consistant manner. > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 05 November 2002 12:14 > To: gam...@li... > Subject: [GD-Windows] GetAsyncKeyState / DI > > > Say I have an app that just uses "simple" inputs : > - standard mouse messages > - GetAsyncKeyState() for keys > > i.e. no special devices such as force feedback joysticks, etc > (or even, no > joystick at all) > > Is there any advantages to use DirectInput instead ? What would be the > benefits in my case ? (It looks to me like it wouldn't be > better, but maybe > I'm misssing something) > > Pierre > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Pascal G. <pas...@ar...> - 2002-11-05 12:40:31
|
I have implemented both as I use the events as a fall back for the case where DI cannot be used. It's not that much difficult to add but at least you get one safety net. Are you really adverse to using it because you can pretty much reuse the code from the DI samples. I can't really say which one is better though. Pascal. -----Original Message----- From: Pierre Terdiman [mailto:p.t...@wa...] Sent: 05 November 2002 12:14 To: gam...@li... Subject: [GD-Windows] GetAsyncKeyState / DI Say I have an app that just uses "simple" inputs : - standard mouse messages - GetAsyncKeyState() for keys i.e. no special devices such as force feedback joysticks, etc (or even, no joystick at all) Is there any advantages to use DirectInput instead ? What would be the benefits in my case ? (It looks to me like it wouldn't be better, but maybe I'm misssing something) Pierre |
|
From: Andrew G. <ag...@cl...> - 2002-11-05 12:42:14
|
Depends what your app is, what you want to achieve and so on. Directinput is good for treating the keyboard like a giant joypad, but lousy for textinput. You'll probably get lower latency with regards to mouse tracking but whether that's something that's critical to you can depend. Andy @ Climax Brighton > -----Original Message----- > From: Pierre Terdiman [mailto:p.t...@wa...] > Sent: 05 November 2002 12:14 > To: gam...@li... > Subject: [GD-Windows] GetAsyncKeyState / DI > > > Say I have an app that just uses "simple" inputs : > - standard mouse messages > - GetAsyncKeyState() for keys > > i.e. no special devices such as force feedback joysticks, etc > (or even, no > joystick at all) > > Is there any advantages to use DirectInput instead ? What would be the > benefits in my case ? (It looks to me like it wouldn't be > better, but maybe > I'm misssing something) > > Pierre > > > > > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm > Tungsten T handheld. Power & Color in a compact size! > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
|
From: Grills, J. <jg...@so...> - 2002-11-05 21:27:27
|
Yup, DirectInput can give you all the key strokes, even when another app has focus. It basically treats the keyboard like a big digital button board -- you don't get any repeat messages. I believe it plugs in at the driver level, so it doesn't use a thread. It can be a bit of a trick to get rid of keystrokes you don't, especially those entered while debugging the application. j -----Original Message----- From: Pierre Terdiman [mailto:p.t...@wa...] Sent: Tuesday, November 05, 2002 3:12 PM To: gam...@li... Subject: Re: [GD-Windows] GetAsyncKeyState / DI > DI can give you buffered input, which has it's benefits. What is it, exactly ? Do you mean it records (say) pressed keys in the background, maybe in another thread, and gives all pressed keys since last query ? Actually it would be a very good reason to switch to DI. >Are you really adverse to using it .... No, I was just wondering if it was worth it. Nothing against the idea. Pierre ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: Wayne C. <wc...@re...> - 2002-11-06 17:16:40
|
> // If the function succeeds, the return value specifies whether the key > was > pressed since the last call to GetAsyncKeyState, and whether > // the key is currently up or down. If the most significant bit is set, > the > key is down, and if the least significant bit is set, the key > // was pressed after the previous call to GetAsyncKeyState. > > Isn't it just the same as what you did ? > > > if( Key[i].state&KEY_BEGIN ) > > Key[i].state ^= KEY_BEGIN; > > Or simply : > Key[i].state &= ~KEY_BEGIN; Unfortunately the remarks section inside the MSDN documentation go on to say: "Although the least significant bit of the return value indicates whether the key has been pressed since the last query, due to the pre-emptive multitasking nature of Windows, another application can call GetAsyncKeyState and receive the "recently pressed" bit instead of your application. The behavior of the least significant bit of the return value is retained strictly for compatibility with 16-bit Windows applications (which are non-preemptive) and should not be relied upon." So you can't really rely upon this bit being set correctly. Wayne -Virus scanned and cleared ok |
|
From: Pierre T. <p.t...@wa...> - 2002-11-06 17:39:13
|
> "Although the least significant bit of the return value indicates whether > the key has been pressed since the last query, due to the pre-emptive > multitasking nature of Windows, another application can call > GetAsyncKeyState and receive the "recently pressed" bit instead of your > application. The behavior of the least significant bit of the return value > is retained strictly for compatibility with 16-bit Windows applications > (which are non-preemptive) and should not be relied upon." > > So you can't really rely upon this bit being set correctly. Ooooh that's nasty ! Maybe it's time for me to update my MSDN since that paragraph is *not* included in mine. ...and actually that might explains a lot of weird things I've seen recently..... Sigh. Many thanks, very useful piece of info....................... Pierre |
|
From: <cas...@ya...> - 2002-11-06 18:10:17
|
Wayne Coles wrote: > Unfortunately the remarks section inside the MSDN documentation go on to > say: > > "Although the least significant bit of the return value indicates whether > the key has been pressed since the last query, due to the pre-emptive > multitasking nature of Windows, another application can call > GetAsyncKeyState and receive the "recently pressed" bit instead of your > application. The behavior of the least significant bit of the return value > is retained strictly for compatibility with 16-bit Windows applications > (which are non-preemptive) and should not be relied upon." > > So you can't really rely upon this bit being set correctly. Exactly, that's what I meant, the interface of GetAsyncKeyState is nice, but the real behaviour is not. Ignacio Castaño cas...@ya... _______________________________________________________________ Yahoo! Messenger Nueva versión: Webcam, voz, y mucho más ¡Gratis! Descárgalo ya desde http://messenger.yahoo.es |
|
From: Andy G. <an...@mi...> - 2002-11-06 21:26:09
|
Why use GetAsyncKeyState or DirectInput for typical keyboard handling at = all? You are going to get WM_KEYUP and WM_KEYDOWN messages all the time - = it's pretty easy to store these results in an array - then you can have = perfect up/down/pressed notifications that do not have any input focus = issues. Andy. -----Original Message----- From: Ignacio Casta=F1o [mailto:cas...@ya...]=20 Sent: Wednesday, November 06, 2002 10:10 AM To: gam...@li... Subject: RE: [GD-Windows] GetAsyncKeyState / DI Wayne Coles wrote:=20 > Unfortunately the remarks section inside the MSDN documentation go on=20 > to > say: >=20 > "Although the least significant bit of the return value indicates=20 > whether the key has been pressed since the last query, due to the=20 > pre-emptive multitasking nature of Windows, another application can=20 > call GetAsyncKeyState and receive the "recently pressed" bit instead=20 > of your application. The behavior of the least significant bit of the=20 > return value is retained strictly for compatibility with 16-bit=20 > Windows applications (which are non-preemptive) and should not be=20 > relied upon." >=20 > So you can't really rely upon this bit being set correctly. Exactly, that's what I meant, the interface of GetAsyncKeyState is nice, = but the real behaviour is not. Ignacio Casta=F1o cas...@ya... _______________________________________________________________ Yahoo! Messenger Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis!=20 Desc=E1rgalo ya desde http://messenger.yahoo.es ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm=20 Tungsten T handheld. Power & Color in a compact size! = http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Gamedevlists-windows mailing list = Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 |
|
From: Tom F. <to...@mu...> - 2002-11-07 11:12:46
|
Unfortunately they don't capture some of the stranger keys in terribly useful ways. Tom Forsyth - Muckyfoot bloke and Microsoft MVP. This email is the product of your deranged imagination, and does not in any way imply existence of the author. > -----Original Message----- > From: Andy Glaister [mailto:an...@mi...] > Sent: 06 November 2002 21:26 > To: Ignacio Casta=F1o; gam...@li... > Subject: RE: [GD-Windows] GetAsyncKeyState / DI >=20 >=20 > Why use GetAsyncKeyState or DirectInput for typical keyboard=20 > handling at all? >=20 > You are going to get WM_KEYUP and WM_KEYDOWN messages all the=20 > time - it's pretty easy to store these results in an array -=20 > then you can have perfect up/down/pressed notifications that=20 > do not have any input focus issues. >=20 > Andy. >=20 > -----Original Message----- > From: Ignacio Casta=F1o [mailto:cas...@ya...]=20 > Sent: Wednesday, November 06, 2002 10:10 AM > To: gam...@li... > Subject: RE: [GD-Windows] GetAsyncKeyState / DI >=20 >=20 > Wayne Coles wrote:=20 > > Unfortunately the remarks section inside the MSDN=20 > documentation go on=20 > > to > > say: > >=20 > > "Although the least significant bit of the return value indicates=20 > > whether the key has been pressed since the last query, due to the=20 > > pre-emptive multitasking nature of Windows, another application can = > > call GetAsyncKeyState and receive the "recently pressed"=20 > bit instead=20 > > of your application. The behavior of the least significant=20 > bit of the=20 > > return value is retained strictly for compatibility with 16-bit=20 > > Windows applications (which are non-preemptive) and should not be=20 > > relied upon." > >=20 > > So you can't really rely upon this bit being set correctly. >=20 > Exactly, that's what I meant, the interface of=20 > GetAsyncKeyState is nice, but the real behaviour is not. >=20 >=20 > Ignacio Casta=F1o > cas...@ya... >=20 >=20 > _______________________________________________________________ > Yahoo! Messenger > Nueva versi=F3n: Webcam, voz, y mucho m=E1s =A1Gratis!=20 > Desc=E1rgalo ya desde http://messenger.yahoo.es >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by: See the NEW Palm=20 > Tungsten T handheld. Power & Color in a compact size!=20 http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Gamedevlists-windows mailing list = Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D555 ------------------------------------------------------- This sf.net email is sponsored by: See the NEW Palm=20 Tungsten T handheld. Power & Color in a compact size! http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5 |
|
From: Pierre T. <p.t...@wa...> - 2002-11-05 21:13:58
|
> DI can give you buffered input, which has it's benefits. What is it, exactly ? Do you mean it records (say) pressed keys in the background, maybe in another thread, and gives all pressed keys since last query ? Actually it would be a very good reason to switch to DI. >Are you really adverse to using it .... No, I was just wondering if it was worth it. Nothing against the idea. Pierre |
|
From: <cas...@ya...> - 2002-11-05 22:31:04
|
The thing I don't like about GetAsyncKeyState is that you can loose keys
pressed between frames. It also doesn't give you information about when a
key has been pressed or released. However, testing keys by polling is
usually cleaner and easier than sending and processing events.
Instead of that I use a different polling mechanism. I associate three
different flags to each key:
enum {
KEY_OFF = 0x00,
KEY_ON = 0x01,
KEY_BEGIN = 0x02,
KEY_END = 0x04
};
And test them like this:
if( GetKey( KEY_SPACE ) ) fire();
if( GetKey( KEY_CONSOLE )&KEY_BEGIN ) console.toggle();
if( GetKey( KEY_ESCAPE )&KEY_END ) exit();
When a key down is received I set the key state to KEY_BEGIN|KEY_ON, and
when key up, I toggle the the KEY_END flag.
On every frame I update the key states like this:
for each key {
if( Key[i].state&KEY_BEGIN )
Key[i].state ^= KEY_BEGIN;
if( Key[i].state&KEY_END )
Key[i].state = KEY_OFF;
}
So, it's possible to recieve up and down messages in the same frame without
loosing the key pulsation.
You can put that on top of any input mechanism, WM_KEY events, direct input
buffers, SDL keyboard events, etc. Whatever you feel more confortable with.
Actually all that is mixed with my action mapping code, so instead of
testing for keys I test for actions, and that makes the whole thing much
more intuitive.
Ignacio Castaño
cas...@ya...
Pierre Terdiman wrote:
> > DI can give you buffered input, which has it's benefits.
>
> What is it, exactly ? Do you mean it records (say) pressed keys in the
> background, maybe in another thread, and gives all pressed keys since last
> query ? Actually it would be a very good reason to switch to DI.
>
> >Are you really adverse to using it ....
>
> No, I was just wondering if it was worth it. Nothing against the idea.
>
> Pierre
_______________________________________________________________
Copa del Mundo de la FIFA 2002
El único lugar de Internet con vídeos de los 64 partidos.
¡Apúntante ya! en http://fifaworldcup.yahoo.com/fc/es/
|
|
From: Pierre T. <p.t...@wa...> - 2002-11-06 17:10:31
|
> The thing I don't like about GetAsyncKeyState is that you can loose keys > pressed between frames. Right, that's my main problem with it. > It also doesn't give you information about when a > key has been pressed or released. Here, I'm not sure you're right : // If the function succeeds, the return value specifies whether the key was pressed since the last call to GetAsyncKeyState, and whether // the key is currently up or down. If the most significant bit is set, the key is down, and if the least significant bit is set, the key // was pressed after the previous call to GetAsyncKeyState. Isn't it just the same as what you did ? key is down => KEY_ON key is up => KEY_OFF key was pressed after the previous call => KEY_BEGIN ...maybe KEY_END is missing, unless the LSB is correctly set in the KEY_OFF case as well... > if( Key[i].state&KEY_BEGIN ) > Key[i].state ^= KEY_BEGIN; Or simply : Key[i].state &= ~KEY_BEGIN; P. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X