Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (576)
games submitted by our members
Games in WIP (497)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Timing for pooling loop, and Multi-threading for polling  (Read 3742 times)
0 Members and 1 Guest are viewing this topic.
Offline fishtoprecords

Senior Newbie





« Posted 2011-02-04 22:06:42 »

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?

Thanks
Pat
Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #1 - Posted 2011-02-05 12:35:42 »

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

Offline fishtoprecords

Senior Newbie





« Reply #2 - Posted 2011-02-05 16:00:02 »

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #3 - Posted 2011-02-05 16:08:29 »

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

Offline fishtoprecords

Senior Newbie





« Reply #4 - Posted 2011-02-05 17:07:05 »

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.
Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #5 - Posted 2011-02-05 18:01:20 »

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

Endolf

Offline fishtoprecords

Senior Newbie





« Reply #6 - Posted 2011-02-06 03:12:32 »

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.
Offline endolf

JGO Knight


Medals: 7
Projects: 1


Current project release date: sometime in 3003


« Reply #7 - Posted 2011-02-06 10:44:44 »

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 Smiley

Endolf

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

xsi3rr4x (11 views)
2014-04-15 18:08:23

BurntPizza (10 views)
2014-04-15 03:46:01

UprightPath (23 views)
2014-04-14 17:39:50

UprightPath (10 views)
2014-04-14 17:35:47

Porlus (27 views)
2014-04-14 15:48:38

tom_mai78101 (49 views)
2014-04-10 04:04:31

BurntPizza (107 views)
2014-04-08 23:06:04

tom_mai78101 (207 views)
2014-04-05 13:34:39

trollwarrior1 (176 views)
2014-04-04 12:06:45

CJLetsGame (182 views)
2014-04-01 02:16:10
List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:05:20
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!