Jump to content
  • Advertisement
Sign in to follow this  
Roots

How freely do you use multithreading in your games?

This topic is 4973 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 put my message pump and my game code in separate threads, just so I can forever split off the stupid windows stuff (boring) from the interesting game stuff (fun!). I would otherwise not use it, unless I was doing something like multiplayer support, in which case it would be a good idea to do the communication stuff in another thread...

I'm sure threading can help design a really nice architecture, but the fact that thread-based things are a pain in the ass to debug (since bugs having to do with thread interaction are hard to trace due to randomness of how threads are switched between) outweighs the benefits IMHO.

Share this post


Link to post
Share on other sites
Advertisement
I use a separate thread to load game data (at the beginning) while the users is seeing a progress bar drawn on the screen

Share this post


Link to post
Share on other sites
I haven't used many threads for things I've done as they've all just been simple things that didn't gain anything from over doing it with threads, but the main thing about them is take your time with designs so you know what they're doing.

Aslong as you're careful and know what you're doing, threads are great, as long as they're clean. If you get lazy in any part of them, and start making 'shortcuts' then you're screwed, and might have to start over rather than figure out where the hell that random bug that pops up 1 in 50 times.

Share this post


Link to post
Share on other sites
Well... I usually don't use multithreading very much tbh! In general, I'd also say don't use it unless there's some benefit to it, because multithreaded issues are hard to debug.

The main places I've personally seen where it's useful are:

1. Things that will stall the machine...
A) Networking code in some cases
B) Loading large maps

2. Multiprocessor / hyperthreading

3. Some background task that needs to continue running (e.g. sound)

roos

Share this post


Link to post
Share on other sites
1+ thread for sound engine.
1 high priority thread for timmer.
1-2 worker threads for 3D engine. There might be additional helper threads.
1 - multiple for game engine.
5+ worker threads for game engine.
If world engine is separated then some threads of game engine are in fact threads of world engine.
possibly passive input thread, if polling of input devices isn't fast enough, or don't work well on high priority, to be done in some executions of the timmer thread.

All of them are async as much as possible, or more. There is some methodology for multithreaded FAST 3D engine, and I developed error cancelation that seems to work to some extent with world engine.
There might be also low priority prefetch threads, and critical safe shut down thread sleeping until needed.
And yes I often don't use thread for inicialization for actual running the game. Just if something would go wrong it's a nice safety net.

If sleeping would work better under windoze XP, you could play a game, and do rendering on background at the same time. Of course such things work better under Linux.

Share this post


Link to post
Share on other sites
I tend to use threads all over the place.
The networking engine I use is highly threaded to the point all processing is detached to a thread.

Graphics I tend to keep in one thread.

Windowing and messaging go in same thread as graphics because I really don't care about it that much.

games generally aren't thread heavy due to the complications with them, static buffers are a real problem in threads. So most people stay away. There are locking routins to ensure thread sychronization, but then that sort of ruins the point of threading your application.

If you're finding out you have to mutex every thing then you probably shouldn't be using them.
Another thing is a lot of libraries (OpenGL) aren't very thread safe. If you read about threading in OpenGL its threadsafe as long as you lock all calls to it. Which basically tells me its not rentrant.

Share this post


Link to post
Share on other sites
More threads are good.
More sync needed (ie. Mutex, Semaphores, Condition Var) is bad.

In gaming there are thousands of good places to open up your logic into new threads.

A good example would be Unreal Tournament 2k3, the newest one...
It has a seperate thread for each piece of its gameLogic.

http://cache-www.intel.com/cd/00/00/20/40/204080_204080.pdf

That is a rather interesting article for anyone who wants to further the proof.

Share this post


Link to post
Share on other sites
Quote:
Original post by anonuser
Another thing is a lot of libraries (OpenGL) aren't very thread safe. If you read about threading in OpenGL its threadsafe as long as you lock all calls to it. Which basically tells me its not rentrant.


which makes sense, as your gfx card cant multi-task, which means some locking is going on 'somewhere' in a reentrant API like D3D.

My point of view as to why a re-entrant gfx API is not really usefull can be found here.

edit:

and for the record, I'm kinda in the process of testing a system which handles rendering via interpolation in one thread, world updates in a 2nd and leaves window and message handling to the main thread. The rendering is done via OpenGL.

I'll probably also require a thread for sound at some point and networking will be handled by whatever networking library I decide to go with so I wont have control over threading there I dare say.

Share this post


Link to post
Share on other sites
actually the PS3 not so good at doing it, because not enough memeory on the VPUs. And the 970 is really hard to program for.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!