Hello Direct X guru's very quick question(although the explaination is lengthy) i am developing a basic user input system for a game using the keyboard i am using a structure to record what state a key is in: its similar to the one above and there is a small manager that updates the time down and resets things. the question is,when using direct input will a call to "->GetDeviceState()" and then subsequent checks to the users keys be slower than checking them all individualy using GetAsyncKeyState() now i have just seen a thread saying that there is no advantage to using DirectInput but if you absolutely have to, is it slower? the reason i ask is that i do not intend to use the keyboard for game controls but as i am only very early on i would like to use it for debugging and testing with the possibility of an easy port to joystick control, using the same methods later. any help is appreciated Thank You

Quote:Original post by Wardyahh
the question is,when using direct input will a call to "->GetDeviceState()" and then subsequent checks to the users keys be slower than checking them all individualy using GetAsyncKeyState()

Try it and see [smile]

As best I can tell you from my experience there won't be a noticeable difference. The two big problems with input performance have been not using async querying (e.g. blocking until input occurs) or aggressive polling that effectively spin-locks the app/CPU with pointless checks. The actual act of retrieving keyboard data is rarely the bottleneck.

Quote:Original post by Wardyahh
the reason i ask is that i do not intend to use the keyboard for game controls but as i am only very early on i would like to use it for debugging and testing with the possibility of an easy port to joystick control, using the same methods later.

In your case, DInput may well be a valid option. Have you looked into "action mapping?" It never got as much love as it should have, but it's still an interesting feature. Also bare in mind that going forwards, XInput is the controller-oriented API of choice so you may need to abstract your code enough to handle DInput and XInput, which begs the question of why don't you also abstract it for regular Win32 mouse/keyboard...?

hth
Jack

Thank you for the reply

i suppose abstracting it to the point of being usable by everything is a good approach(and i may well do that just for the learning experience)

i'm intentionally not adding support for mouse and keyboard because the way the gameplay will be set out(hopefully), will require the 360 rotation of analogue sticks.
While this is do-able using the mouse, it is designed around the 360 controller(or dual shock as they are pretty similar nowadays) and thus the combinations of buttons and how you need to utilise them has also been designed around the layout of the controllers.
in short, a port to keyboard/mouse control is possible...but not really useful lol

my hope is to have a nice demo, but my main aim is just learning
(plus i think it is cool how you can attatch the 360's controller to a pc)

I assume you're aware that the 360 controller is designed to be accessed via the XInput API and not the DInput API? I've not tried it, but I gather it's still visible to DI but not all features are accessible.

hth
Jack

yep

but to the best of my knowledge(which isnt much) the usage is similar so if i build an architecture around DInput when i come to add joypad support it shouldnt be as much of a leap as it would be if i were using GetAsync

although i have completely abstracted the input from the main manager anyway so even if it is completely different it only requires changes to the input section :)