Timing for pooling loop, and Multi-threading for polling

Engines, Libraries and Tools JInput
#1

I’ve noticed that all of the usual examples have a 20 millisecond polling sleep in the main polling loop. Which raises the question: why 20 milliseconds?

In a long dead thread:

My initial reaction is, what kind of control do games want over the threading model? Java has had nice threading support for ages, and the recent 1.5 and later versions have nice synchronized queues. To me, the obvious model is to have the controller polling in one thread, the command/key/movement action in another, with a third thread for game motion and AI. (with usually another for painting the graphics)

What is the reason that folks don’t implement it this way? Is it technical? or historical?

Are there known problems with putting the polling loop in a separate thread?

Thanks
Pat

#2

Hi

Games often work on fixed time slices and want to be able to predict the amount of time one tick of the game takes. The API was designed that way from the beginning and wasn’t something we could change.

Endolf

#3

I understand the desire for the game to have One Clock to rule them all. But I’m not understanding why that means a fixed polling time for input. That’s really a separate issue, unless I’m confused.

Seems to me that the key to handling input is to get all the events as soon as possible. Pulling the trigger is clearly an obvious example, but even turning (rotation) is critical to survival in a FPS.

Putting in a simple thread to handle and queue up the Event is trivial to do, I did it last night. I’m more interested in why a fixed polling time for events is good.

You say it couldn’t be changed, so perhaps this is just historical. Clearly jInput predates Java 1.5.

#4

JInput was designed to be low level as I understand it. At the OS level on all 3 platforms we support. Polling appeared to map to the lower levels, and as you can see, it’s easy to wrap in something else if you wish. Flexible for all.

And yes, it was originally done when 1.4 was the newest jdk

Endolf

#5

I can understand the historical basis. And I’m not up to speed with the internals of OS-X or Windows more recent than W2000, so it may be true still across the board. But interrupt and/or callbacks are the more modern way to do events, and are less resource intensive. Since OS-X has assorted BSD and Mach origins, I would expect it to work fine with interrupts. For Windows, I would not be surprised that you have to connect into one of the Direct-X apis.

#6

The API was also designed with consoles in mind, although didn’t end up with implementations for any, not publicly anyway.

Endolf

#7

From looking at the code, and debugging the software on my Ubuntu 10.10 system, it appears that the default implementation sets the EventPool size to 10. This would then set a hard limit on the number of Events that can be obtained in a single poll() call. Which would, in turn, set a upper bound on the polling interval. Clearly you don’t want to have the queue fill, so you have to call poll() often enough to capture all events.

its not clear how fast they can be generated. For a mouse’s buttons, or triggers on a joystick, human’s can only fire fairly slowly. A reasonable limit might be 10 clicks/pulls per second. A good typist may type 120 words per minute, which is only 2 words per second. At six characters per word, you have only three characters per second. So three times that would seem to be a reasonable guess. (Not counting, of course, the Korean professional Starcraft folks, they have amazing key abilities).

Rolling the mouse, or moving the joystick, can cause lots more events, far more than trigger pulls or mouse clicks.

In my testing, I don’t see any noticable diference between a 50 millisecond poll rate and a 20 millisecond rate, except that the CPU usage is a lot higher with the shorter rate.

#8

From the feedback we’ve had in the past, most game loops draw 1 frame to the screen too, so 20ms would be 50fps and 50ms only 20fps, but it depends on the game and whether you want to go threaded or not. If you have multiple threads then the poll rate is what ever you decide is a good rate for not getting the queue full, if you are single threaded then you go at the desired fps, as long as the system can keep up :slight_smile:

Endolf