Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There's this post, it's highest voted answer got me curious about the many ways of threading games.

My game has input update, game logic update, user interface update and expensive operations methods. Usually the game runs smoothly, but sometimes the user triggers a very expensive method that makes the game freeze for a few seconds, which is of course unacceptable for release, but the method serves development purposes. I hope the freezing can be resolved by threading, so that expensive method may be used in release.

Everyone says the UI thread must have the highest priority, but I'd like it to be second to the input update thread, so the interface (as well as player controls) is as responsive as it can be. But maybe I'm wrong and it doesn't work as I'm imagining, I haven't really succeeded in trying out either way, since XNA is a bit different from a normal C# application (always running Update method instead of just going down the code).

Which threading option (ThreadPool, Thread or BackgroundWorker) should I use (and how) to achieve maximum responsiveness, while not letting the game freeze when doing occasional expensive operations?

Stuff to read on threading:

share|improve this question

closed as too broad by Josh Petrie Jan 2 '14 at 17:53

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

Instead of complicating things with multithreading for what seems to be a development-only operation, have you tried doing something like time slicing your "expensive operation". That is, to separate out the work across several frames to make it have less of a performance impact? – Tetrad Feb 27 '13 at 22:26
A simplified version of that method will be a part of the game world update method, but it still can take enough time for user to see artifacts. I wasn't able to chop it into pieces good enough to not cause freezing and yet finish on time. Besides, there will be more parts of world update, which will only make it worse and harder to regulate manually. So I thought why not do that in a thread. – user1306322 Feb 27 '13 at 22:32
How often does the operation occur? Can you simply dim the screen down and display 'Please wait...'? If it's just a development thing and it doesn't happen very often, this can be a quick implementation and save a lot of threading head-ache. – Vaughan Hilts Feb 27 '13 at 23:04
I'm so into threading head-ache! The operation is game world update, so it's gonna happen every now and then, it runs for about 4 seconds and has to be run every 30 seconds. I'd like to run it more often, though. I tried putting it into a Thread and BackgroundWorker, and it still causes severe lags, but over time, instead of a constant freezing. Maybe there are some parameters to tune them, but I couldn't find a nice tutorial that tells me how to do this without causing lags. – user1306322 Feb 27 '13 at 23:12
Sounds like you just need to profile and modify whatever operation blocks so that you can execute it in a small timeframe (10ms) over multiple frames. For example, if your world is 100k objects, update, say, 100 per frame (100 frames = up to date) – ashes999 Feb 27 '13 at 23:52