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:
Nope. JInput is a polled API, you always have to poll it. If you want to do what you say, you could write a thread that polls the API and then calls in to your code on a listener interface, but it seems odd. Most games want control over the threading model, so polled APIs seem more acceptable to developers.
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?