multi-thread

Started by
10 comments, last by frob 10 years, 7 months ago
Bottom line: introducing multi-threading can cause you to spend a lot of time thinking about and developing things in a way that probably isn't very intuitive. If you don't absolutely need it and know what you're doing need it, then it may be better to spend time on the actual gameplay.

When I wrote my game engine, I needed it to scale with the number of cores, processors and machines. My general approach was to write my game as a set of serial tasks (update, network, physics, audio, render), but allow each step to spread out to use many worker threads when needed. Some of the systems were running their own internal threads and used the serial part to transfer queued messages (network, audio and renderer did this). I was able to show my system scaled almost linearly with the number of cores.

I spent a lot of time developing data structures that allowed for contention free processing without locking. Entity state, spatial data structures, profiling, event management all needed double buffering and special control structures to make things work properly. I spent even more time debugging this stuff.

If you really want to multithreaded your game ill be happy to discuss how I did it in more depth, but if you're on the fence, then you're probably better off not.

Cheers,

Bob

[size="3"]Halfway down the trail to Hell...
Advertisement

As Khatharr mentioned above, you automatically get a boost from it. Yours is not the only application running. Having multiple processors means that even if your app is single-threaded, you still generally get one full processor to yourself.

There are many ways to take advantage of the processors without actually resulting to multithreading your app. Use asynchronous calls liberally. The operating system will do the work in the background and allow your application to continue to running.

If you do decide to write algorithms that require multiprocessing, remember that your game will likely need to be runnable on single-processor machines. Also remember that heavily loaded machines may degrade to single-processor performance and your program (not the bogged-down system) will be blamed for bad performance.

It is consequently unwise for mandatory processing to require multiprocessing. If you build your game such that it requires a quad core processor and for whatever reason all four processors are not available (including heavy system load due to all the malware) your game will perform poorly.

Building your game so that eye candy uses extra processors, sure that is fine. Throw all those extra visual effects onto the spare processors. Put the extra audio processing on extra processors. Don't put game-critical systems on those extra processors because they might not be there.

This topic is closed to new replies.

Advertisement