Jump to content
  • Advertisement
Sign in to follow this  
etsuja

Multithreading games

This topic is 4380 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm just starting to program a game and was thinking about making it multi threaded. Anyone with multi threaded game programming experience wanna give me some advice on how to implement it? If the work load was divided equally between threads would performance double on dual core machines?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by etsuja
I'm just starting to program a game and was thinking about making it multi threaded. Anyone with multi threaded game programming experience wanna give me some advice on how to implement it? If the work load was divided equally between threads would performance double on dual core machines?


No. Some part of a program is inherently serial, and thus won't benefit from threading. See Amdhal's law for detail

There are featured articles on gamasutra that deal about this (they might need a free registration):
Multithreaded game engine architecture
Threading 3D game engine basics.

HTH,

Share this post


Link to post
Share on other sites
IMHO unless you actually need[1] it you should avoid having multiple threads as much as possible. They'll add considerable complexity, and a whole range of bugs, most of which are hard to reproduce and test. If you're just doing this for fun then multithreading is a whole heap full of headaches that you can do without (especially if you've not even finished a game yet).

[1] Ie. you know your target hardware will have multiple processors and you're already CPU limited.

Share this post


Link to post
Share on other sites
Quote:
Original post by OrangyTang
IMHO unless you actually need[1]

[1] Ie. you know your target hardware will have multiple processors and you're already CPU limited.

Heh. I've said exactly the same thing, almost word-for-word. But there are some exceptions, most notably background resource loading. Think GTA, Dungeon Siege, and any other game with a seamless world and no loading screens. You can't do that with one thread. Or if your game involves a CPU-intensive simulation and you want to maintain a decent framerate, multithreading may be beneficial.

If your game has none of these requirements, please don't adopt a solution in search of a problem.

Share this post


Link to post
Share on other sites
Quote:
Original post by drakostar
Heh. I've said exactly the same thing, almost word-for-word. But there are some exceptions, most notably background resource loading. Think GTA, Dungeon Siege, and any other game with a seamless world and no loading screens. You can't do that with one thread. Or if your game involves a CPU-intensive simulation and you want to maintain a decent framerate, multithreading may be beneficial.

If your game has none of these requirements, please don't adopt a solution in search of a problem.

Aye, background loading fits into the 'need' catergory, as it's pretty much the only way to do it. Depending on the libraries you're using sound and networking may also require additional threads, but they're usually quite easy to deal with as they only interact with a small section of your code.

Share this post


Link to post
Share on other sites
Quote:
Original post by etsuja
I think what I'll do is try to have the physics and maybe some AI running on seperate threads.


The AI would most likely depend on the physical representation of the world, how would you handle that? You could lock all physics objects before modifying, but this could introduce very heavy slowdowns unless done very well (then it would only introduce big slowdowns). You should also be aware that this could introduce problems, because lets say the physics engine is trying to update frame n's content to what frame n+1 should look like, well sometimes the physics engine will modify first and at other points the AI will read first. So some of the AI (in some cases even the same agent) would depend on the n'th frame's geometry, but other parts of the AI will depend on the (n+1)'th frame's geometry. In extreme cases the AI could even be split up over more than 2 frames' content. This problem could be eliminated by making sure that the AI only touches a region when the physics engine has updated it, but then suddenly the AI engine is going to wait a lot on have to "follow" the physics engine. Wasn't this the kind of stuff we was getting away from? You could also choose to copy the whole physical representation before making any changes to it, so that the physics engine and the AI engine works with seperate data, this would elimante almost all shared data, but it would be expensive memory-wise and could also result in the AI working on earlier frames than the physics engine.

This was just to show you that it might not be as simple as it seems, now imagine if you also have to consider the graphics engine working on a copy of the same content and maybe even other engines too.

Share this post


Link to post
Share on other sites
Quote:
Original post by etsuja
I think what I'll do is try to have the physics and maybe some AI running on seperate threads.


These are the hardest things to seperate into threads, as your rendering will be constantly asking for position data that the physics code will be updating, and so will the AI.

I don't think I personally could come up with a multithreaded solution for physics AI and rendering that would be more efficient than running them all in the same thread...

Share this post


Link to post
Share on other sites
Im currently working on a game aswell (surprise surprise :) ) and the same question about multithreading came to my mind aswell.
I can see from your posts (and get the point why) that it is highly undesirable to have but wouldn't networkconnections be a suitable applicaiton for threading ?

Share this post


Link to post
Share on other sites
Quote:
Original post by ChristianJames
but wouldn't networkconnections be a suitable applicaiton for threading ?

Usually no. Ask yourself what the network communication affects. Game logic, right? So you need to poll for incoming network data, add it to whatever else is going on in the game world, then send out your own changes for each cycle of game logic (and by this I mean things like updating a player's position, checking for collisions, etc). Asynchronous I/O should do everything you need.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!