Where can I use multithreading in a simple 2D XNA game? Any suggestions would be appreciated
A:
There is lots of place to apply to: AI, objects interaction, multiplayer gaming etc. This depends on your concrete game.
ironic
2009-12-21 17:51:26
+6
A:
Well, there are many options -
Most games use mutlithreading for things such as:
- Physics
- Networking
- Resource Loading
- AI/Logical updates (if you have a lot of computation in the "update" phase of your game)
You really have to think about your specific game architecture, and decide where you'd benefit the most from using multithreading.
Reed Copsey
2009-12-21 17:51:41
For example: Forza 3 runs at 30fps, but the (amazing) Physics engine runs at 60fps.
Sneakyness
2009-12-21 17:54:04
Yeah - Physics is very often pushed into a separate thread. That was partly why I listed it first - it's one of the more common, and more important, elements to thread if you're needing better perf.
Reed Copsey
2009-12-21 17:56:47
How we can use it in Networking?
Azat
2009-12-21 18:05:20
You can push all of the networking into a dedicated thread, and use a Producer/Consumer pattern to access it via the main thread. This way, you're never blocking for communication in the main game thread...
Reed Copsey
2009-12-21 18:18:28
I'd recommend not doing networking in a dedicated thread. There are simpler (and thus safer) ways to achieve non-blocking network behaviour so you may as well use them.
Kylotan
2009-12-25 14:25:56
@Kylotan: Most non-blocking networking behavior involves threading of some form - whether managed by you or the OS. Polling is pretty much the only non-threaded, asynchronous networking option, and is not used very often (for good reason). Keeping the networking on a separate thread and handling the asyncrhony yourself is actually quite simple, and very effective, in many situations - especially for a highly-network oriented game.
Reed Copsey
2009-12-27 20:07:00
A:
Why do you want to use multi-threading?
If it is for practice, a reasonable and easy module to put in its own thread would be the sound system, as communication is primarily one-way.
Shmoopty
2009-12-21 17:51:54
I need to in my university project :) never used multithreading before (I mean in serious projects), I've been told to make a multithreaded program, which uses syncronization, animation and some another stuff, I think game best fits all this needs. But as I have told, I never used multithreading, and I can't imagine, how can I use it in a game.
Azat
2009-12-21 18:09:21
+2
A:
Some games use multithreaded renderers as a core design philosophy.
For instance... thread 1 calculates all of the game logic, then sends this information to thread 2. Thread 2 precalculates a display list and passes this to the GPU. Thread 1 ends up running 2 frames behind the GPU, thread 2 runs one frame behind the GPU.
The advantage is really that you can in theory do twice as much work in a frame. Skinning can be done on the CPU and can become "free" in terms of CPU and GPU time. It does require double buffering a large amount of data and careful construction of your engine flow so that all threads stall when (and only when) necessary.
Aside from this, a pretty common technique these days is to have a number of "worker threads" running. Tasks with a common interface can be added to a shared (threadsafe) queue and executed by the worker threads. The main game thread then adds these tasks to the queue before the results are needed and continues with other processing. When the results are eventually required, the main thread has the ability to stall until the worker threads have finished processing all of the required tasks.
For instance, an expensive for loop can be changed to used tasks.
// Single threaded method.
for (i = 0; i < numExpensiveThings; i++)
{
ProcessExpensiveThings (expensiveThings[i]);
}
// Accomplishes the same work, using N worker threads.
for (i = 0; i < numExpensiveThings; i++)
{
AddTask (ProcessExpensiveThingsTask, i);
}
WaitForAll (ProcessExpensiveThingsTask);
You can do this whenever you're guaranteed that ProcessExpensiveThings() is thread-safe with respect to other calls. If you have 80 things at 1ms each and 8 worker threads, you've saved yourself roughly 70ms. (Well, not really, but it's a good hand-wavy approximation.)
Dan Olson
2009-12-27 07:05:23