用Fixed step还是variable step, XNA团队成员有如下解答
understanding-gametime https://blogs.msdn.microsoft.com/shawnhar/2007/07/25/understanding-gametime/
As a rule of thumb, console programmers prefer fixed timesteps, while PC programmers usually go for variable timing mode. There are two main reasons for this disparity:
Consoles are usually connected to a 60 hz television, while PC monitors can be set to many different refresh rates.
The speed of a console is known ahead of time, so while games must handle single frames that take longer than expected, it is unlikely they will be consistently too slow for the machine they are running on. PC games must support a wider range of hardware, so it is more important for them to cope well with way-too-slow machines.
主机程序员选择Fixed, PC程序员选择variable. 主机的性能是稳定的, 所以XNA默认是60帧; PC性能差异较大. 下面也说了, 并不绝对.
But there are no absolute rules. I’ve seen console games that worked well using variable timesteps, and I personally shipped a PC title that ran just fine with a 60 fps fixed timestep.
XNA defaults to fixed timestep mode because that is easier to program, but you are welcome to change this if you disagree with our choice.
Multiple Update Frequencies
不同的Component还可以用不同的Update rate
There is no law saying all parts of a game must update at the same frequency. For instance MotoGP combined three different update rates:
The main game logic ran at a fixed timestep 60 fps. This included input, sound, user interface logic, camera movement, rider animations, AI, and graphical effects.
The physics update ran at a fixed timestep 120 fps (we just called it twice in a row from our main Update method). This provided a more accurate simulation, which was important for simulating vehicles moving at extremely high speeds and right on the edge of loosing traction.
The network update ran at a fixed timestep anywhere between 4 and 30 fps, depending on how many players were in the game. The more players there were, the more data we had to send, so we adjusted by sending it less often to conserve bandwidth.
Running some parts of your update logic less often than others is a great way to make games more efficient. For instance pathfinding and AI often only need to be updated a couple of times a second. Once you have found a good path or made the decision to attack, you can follow that decision without having to repeat the entire original calculation on each update.
作者的另外一篇文章 Game timing in XNA Game Studio 2.0
https://blogs.msdn.microsoft.com/shawnhar/2007/11/23/game-timing-in-xna-game-studio-2-0/
讲了XNA 2.0与XNA 1.0用了不同的game loop策略, 值得一读
In 1.0, things worked like this:
- Call Update as many times as needed to catch up to the current time
- Call Draw repeatedly until it is time for the next Update
In 2.0, the Draw behavior has changed:
- Call Update as many times as needed to catch up to the current time
- Call Draw once
- Wait until it is time for the next Update
In other words, we no longer call Draw more than once without an Update in between. That was a pointless thing to do, as it would just render the exact same image a second time!
Here’s why the new behavior is an improvement:
- Consider a fixed timestep game running at 60 fps, with vsync enabled on a 75 hz monitor
- Update completes in, let’s say, 3 milliseconds
- Draw completes in, let’s say, 5 milliseconds
- This has taken 8 milliseconds total
- 60 fps is 16.7 milliseconds, so it is not yet time for another Update
- We call Draw again
- Because vsync is enabled, the graphics driver waits 13 milliseconds for the next 75 hz retrace
- Yikes! By the time this returns, we have taken 21 milliseconds in total, so we are late for the next Update
In practice the effects of this were very minor, because the next Update would quickly catch up to the correct time, but it caused some unnecessary jitter in the rate of calls to Update.
In 2.0, we call Update at more precisely controlled times:
- Update completes in 3 milliseconds
- Draw completes in 5 milliseconds
- There are 8.7 milliseconds left over, so we wait exactly that long
- Rinse, lather, repeat
作者还有其他很多可以学习的文章.
另外以下关于GameLoop的4篇系列文章也值得一读
4 - The Game Loop http://rbwhitaker.wikidot.com/the-game-loop
5 - GameTime: A Game’s Heart Beat http://rbwhitaker.wikidot.com/gametime
6 - Time Steps http://rbwhitaker.wikidot.com/time-steps
7 - Cracking the Game Time Problem http://rbwhitaker.wikidot.com/cracking-the-game-time-problem