File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Taking advantage of multiprocessing in game programming Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Taking advantage of multiprocessing in game programming" Watch "Taking advantage of multiprocessing in game programming" New topic
Author

Taking advantage of multiprocessing in game programming

Phil Freihofner
Ranch Hand

Joined: Sep 01, 2010
Posts: 115
    
    1
One of the "good parts" of Java that has intrigued me is that one can program multiple threads.

Now, there has been some back and forth whether the "best way" to run a game loop is to use the classic form (while loop that executes updates then display then sleeps to fill out the duration of the loop) or to do so via a Timer that iterates, launching a new thread for every game cycle. As multithreading continues to be a place where Java excels, it seems to me that a Timer-based game loop system makes a lot of sense, and may end up being a better choice than the classic game loop. But the classic game loop is definitely the most popular choice currently.

Does this seem reasonable, or does it betray some misconceptions about multithreading and Timers on my part? Or maybe the game loop itself is not an area where multithreaded aspects make too much difference. Maybe the key aspects of multiprocessing is, rather, in the ability to have parallel threads handling the increasingly complex graphics (lots of calculations in 3D) and sound playback.

Anyway, I'm curious what sort of matches you see there being between the language's "good parts" and game programming.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3573
    
  14

Personally, I think spawning a new thread per cycle makes very little sense.

You use threads when you want to do two things at the same time. Do you want to draw the two cycles at the same time? No, you always want to draw them one after the other. So just use a single thread. If you use multiple threads you are going to introduce a *lot* more complexity. What if the timer spawns two threads, and the latest one finishes its cycle before the old one?
Jim Waldo
author
Greenhorn

Joined: Jun 22, 2011
Posts: 29

I agree that spawning a thread per cycle doesn't make a whole lot of sense, unless you plan on having multiple cycles occurring at the same time (which doesn't make a lot of sense, either).

If you are talking about a single-player game, then you might want to think about having a single thread per entity in the game (such as the AIs) and let each thread use a cycle for a synchronization point (the hard part of doing multi-threaded programming is the synchronization and data sharing).

If you are thinking about a multi-player game, then things get more interesting-- using multiple threads on the server, one for each player (or one for each player's interaction) can let you spread the server side of the game over multiple cores in a way that allows much better use of modern multi-core chips. I spent a couple of years working on such a project in Sun Labs; the result is available in open-source format under Project RedDwarf. There were a lot of interesting ideas in the server only some of which we had time to finish up before Oracle took over Sun (and decided that they didn't do games, and hence cancelled the project).


Jim Waldo
Author of Java:The Good Parts
Phil Freihofner
Ranch Hand

Joined: Sep 01, 2010
Posts: 115
    
    1
What if the timer spawns two threads, and the latest one finishes its cycle before the old one?


I decided to check this out. The following code and the Console results shows that the threads spawned by a single Timer do not overlap. Or rather, "what happens" is that the new thread is blocked by the previous thread.


I think that the classic game loop is often placed on its own thread anyway, so having a sequence of threads that never consume more than a single thread, perhaps that is not such a bad thing?

The benefit of the Timer is that it automatically keeps the frame rate even, without requiring calculations to determine elapsed time per frame. The contingencies written to manage overages with a classic game loop can also be applied to the Timer thread instance.

But to go back to my first question, I can see that there probably isn't anything to be gained, in terms of multiprocessors with this particular aspect of game code. Maybe, just maybe, it would be an interesting exercise to write two loops, one for updating game state, the other for refreshing the display, and have them work concurrently at separate rates. The suggested possible use, separating out AI, also makes a lot of sense to me.

However it is neat to consider the uses in multi-player games. I hadn't heard about Project RedDwarf. This looks very cool! Thank you for the link.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3573
    
  14

Oh yes, using a timer like this is just fine. But you are not using multiple threads here. You're just having multiple tasks being executed by one thread. This is a big difference.
 
Consider Paul's rocket mass heater.
 
subject: Taking advantage of multiprocessing in game programming
 
Similar Threads
Java training in Chennai?
Please Help me Out
multithreading,tasking
How many requests can handle a port at 'a' time
Diff. betn multithreading and multiprocessing