DirectInput and process priority

Started by
9 comments, last by Promit 18 years, 5 months ago
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?
Advertisement
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.
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?
Anyone else have more details or ideas about whats going on here?
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.

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.
Ooops, didn't realize I wasn't logged in. That last post was mine.
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.
SlimDX | Ventspace Blog | Twitter | Diverse teams make better games. I am currently hiring capable C++ engine developers in Baltimore, MD.
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.
You also mentioned DI used to allow direct polling, can I simply use an older interface to achieve this?

This topic is closed to new replies.

Advertisement