Pros/Cons of DirectInput
Author
Why exactly has DirectInput become so popular with programmers, especially game programmers? Right now I''m using GetAsyncKeyState() and everything''s working just fine, and the few apps I do have that use DirectInput seem so much more confusing and were a lot harder to code. Are there any unseen reasons to use DI, like better performance, or anything? To me GetAsyncKeyState seems to be ideal, so unless I''m missing something there''s no reason to use DI, except with so many people using it, there must be some reason to use it, right?
DirectInput isn''t just for keyboards, you know. How would you poll arbitrary game controllers?
A DirectInput keyboard device allows for callbacks, which are triggered when the keyboard device is actually updated. This means that you would never miss a keypress. With GetAsynKeyState(), you''re asking what keys are pressed at the time of the call. If something happened, like a skip in the frame rate, keypresses could be missed. This can also affect response times with players who are getting low frame rates in your game.
Aside from this, DirectInput devices allow for control over a device. This in turn allows you to gain intimate knowledge of such devices fairly easily (ie; every single button on a mouse, wheel movements, 100% control over mouse cursor, etc).
Aside from this, DirectInput devices allow for control over a device. This in turn allows you to gain intimate knowledge of such devices fairly easily (ie; every single button on a mouse, wheel movements, 100% control over mouse cursor, etc).
DirectInput is made for games and frees you from the dreaded win32 message pump. It supports a lot more than the basic keyboard/mouse/joystick that win32 API does.
But if your game''s input needs are pretty simple (cursor movement, on/off keystates), then Win32 should be fine.
But if your game''s input needs are pretty simple (cursor movement, on/off keystates), then Win32 should be fine.
quote:Original post by ms291052
This is true, but for now let''s stay within the realms of keyboard/mouse.
DirectInput talks directly to the hardware device driver.
GetAsyncKeyState() et al talk to the Windows layer above the device driver.
Because of that DirectInput gives you things like exclusive access/control and (slightly) lower input latency.
Furthermore, Windows mouse and keyboard settings which make sense for desktop productivity applications (key repeat rates, mouse sensitivity, mouse accleration etc) don''t always make the same sense for games.
Finally many games DO support some form of gaming input device (joypads, steering wheels etc) - with things such as action mapping, DirectInput makes using those pretty easy.
You asked why DI was so popular with games programmers - access to gaming controllers is an important thing for us to have (particularly in the commercial world, and particularly in arcade genres). So you can''t really fairly ask why people use it whilst "staying within the realms of keyboard/mouse".
As a sidenote - people do often use DirectInput for the WRONG things. For text input into a game and controlling a mouse pointer in a GUI it''s *much* better to use the standard Windows messages and NOT DirectInput (or GetAsyncKeyState for that matter).
For typing *text* and controlling pointers, you can pretty safely assume that the user has already configured preferences for those in Windows (key repeats, keyboard layouts & territories, IME, accessibility, mouse speeds etc).
--
Simon O''Connor
3D Game Programmer &
Microsoft DirectX MVP
Totally agree on DirectInput being the wrong choice for text input. I had myself a text input mechanism using DI and it worked fine for my needs (drop-down console input) by sending key Press, Repeat, and Release events, but then I started to work on a team and we now had a GUI and it was requested of me to support Unicode. Well, I didn''t get very far before I realized it was a silly thing to do with DI. Windows supports all the text input I can think of (and probably some I have never even heard of, surely) so there''s no way I would want to or need to emulate all of that. And neither would anyone else.
The only Win32 infiltration is WM_CHAR so it''s a very good deal.
The only Win32 infiltration is WM_CHAR so it''s a very good deal.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
