Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
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  
  Game Threading  (Read 5227 times)
0 Members and 1 Guest are viewing this topic.
Offline QuicK

Junior Member





« Posted 2012-10-08 02:06:34 »

I'm intermediately experienced with java, and I was wondering how a game should be threaded.

I'm not entirely confident that I know how threads work, so any information on this topic would be great! Smiley

The only thing I really know about threads is that they allow operations to be done without causing the main thread to lag or sleep.

Thanks in advance!
Offline ra4king

JGO Kernel


Medals: 347
Projects: 3
Exp: 5 years


I'm the King!


« Reply #1 - Posted 2012-10-08 02:45:04 »

1 thread for logic and rendering. That's all.

Extra threads should be for very time consuming operations that do not need to run at the same time as the logic, such as reading files, loading resources, and path finding.

Offline kammce

Senior Newbie





« Reply #2 - Posted 2012-10-08 03:14:07 »

And maybe a thread for music and sound as well.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline QuicK

Junior Member





« Reply #3 - Posted 2012-10-08 04:25:32 »

And maybe a thread for music and sound as well.

@ra4king - Do you second this? (I imagine it would be mainly for the loading of sounds which I would generally pre-cache)

Also. When you say 1 thread for logic and rendering, you mean 1 thread total? as in I can just use the main thread?

or do you mean 1 thread for each? Because with my non-optimized rendering of a skybox and a 64x64 grid of cubes, it takes about 2 seconds to finish defining all of the vertices and to initialize the drawing of each. (after this, my fps is fine) and that is what brought me to asking this question.
Offline Phased
« Reply #4 - Posted 2012-10-08 04:27:40 »

What you can do is do not render anything that you can not see, so reducing the 64x64 cube to something that maybe only shows the front side of the cube or something, this will reduce the time.

edit: im assuming you mean a 64x64x64 or something of cubes, so you can render just the outside, but dont render the inside this will reduce it massively from

