It really depends on your UI library and what you call rendering. In WPF, for example, rendering is already a thread separate from UI thread. I don't think this is a correctly posed question. In all cases, you should separate the game scenario from UI. Then you just have to render the scene in the form of data, and this hardly can be a thread different from "scenario" thread. But the UI rendering (GDI, DirectX, whatever) is nearly inevitable comes in a different thread, but what is it, UI thread or yet another thread, depends on the technology.
[EDIT #1]
First of, all the format of the forum does not allow to consider this problem seriously, especially when you try to do some generalizations. I would say, generalization is especially dangerous here.
Consider you are playing tennis with a wall. It's good to have a thread representing the ball. The UI thread will give you the events which you can use to change the motion due to collisions with a racket. When you introduce "play against a computer", its good to have a thread representing your opponent player. At the same time, if this is football, perhaps you will need a thread representing a whole team of players.
Nothing is so straightforward as you probably trying to imagine. However, I would try to list some architectural notions you should not mix up with a thread.
- Thread should not be coupled with a layer in a multilayer architectures (and practically all architectures should be multilayer). A thread can execute the code of several layers; and a layer can host several threads.
- Thread should not be coupled with a functional unit. A thread can execute the code of several functional units; and a functional unit can host several threads. In particular, a thread should not be associated or couples with some algorithm.
- Thread should not be couples with a compilation unit, such as a .NET assembly. Same as above.
It is very important to understand that threads should not be considered as a performance tool. In particular, if you try to use parallel processing with a number of threads which is significantly more then the number of CPU cores, you will loose in performance, due to apparent overhead.
The thread, by its nature, is rather a representation of something consisting of a sequence of relatively independent state changes, something which "lives its own life". It can be a ball, for example. It is very important to understand that a thread represents a "source of causality". In gaming, when you have anything where you need to model the
concept of free will, you need to implement it in a separate thread. An example would be an enemy of a player. Many enemies: could be one thread for all. It really depends an a number of factors.
[EDIT #2]
The second problem is performance and timing. If you have a real-time OS, you would have to guarantee too much of timing to comply with your timing scenario. Despite of suitability for
real-time strategy games, XNA is not a real-time OS. Therefore, you should not rely on performing all calculations between the frames, or even showing all frame in time. Timer approach is less reliable then threading in principle. Did you ever tried to take into account such situation: your handler called by a timer tick event is not completed execution when the next event is invoked?
The solution is using just a thread or using combined processing: the physics, scene data, and so one is recalculated in a periodic thread. To make the behavior of this data time-accurate, you will need to inquire the real time value from the OS. In this case, your algorithm is not so sensitive to the delays: for example, the position of a ball is calculated correctly even if it is performed in non-uniform moments of time; so the motion looks subjectively smooth…
I really feel that I'm going beyond the normal forum format. Again, discussion of all aspects is really not suitable for the
Quick Questions & Answers forum…
—SA
Submit an article or tip