DirectInput vs WndProc input

DirectInput hooks your window procedure, so it's (in that sense) worse than Win32. For most input I'd just use Win32 messages directly, unless you need joysticks or something. You might also consider RawInput, depending on what you need.

Evil Steve doesn't like Direct Input.
Microsoft doesn't like Direct Input (unless for a joystick).

I c.
in that case ill learn RawInput.
Thanx fr the link

Quote:

Original post by Firecore in that case ill learn RawInput.

Only if you need to. I.e. for high-DPI mouse input. I wouldn't go using it for keyboard input of GUI-style mouse input.

Quote:

Original post by Evil Steve Quote: Original post by Firecore in that case ill learn RawInput. Only if you need to. I.e. for high-DPI mouse input. I wouldn't go using it for keyboard input of GUI-style mouse input.

Well the only reason I want DInput is for my game. I dont really need it for GUI input. I mean, I'll want my game to have fast input and output.

Quote:

Original post by Firecore Quote: Original post by Evil Steve Quote: Original post by Firecore in that case ill learn RawInput. Only if you need to. I.e. for high-DPI mouse input. I wouldn't go using it for keyboard input of GUI-style mouse input. Well the only reason I want DInput is for my game. I dont really need it for GUI input. I mean, I'll want my game to have fast input and output.

To be honest, if you're only doing it to reduce latency, I wouldn't bother with DirectInput. It's no faster than Window messages for what you're doing; your input system will only be ticked once per frame, so any lag will be the same really.

You should only be using DirectInput if you need high-DPI mouse input, and you've already determined that window messages / Win32 functions aren't precise enough (Since they give results in pixels at the highest resolution).

Sorry for ressurecting this old post, but i thought this would be a good post to add my question to.

I was just curious whether GetAsyncKeyState a viable alternative to WM_INPUT?

DirecInput was better for game controls because of its lower latency (at least marketing said so) and because of buffered input (you can detect when the player pressed the fire button even if the press was shorter than a single frame).

DirectInput also allowed you to really capture mouse deltas (instead of the ugly but common technique of resetting the mouse to the center of the screen each frame and then measure how far it has wandered off in order to get deltas) and to use the windows and menu keys for game controls.

DirectInput utterly failed for text input. Conversion of keys to ascii characters is not too hard, but implementing french accents or even IME input for east-asian languages is only really possible using the WM_CHAR messages.

I wrote all of this in past tense because right now, Microsoft is replacing DirectInput with XINPUT. It's inferior to DirectInput, but it works identically on gaming consoles. I'm very unhappy with this step Microsoft took, but it seems like DirectInput is in maintenance mode and no longer recommended technology.

-Markus-

Quote:

Original post by Firecore Sorry for ressurecting this old post, but i thought this would be a good post to add my question to. I was just curious whether GetAsyncKeyState a viable alternative to WM_INPUT?

GetAsyncKeyState works if you just need to know what key was pressed, like moving the character when the arrow key is pressed. But for anything where the user has to say, type their name into a box, you'll want to use WM_CHAR instead so that you get full multi-language support and expected keyboard behavior.

DInput wasn't totally replaced by XInput, only the joystick/gamepad portion was. And even with that, you still need to use DInput if you're supporting anything other than the Xbox 360 controller. The mouse and keyboard functionality was simply moved into the main Windows API as Raw Input.

I see. thanks guys. uve been a big help :)