Jump to content
  • Advertisement
Sign in to follow this  
stealthgate

My app processes keyboard input TOO fast...

This topic is 4446 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

My goal is to be able to press a key and have a little sprite appear on the screen. I've been able to get there just fine, however, when I press the key, even for just a second, I can tell the sprite appearing and disappearing (as it should) very very very fast. I'm chocking this up to using immediate data retreival, I'm not sure though. What's another method of getting keyboard input and processing it more slowly without disrupting the framerate (as in, Sleep(), which worked the wrong way :p)? Thanks alot guys.

Share this post


Link to post
Share on other sites
Advertisement
What effect are you trying to achieve? If I understand correctly, you simply want the sprite to stay longer on the screen. In that case, just start a timer when the key is pressed and keep the sprite on screen until the timer expires.

Share this post


Link to post
Share on other sites
Well, basically what happens is that I'm using GetDeviceState() to see what's going on with the keyboard. When a certain key is pressed the sprite appears. When that same key is pressed again, the sprite goes away. However, when I press the key the sprite appears and reappears several times before I lift my finger from the key, rather than me pressing the key, the sprite appearing and staying until I lift my finger and press it again...

Share this post


Link to post
Share on other sites
Ah, okay. I understand better now.

First of all, you might want to use windows messages instead of DirectInput. Then just use the WM_KEYDOWN/KEYUP messages.

Otherwise implement your own key down/up functionality. That is, only register another key down after the key was up.

Share this post


Link to post
Share on other sites
Create a buffer for previous variables when you call your input update function.
Then, create keyboard-checking functions with these, well, functions:
Key Press: !prev && current
Key Hold: prev && current
Key Release: prev && !current
And remember to include a function that only checks the current key (and maybe even the previous).

Share this post


Link to post
Share on other sites
I'm not sure what your using. I'm sorta new to DirectX9, but here is a few tips;
-DirectX 9 uses DirectInput 8, takes a itty bit to get it to work. (There are two different ways that I'm aware of; defining directx8, or the coinitialize way.)

-There is 2 modes for 3 different areas;
foreground: You require focus to the directx app in order to get input.
background: You can get input even when the application is not selected.

exclusive: other handlers cannot take control of the device. (?)
non-exclusive: other handlers can take control of the device.

immeadiate: Events are not logged, creates screenshots of the pressed keys/mouse. Can lose states if not updated fast enough.
buffered mode: Events are logged, ie; key is pressed, key is released, etc. Can overflow if too many keys are pressed between your key update.

-Both versions seem to be updated 12 times a second.. which means you should run the update immeadiate/buffered every ~8.333 milliseconds.

For foreground, non-exclusive
-When you lose control of a device. (Which can happen when someone escapes - you can write reacquire code in the update event. - Additionally you'll want to clear the buffer/key program when you lose access.)

For immeadiate/buffered
-Logging events like a key being pressed can be instantaneous, but.. a release is somewhat more complicated. You can write a boolean that logs a release event, and when that a check is done against that release event, it resets the boolean to false. This is somewhat better than both modes.

Another effect is when you want to act on a change... if you move an object to the right every frame, and your code runs at 100 frames/second.. it will move very very fast. In this case, you can try to query it slower, but most likely.. the idea of caching results, and then querying against it at a time-based "tick" is more effective.

In my version of a DirectX/C++ engine I wrote a scheduler class that uses a global clock, and queues multiple events by id. Basically like at a theatre they have actors looking at a central clock to know when to get on stage.

Similarly.. in my Scheduler class, I write a dynamic array that sets three variables with every event. The delay of a event.. say.. every 10 milliseconds I update the movement of game objects. Then a repeat variable, which for game updates would happen repeatedly. Then finally.. a decrement value.. that is used to safely reach the end of a clock. (it decrements to 0 to determine when a event is "expired")

I hope this gives you some ideas.

Share this post


Link to post
Share on other sites
To determine key press/release events you should be using buffered mode rather than immediate polling. When you call GetDeviceState it will ALWAYS return a "key down" state as long as the key is actively being held down. With buffered input mode you get a discrete "key was pressed" message and another "key was released" message. There are some pretty simple tutorials in the DirectX SDK docs for using buffered mode.

Share this post


Link to post
Share on other sites
thanks guys...i definitely see the advantages of using buffered input. i'm currently working on being able to press the same button to display and vanish a sprite (like I was saying before).

My idea is that I see if the key '`' was pressed: if it was then I check to see if it was released (data[0].dwOfs != 0), if it is, then the sprite is displayed. however, my trouble is using '`' again, after it is displayed, to make it vanish. Any further suggestions?

Share this post


Link to post
Share on other sites
If you mean toggling the sprite's visibility when you press that button...
if key pressed '`' //NOT Held down
visible = !visible //Toggle it

Hope that helps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!