262144 cubes completely rendered
to
24576 cubes rendering the entire outer of the cube, where you can remove the rendering from the back (as the player cant see the back, that will just reduce it to like 20576 cubes. which should definitely be under 1 second
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #5 - Posted 2012-10-08 04:36:24 »

ra4king is completely right.

1 required thread
- game (logic and graphics).

Extra optional threads...
- music/sound (like ogg, midi, wav, and/or mp3).
- resource loading and reading (which include pathfinding).
- Possibly server thread (if you are working with multi-player online).

Any other thread will slow down your game to a snails pace for no reason. Also, you'll have to deal with synchronizing threads... which is totally not fun when you have to use the java lock and unl... Yeah, stick to 1 thread for game actions, and keep your game quick and headache free.

Offline QuicK

Junior Member





« Reply #6 - Posted 2012-10-08 04:45:15 »

What you can do is do not render anything that you can not see, so reducing the 64x64 cube to something that maybe only shows the front side of the cube or something, this will reduce the time.

edit: im assuming you mean a 64x64x64 or something of cubes, so you can render just the outside, but dont render the inside this will reduce it massively from

262144 cubes completely rendered
to
24576 cubes rendering the entire outer of the cube, where you can remove the rendering from the back (as the player cant see the back, that will just reduce it to like 20576 cubes. which should definitely be under 1 second

It is only a 64x64 space (4096 cubes...I assume this adds up to 49152 faces...12 for each cube (front and back?)) but every face of every cube is being drawn (front, and back).  It was just for testing, I wasn't trying to optimize the rendering. I  just wasn't sure if threading would be involved as part of the optimization or not, but they have answered my question Smiley

Thank you everyone for the replies! Smiley If only I could get this many on my other questions >.>
Offline Roquen
« Reply #7 - Posted 2012-10-08 05:43:35 »

A: It depends.
Offline KittenKoder

Senior Member


Medals: 7



« Reply #8 - Posted 2012-10-08 07:15:39 »

Multiple threads only really help on multi-core processors, most of the time they just over-complicate issues. Though the recommendations for splitting off things like loading and audio can benefit any application, your best bet is that if you don't understand threading well, just don't use more than the main thread. Most classes that benefit from them will create their own threads anyway.

One problem with mixing libraries is if they are not thread-safe then using multiple threads where not initiated on their own will require more programming, and a lot more work. However, if you're making it playable over the network, you will need at least two threads, one for the network and the main thread. Networking complicates matters because of this, and probably why most games are not over the net. Network events will happen out of synch with your main thread all the time, thus why you need the thread exclusively for network data transfer.

I am no one else.
Offline nsigma
« Reply #9 - Posted 2012-10-08 09:37:26 »

And maybe a thread for music and sound as well.

Yes, playback of audio should always be done in a separate thread, and a higher priority one ideally.  However, whether you need to create the Thread yourself depends on which audio library you are using.  Most higher level audio libraries will handle this themselves.  You should be aware of this if you are manually writing bytes to a JavaSound audio line.  I'd use something like TinySound if you need to use JavaSound, rather than using the higher level (Clip) stuff built into JavaSound itself. 

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Varkas
« Reply #10 - Posted 2012-10-08 09:59:48 »

In a multiplayer environment it can be sueful to collect all player input in a queue and let a pool of worker threads handle the queued actions. That way you can scale parallelism very nicely.

In single player games the only thing that comes to my mind in addition to the suggestions above is to prefetch data from disk in a thread of it's own. If your game needs to access a lot of data and you can't keep all of it in memory at once -  in that case the thread would have to estimate the next needed data chunks and read them parallel to the game, so they are readily available when needed.

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Cero
« Reply #11 - Posted 2012-10-08 15:23:08 »

like nsigma said, most libraries do this by default, so you who is just using those libs, doesnt have to create threads manually or anything.
thats true for most of the stuff like audio and maybe input.

situations that force you to built your own thread structure for things like streaming stuff in the background or AI/pathfinding or whatever, should be avoided, unless you really really know what you are doing and/or the scope is small and clear
loading some stuff in the background, where synchronization isnt all that important, may not be that much code and might be ok
but you dont want to do 8 core PS3 dev if you have no experience with it.

Offline sproingie

JGO Kernel


Medals: 202



« Reply #12 - Posted 2012-10-08 18:03:22 »

The proper number of threads to use if you don't understand threading: 1
Offline davedes
« Reply #13 - Posted 2012-10-08 18:22:08 »

I would say the vast majority of 2D OpenGL games will run efficiently enough in a single thread; and thus multi-threading (which greatly increases the complexity of your engine) falls under premature optimization.

Offline matheus23

JGO Kernel


Medals: 108
Projects: 3


You think about my Avatar right now!


« Reply #14 - Posted 2012-10-08 19:10:22 »

I would say the vast majority of 2D OpenGL games will run efficiently enough in a single thread; and thus multi-threading (which greatly increases the complexity of your engine) falls under premature optimization.

Yes. Agreed.

Limitation on agreement ( Grin ):
In special cases multithreading improves performance cracily... (I, for example, had a pretty cpu-intensive light "calculator" (no, not a gl-lighting "engine")) Without threading out the light calculation I got about 20-30 fps (yeah, this was a big issue), then I got 200-300 fps... which is... quite awesome Smiley

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline theagentd
« Reply #15 - Posted 2012-10-09 06:13:51 »

I disagree. Making threadable game logic is very easy at times. Collision detection, AI, etc can be threaded pretty easily. If you're interested you can take a look at a small library I wrote just for this: http://code.google.com/p/small-java-threading-library/

Myomyomyo.
Offline Pickleninja

JGO Coder


Medals: 10
Projects: 1


I'm tired of working for someone else.


« Reply #16 - Posted 2012-10-25 19:17:15 »

1.) Animation ( you don't want animation to freeze while you're waiting for a process to finish )

2.) User Input ( when I click something, I want to see immediate feedback )... I found that this was critical when I was programming my 2D side scroller.

3.) Networking ( latecy on bad connections can reach 2,000ms... you shouldn't hold up other processes because you're waiting for a reply from the server )

4.) Any additional assets that aren't critical to gameplay, but are "nice to haves"... I.E. Music.... If I'm playing WoW, and the music fades in 15 seconds after I log in, I might not even notice, and I'd much rather be running around Stormwind for 15 seconds without sound, then waiting 15 seconds at the load screen waiting for them to start simultaneously.

Hope this helps.

-Pickle

Offline Agro
« Reply #17 - Posted 2012-10-29 00:58:12 »

I usually have animation and networking in the same process/thread. With non-blocking reads of course.

Offline SHC
« Reply #18 - Posted 2012-10-29 01:51:19 »

I use one thread for logic and rendering, one thread for resource loading, and one for each sound in the game. I use the standard EDT to poll input.

Offline Roquen
« Reply #19 - Posted 2012-10-29 09:46:22 »

A thread per sound isn't a good idea.

Rule of thumb: 1.5-3.0 "active" threads per core per timeslice for max throughput.
Offline SHC
« Reply #20 - Posted 2012-10-29 15:18:31 »

How else could I play sounds simultaneously???

Offline theagentd
« Reply #21 - Posted 2012-10-29 15:32:13 »

A thread per sound isn't a good idea.

Rule of thumb: 1.5-3.0 "active" threads per core per timeslice for max throughput.
Since the audio is buffered each threads will only be active a very short time to fill the buffers.

How else could I play sounds simultaneously???
This.

Myomyomyo.
Offline Roquen
« Reply #22 - Posted 2012-10-29 17:33:39 »

I was speaking in general...I assume you don't disagree.  A sound per thread isn't a reasonable thing.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #23 - Posted 2012-10-29 17:51:55 »

How else could I play sounds simultaneously???

Depends what audio api you're using. Usually you have a high-level non-blocking api that you access in your game logic, and under the hood you have one sound thread that does sound mixing and fills audio output buffers (you might also have a single music thread if you're decoding and/or mixing music as well).

If you're using something like java sound then the low level mixing is hidden / done for you.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline i30817

Junior Member





« Reply #24 - Posted 2012-10-29 18:02:10 »

Disregarding the 'simple', what's the best way to profitably multithread AI on a game with multiple permanent agents on a level (assuming that the agents all run physics code, pathfinding, conversations, animations all the time the player sees them, and if he does not, they still need to run pathfinding, and at least part of the physics code (to not fall down the floor, or kill themselves with momentum for instance).
Offline nsigma
« Reply #25 - Posted 2012-10-29 19:26:42 »

Depends what audio api you're using. Usually you have a high-level non-blocking api that you access in your game logic, and under the hood you have one sound thread that does sound mixing and fills audio output buffers (you might also have a single music thread if you're decoding and/or mixing music as well).

Absolutely!  Multi-threading audio code is a recipe for disaster.

If you're using something like java sound then the low level mixing is hidden / done for you.

Unfortunately, the low-level bit of JavaSound is about the only bit that isn't shit!   Wink  If you're using JavaSound, you'd be better looking at a third-party library to handle the mixing on top of it.  TinySound seems promising.  If you need something more complex then Beads is also worth a look (and in the process of transitioning to JAudioLibs under the hood).

Praxis LIVE - open-source intermedia toolkit and live interactive visual editor
Digital Prisoners - interactive spaces and projections
Offline princec

JGO Kernel


Medals: 386
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #26 - Posted 2012-10-29 21:44:36 »

The route to profitable multithreading would seem to be:

1. Use FBOs and VBOs in OpenGL exclusively, and use glMapBuffer() to get the buffers and write into them when you're doing your drawing. This parallelises the GPU and CPU load for free! All your OpenGL calls return instantly, leaving your game to do all its thinking.

2. Rely on the fact that Java already has a couple of background threads doing stuff for you which you probably don't even realise - the JIT compiler and some GC work. That's a small win right there for no effort whatsoever. Your game is already multithreaded!

3. All your networking code will be running on another thread or two somewhere, if you've got any; if you're on a dualcore system only, then while one core is very busy making games run and feeding morsels to the GPU, the other core will be very happy taking care of all the little but important jobs without causing any hiccups, like the JIT, GC, networking, OS work, etc.

4. Your sound mixing and music decoding will also be using up a bit of time on another core.

5. Should you still find yourself a spare core lying around with nothing to do most of the time, you are in a world of pain attempting to parallelize your game logic in such a way that won't either cause deadlocks, inconsistent state, or stalls. Here the gain:pain ratio is significantly poor enough to seriously reconsider whether you are spending your time wisely.

<edit> Forgot sound/music

Cas Smiley

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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (19 views)
2014-09-24 16:12:06

Grunnt (43 views)
2014-09-23 14:38:19

radar3301 (25 views)
2014-09-21 23:33:17

BurntPizza (62 views)
2014-09-21 02:42:18

BurntPizza (32 views)
2014-09-21 01:30:30

moogie (37 views)
2014-09-21 00:26:15

UprightPath (50 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!