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.
How freely do you use multithreading in your games?
I use a separate thread to load game data (at the beginning) while the users is seeing a progress bar drawn on the screen
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
