Sign in to follow this  
Jonathan Gunz

DirectInput and process priority

Recommended Posts

Although this isn't exactly game related, I was hoping to find some help here. I'm working on a response timing application that uses DirectInput and Direct3d to present stimulus. When I set the process priority to realtime, my "game loop" is getting executed correctly but DirectInput fails to register keyboard presses. I am not using buffered and was under the impression that calling GetDeviceState would return the state of the device at that instant. Any explanations or ideas?

Share this post


Link to post
Share on other sites
Why do you use realtime priority? That's sure to mess with anything you do.
What's happening is most likely that essential Windows processes are getting no CPU time, so they aren't registering key presses, and so, they can't send them to you when you call GetDeviceState.

By using realtime priority, you're basically disabling every other process. It's generally a very bad idea to use.

Share this post


Link to post
Share on other sites
I acknowledge setting realtime is generally a bad idea. The reason I was setting it in this case (or more accurately why I really WANT to use it) is because I want to get my single threaded, single process, full screen app as responsive as possible so I can poll both the raster and the input as fast as possible. Fast polling is the only way I can minimize the amount of error in my measurements.

It definetly does seem like I am starving another essential Windows process from running and therefore my input doesn't show up, but what process is that? My understanding was I was polling the keyboard directly with DirectInput, am I infact polling the results of another processes polling?

Share this post


Link to post
Share on other sites
Quote:
When I set the process priority to realtime, my "game loop" is getting executed correctly but DirectInput fails to register keyboard presses. I am not using buffered and was under the impression that calling GetDeviceState would return the state of the device at that instant.

- What do you mean by "executed correctly"? Does it not get executed correctly with normal or high priority?
- Messing with process priorities, and especially real-time priority, is not advised. It should have a fair set of limitations depending on what windows actually does with them. I'd go for an official win32 newsgroup or something and ask the guys over there.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
No, the game loop is executing correctly under all process priorities. Under realtime however the direct input polling is not returning up to date information. I was simply trying to up the process priority in hopes of getting a more responsive process, that is, getting more processor attention so that the distance between my input polls was shorter in duration. For the particular application I'm working on, milliseconds matter.

Share this post


Link to post
Share on other sites
Using DirectInput is a bad idea in this case. Keyboard input in DI is merely a thin wrapper to the standard Win32 functionality (and not a tunnel into the guts of the system, as it used to be). There's even a joke that talks about Indirect Input. Anyway, you'll be much better served processing windows messages directly.

Share this post


Link to post
Share on other sites
Thanks for the reply. Indirect input make sense, because that is what sure seemed like was happening. Is there anyway to "directly" poll the keyboard? I do not want to be dependent on some other uncontrolled polling.

You mentioned processing windows messages directly, I'm not sure exactly what you mean by this and if doing so in the appropriate way allows polling directly.

Share this post


Link to post
Share on other sites
The direct polling was on OSes before XP (the 9x series in particular), and I don't know the details of why it changed. I assume something was changed in the underlying messaging system that made DI's hack into the input unnecessary.

You could get Windows' GetKeyState, GetAsyncKeyState, and GetKeyboardState methods. I don't know how good the response times of these are. If that doesn't work for you, the best option is probably to alter your window proc message handler to pick up WM_KEYDOWN/WM_KEYPRESS/WM_KEYUP and respond accordingly.

Share this post


Link to post
Share on other sites

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