Two threads? Update() and Draw() ??
Is it a good idea to have a separate threads for doing the game updates (weather, unithandling etc) and another for drawing everything?
also; if I go with two threads, is there really a need for timebased movement in the update function? since the thread runs independently from the drawing there should be no slowdowns (gameplay wise) if heavy rendering occurs etc..?
Anyone got a answer to this?
Cheers!
You need time based movement no matter what... its not just a question of keeping the speed constant, you also need the game to run at the same speed no matter what PC you play it on (3GHz or an old 486 with 33 MHz CPU).
As for the Update() and Draw() functions being kept seperate is a good idea IMO... I originally had everything in a Render() function, then i split it into Update() and Render(). It helps keep things more consistant, because sometimes you might render something and then afterwards further in your render function you might change its position but since u already rendered it, the changes won''t be seen until the next frame.
As for the Update() and Draw() functions being kept seperate is a good idea IMO... I originally had everything in a Render() function, then i split it into Update() and Render(). It helps keep things more consistant, because sometimes you might render something and then afterwards further in your render function you might change its position but since u already rendered it, the changes won''t be seen until the next frame.
Splitting it into two functions is great, yeah, in fact it''s almost mandatory. But two threads... no, unless you happen to be God of the Mutex.
The two operations cannot be run in parallel. You need to update, then draw, then update, then draw, et cetera. As such, using two threads, one for update and one for draw, is inappropriate.
Update() and Draw() can be in separate threads, and it actually helps in many cases. You can, for example, keep the update cycle at a fixed rate to make it easier for multiplayer syncing, but let the graphics fly off at their own rate. Conversely you can lock the frame rate to the monitor refresh rate and let the game logic use up the rest of the CPU time. Or you use separate threads just to see it run more efficiently on a dual-processor system.
the only issue is the normally rather tight and massive inter-communication between the threads. they share the whole world. to make those accesses threadsave, and don''t lock anything too much, thats hell of a job. doable, for sure, but it''s quite some work.
If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia
davepermen.net
If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia
davepermen.net
Unless you know you''re going to get a real advantage by running each thread on a separate processor (hint: next gen consoles) despite mutex issues, you''re better off running them sequentially.
You could see some increases in speed by going with two threads in your current scenario. Basically, while your GPU is busy rendering, your other thread (update thread) can use the CPU to perform functions.
In the single thread based scenario, your CPU is essentially doing nothing for your game while its waiting on the GPU to complete a task (on blocking calls).
The same applies for file I/O (blocking calls).
You do have to worry about some synchronization issues, but its not really a big deal if you take some time to properly design your code.
In the single thread based scenario, your CPU is essentially doing nothing for your game while its waiting on the GPU to complete a task (on blocking calls).
The same applies for file I/O (blocking calls).
You do have to worry about some synchronization issues, but its not really a big deal if you take some time to properly design your code.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement