Archived

This topic is now archived and is closed to further replies.

SikCiv

Too many threads is bad?

Recommended Posts

SikCiv    122
I want 2 extra threads in my game, one to control the gameplay, the other to update the GFX using DirectX. Using two threads should be ok right? I know two threads shouldnt access DDraw surfaces at once so im going to limit surface blits to one thread. But how fast should the timer frequency be? Im affraid of timing inconsistancies etc..

Share this post


Link to post
Share on other sites
cyberben    122
Yah, this is a good idea, you basically have a thread that does nothing but cycle through your structures and paint everything, no handling. Then another thread that updates everything, updates unit positions, updates mouse pos, update buildings, update wheater? Whatever, but this thread uses good timing so that it runs the same on everycomputer no matter how many fps the graphics thread is getting...

It''s harder to implement but works well from what I''ve heard...
- Ben

Share this post


Link to post
Share on other sites
baskuenen    124
You can also put it all in a single loop. Just multiply the distance an object should move with the time passed since last update. Your program will run faster this way!

If you use 2 threads, you might end up doing 2 screen updates but only 1 "game" animation. This way calculating & drawing the same screen.
Or: Draw ones, but do 2 animation updates...one not visible on the screen...

Share this post


Link to post
Share on other sites
maikgerth    122
if u use threads in your game ... u got to do ALOT of synchronization special cases ... for instance ... a creature died right when the draw-thread is drawing it ... and right at this moment its deleted (just a little example -)) --> this would result in a crash if u got bad luck hehe

and if u synchronize too much u got performance lost ....

so if u are doin a FPS-based game ... i wouldnt use threads ...
if u are doin a strategy/(alot of side computation) based game ... threads would be better i think to keep frames updated faster

this are just my experiences ... so im not sure ..

Share this post


Link to post
Share on other sites
MadKeithV    992
quote:
Original post by baskuenen
[ If you use two threads you could end up with: ]
Draw once, but do 2 animation updates...one not visible on the screen...



This is the case you''re aiming for - if the animation is the limit, you''re not limiting game speed, you''re just reducing frame-rate. Reduced frame rate isn''t so bad, and your game world keeps ticking along at it''s normal rate.

Thread-synchronisation can be hard to implement ( get a good library, or read up on it a LOT ).

And lastly, at the moment you''re talking about just two threads, that''s fine. You might be tempted to put in a LOT of threads, and this has several risks:
- Synchronisation and context switching could end up eating a lot of your processor time, with little gain with regards to timing issues.
- You could run into threads-specific problems, such as the "thundering herd" syndrome. Having things like this go wrong in your code is a bugger, and you''ll usually end up rewriting it serially.

So bottom line:
don''t use threads unless you know how, and you know why!





Give me one more medicated peaceful moment.
~ (V)^|) |<é!t|-| ~
ERROR: Your beta-version of Life1.0 has expired. Please upgrade to the full version. All important social functions will be disabled from now on.

Share this post


Link to post
Share on other sites
Dogfood    122

You need to be careful with mutex''es. Only 1 thread at a time can have a mutex you''ve created, so its easy to have two threads both needing two mutexes, but if the other one has it, you have two-process dead-lock. If you only ever lock 1 mutex at a time, this problem won''t happen.


One of the bigger advantages of multithreading is that your program can take advantage of multiprocessor systems(each thread willl probably end up with its own processor). This may be of more relevance to server side code for games rather than client side, but worthing knowing.

Share this post


Link to post
Share on other sites
SGreth    218
If gamers and developers start considering Win2K (vs 98) the the benefit of multiprocessing is supported. I know that I''m definately keeping that in mind during my development. Now that we have consoles with extra chips on them just for specifc tasks, I think that game programmers are going to have to consider optimizing for dual processor systems! Of course right now you''re only talking about a small percentage of gamers that have dual processors, but perhaps if games start coming with special optimizations/features for those who have dual systems we just might see an increase. Just a though though....

~S''Greth

Share this post


Link to post
Share on other sites
Dogfood    122

Well, actually you don''t have to optimize for any number of processors. The cost of multitasking threads is much lower to the OS than processes(just has to change stack frames, instruction pointer stuff, the page tables for most of the memory will be the same)(this may not be entirely accurate, but the general principle holds). N threads can be divided among up to N processors to take advantage of multiprocessor systems. The server for my MMORPG has a command line option for the number of threads to process connected users.



I recommend if you''re going to make a multithreaded game engine, make it easy to configure the number of threads involved, its a good way to divy up functionality. If two or more threads can work on the same job, go ahead and make it configurable to how many threads are created. For you 3d junkies out there, lots of 3d algorithms are well known to be easily parallelized(is that a word?).

Share this post


Link to post
Share on other sites
maikgerth    122
i wonder how many people work on multiplayer-rpgs ...
well my roleplaygame-server uses a thread for each client that connects ...but im not using mutexes at all ... i do my own synchronization ... the reason is that the server must be able to compile on linux/unix and winnt and im afraid its alot different ...

im just using some global variables as "signs" ... its a little complicated but it seems to work quite well

Share this post


Link to post
Share on other sites
CondorWitte    122
I don''t know much about Unix/Linux, but I do know a few things about Win32:

When using a global variable as synchronisation-object, there are a few drawbacks:

- Polling the variables is consuming cycles
- Creating a timeout-mechanism to avoid deadlocks is probably as different for Unix/Linux & Windows as implementing some sync-objects using CreateEvent(), SetEvent() and WaitForSingleObject() is...

Greetings,

CondorWitte.

Share this post


Link to post
Share on other sites