Sign in to follow this  

Taking input into inputbox with direct input

This topic is 3563 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, Direct Input can be used in games. For example you can move camera with direct input. I write now input box in directx and i heard that you can use direct input for take the input to the inputbox. I rode the direct input tutorials and they doesnt help. I mean: when i push for example key 'k' on my keyboard and then i render it they shows many letters 'k' because of sensivity that direct input have. How must i do: when i push key 'k' they show only one letter 'k' and no many letters 'k'.

Share this post


Link to post
Share on other sites
First: using DirectInput is no longer recommended. With the speed of today's processors, it is much simpler to use an OnKeyDown() routine or WM_KEYDOWN.

Second: There are DirectInput examples in the SDK. Your best bet is to study how DirectInput is setup.

Third: there are 2 modes for DirectInput - immediate and buffered. Acquiring keyboard data differs between the two modes. Again, I suggest studying the SDK example.

Hope that helps.

Share this post


Link to post
Share on other sites
Yes. You could use DirectInput. Equally, you could use BIOS interrupts to manage keyboard input. It's an equally good idea. Faster, but far far more complicated.

You should never be using DirectInput for keyboard or mouse input.

EDIT: Actually, the problem you're having is directly related to using DirectInput. Ditch it and use Window messages or some alternative for your own sanity.

Share this post


Link to post
Share on other sites
I wouldn't advise using DirectInput for any kind of keyboard input, but for this kind of situation you absolutely don't want DI. For any kind of keyboard input that's used for edit boxes, say for entering a name, you want your game to respond just like a normal Windows Edit control would. This means you want capslock and shift to work, you want they key to auto-repeat if it's held down, and you want to allow for alternate keyboard arrangements and different language configurations. None of those things are supported in DirectInput, but they are if you simply process WM_CHAR messages.

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
I always used DirectInput or GetAysncKeyState so I didn't have to wait a second for they key to start repeating if the user kept pushing it.
If you've received a WM_KEYDOWN message and no WM_KEYUP message, then the key is pressed. There's no need to use DirectInput.

EDIT: Actually, all you're doing is warping Window messages to do what you want them to do. There's no difference between trying to get key repeat from a method that doesn't provide it, and trying to remove key repeat from a method that provides it.

Actually, the above method can have some problems if the user alt+tabs with the key held (Since you won't get the key up message). But if you get a WM_ACTIVATE message saying your window has just become focused, you should probably clear your held keys anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by kacperz1
So it must be like this?

case WM_CHAR:
{
switch(wParam)
{
default:
std::cout << wParam;
break;
}
}
break;


But the wParam contains not the name of the character but him number. what must i do?
wParam is the character code. If you want to print it out, you'll need to cast it to a character, like so:
std::cout << (char)wParam;

Share this post


Link to post
Share on other sites
[quote]Original post by kacperz1
I dont want to handle the messages into the messages procedure but in my function.
[quote]

But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.


This is why I always used DirectInput. I use states and a game manager class to control the game so I would have to forward the data from WM_CHAR a few times to get it to where the game is actually checking input.

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
Quote:
Original post by MJP
But that's exactly what the message procedure is for. If you want to handle the specific WM_CHAR message somewhere else, then have your window procedure forward the message to whatever function you want to handle it.


This is why I always used DirectInput. I use states and a game manager class to control the game so I would have to forward the data from WM_CHAR a few times to get it to where the game is actually checking input.
Then you're missing out on all the things that Windows provides, like key repeat. It's not such a big deal if you just need to know if a key is up or down, but it is if you're doing any sort of text input, you want to support any language other than English, or you want to support lower / upper case and shifted characters.

Just because DirectInput seems easier to do here, doesn't mean it's a good idea. Hell, you can write to specific memory addresses to call BIOS interrupts or similar, and that's easier - but it's really not a good idea.

Share this post


Link to post
Share on other sites
Quote:
Original post by stupid_programmer
If MS thinks DirectInput is such a bad idea why did they even develop it? Is it a holdover from older versions of DX where DI got input faster then in the WM_CHAR message?


Before Windows XP, there was no RawInput API in Win32 that gave you low-level access to input hardware. But now we do have them, and because of that all DirectInput does (in Windows >= XP) is hook your message procedure and use a separate thread to process WM_INPUT messages. This is an awful lot of overhead for something you could do yourself with less code.

DI was also more relevent when joysticks and gamepads were the primary input methods for games. These days if you worry about a gamepad at all, it's usually just the 360 gamepad.

[Edited by - MJP on March 10, 2008 10:19:20 PM]

Share this post


Link to post
Share on other sites
Quote:
Original post by MJP
Quote:
Original post by stupid_programmer
If MS thinks DirectInput is such a bad idea why did they even develop it? Is it a holdover from older versions of DX where DI got input faster then in the WM_CHAR message?


Before Windows XP, there was no RawInput API in Win32 that gave you low-level access to input hardware. But now we do have them, and because of that all DirectInput does (in Windows >= XP) is hook your message procedure and use a separate thread to process WM_INPUT messages. This is an awful lot of overheard for something you could do yourself with less code.

DI was also more relevent when joysticks and gamepads were the primary input methods for games. These days if you worry about a gamepad at all, it's usually just the 360 gamepad.


Thanks, I guess it isn't that big of a deal to pass on an array of keyboard input into my actual input handler.

Share this post


Link to post
Share on other sites

This topic is 3563 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this