🔒 Locked

DirectInput on different thread

Started by Figgles Jul 10, 2006 at 11:24 PM 2 replies 1.4k views

Original Post

Jul 10, 2006 at 11:24 PM

Hi all, I have a program that polls DirectInput for update information. However, when running a server in the background that competes for CPU power (50% my program, 50% server), the mouse drags in responsiveness. This is obviously due to the fact that the polling mechanism is not being called often enough from the main loop. Now, my computer isn't the fastest of them, but there are definitely slower ones, so I decided that it would be good to create a separate thread to poll DirectInput on to make my input FPS independent. Now, I just finished debugging a multithreaded OpenGL nightmare with contexts and all that fun stuff, and I am not particularly interested in doing this with DirectInput. So, does anyone happen to know what DirectInput's threading policy is. Here are 3 possible situations, I am leaning toward #3, since it best suites my needs. Situation 1: Thread A: Initializes DirectInput, Reads thread shared variable via mutex Thread B: Polls DirectInput, updates shared variable via mutex Situation 2: Thread A: Creates Thread B and reads shared variables via mutex Thread B: Initializes, pools, and updates variables via mutex Situation 3: Thread A: Creates Thread B and reads shared variables via mutex, sometimes calls DI functions from interface created on thread B. Thread B: Initializes, polls, and updates variables via mutex. Anyone have any war stories or wisdom to share on this matter?

DXnut

Jul 11, 2006 at 12:44 AM

Well, the purpose of DirectInput is to give you the shortest path possible from the mouse driver to your application code. Separating it into two threads would totally defeat that purpose. Just using the normal windows message path for mouse actions would be much better, since it puts mouse messages into your message queue that you read from in your message loop. So, the current Windows mouse processing already does what you want, with one thread (handled by the OS) reading mouse inputs and putting them as WM messages onto your message queue, and your main app polling the queue in its rendering loop prior to rendering each frame.

Figgles

Author

Figgles

Jul 11, 2006 at 12:58 AM

That is a non-option =
My program runs under Linux as well, where I cannot write platform specific code to handle messages from my window. Actually, the input library is not connected to the windowing system directly because of this fact.

I appreciate your suggestion, but it is not within the bounds of my question =
On the idea that DirectInput creates its own thread. Indeed it does, I have seen this via the task manager. However just because DirectInput runs a different thread and internally updates its state info rapidly does *not* mean that my application's thread can read the information from it that quickly. That is why I intend to move the input polling to a separate thread so that it is not limited by the GPU's speed (i.e. FPS).

Quote:

...and your main app polling the queue in its rendering loop prior to rendering each frame.

This is the exact logic that leads to my current problem. My app cannot poll fast enough!

Kest

146

Kest

Jul 11, 2006 at 3:34 AM

That's what buffered input is for. When your devices are buffered, you don't poll to get the exact current states of devices. You poll to get every event that has happened since the last time you polled.

Search for "buffered and immediate data" (with quotes) in the docs.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.