Jump to content
  • Advertisement

Archived

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

Rasmadrak

Two threads? Update() and Draw() ??

This topic is 5356 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

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!

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

  • 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!