Game Threading

[SHC]

How else could I play sounds simultaneously???

[theagentd]

@Roquen

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.

@SHC

How else could I play sounds simultaneously???

This.

[Roquen]

I was speaking in general…I assume you don’t disagree. A sound per thread isn’t a reasonable thing.

[Orangy_Tang]

@SHC

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.

[i30817]

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).

[nsigma]

@Orangy Tang

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.

@Orangy Tang

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! 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).

[princec]

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.

Forgot sound/music

Cas