深入理解XNA的时间间隔

深入理解XNA 时间间隔模式：

    默认的情况下，XNA运行在固定时间间隔模式下，该模式下的目标帧频是60每秒。这满足了一般游戏的需要：

    1. Update函数会在一秒钟内被调用60次。
    2. Draw函数会在线程空闲时被调用。

    让我们看得更深入一些，时间循环的运行会有几种不同的情况。

    最简单的情况是游戏调用一次Update和Draw函数的时间刚好是1/60秒，在这种情况下，程序调用了Update，然后调用Draw，然后看一看时间发现应该调用下一次Update函数了，然后调用Draw，就这样重复。

    那么当Update和Draw函数需要少于1/60秒的时间会怎样呢？也很简单，调用Update，然后调用Draw，然后查看时间，等到时间到达该进行下一次Update的时候再进行一次调用。

    那么如果Update和Draw函数需要多于1/60秒的时间呢？这种情况下事情变得有一些复杂了。而该情况发生的原因有很多：

    1. 你的计算机的性能不足以用需求的帧频来运行这个程序，然而差得并不远。
    2. 你的计算机的性能相差需求很远。
    3. 计算机的性能能够满足运行游戏的基本需求，然而对于特定的帧而言，计算机需要用更长的时间来更新和绘制，可能这些帧中有大量的爆炸需要计算或绘制。
    4. 你可能在debugger过程中暂停了程序。

    对于以上情况引发的缓慢，XNAFramework会采取以下的手段来应对。

    1. 设置GameTime.IsRunningSlowly为true。
    2. 多次调用Update函数（而不调用Draw）直到赶上了正常的进度。
    3. 如果时间很紧急而我们被落下了很多，我们便放弃追赶。

    如果你考虑了这个方法具体是怎样解决以上列出的四个运行缓慢的原因的，你就会发现该方法对每一种情况都解决地很好：

    1. 即使是计算机有点慢以致不能在一帧中运行完Update和Draw函数，而以两次Update函数和一次Draw函数的调用作为两帧，游戏会显得有些迟缓，但依然会正确地运行。如果程序员能够聪明地检测到IsRunningSlowly的值为真，并降低游戏的细节的话，帧频又能提高。
    2. 如果计算机太慢，（例如Update函数都无法在一帧中运行完成）XNAFramework除了设置IsRunningSlowly并祈祷程序员注意到这一点之外，做不了别的事情。对于用户而言，但这种情况发生的时候，可能说明你需要一个更快的机器。
    3. 如果特殊的帧在偶然情况下花掉了过多的时间，XNAFramework自动地多次额外调用Update函数来追赶时间，追赶上之后游戏就恢复正常运行的状态了。用户可能会注意到一段短时的停滞，但我们已经将影响讲到了最低。
    4. 在debugger中中断了程序会让游戏比预期的循环时间落下很多，于是我们的方法会放弃追赶，接受遗失了不少时间的事实，然后在继续运行后重新平滑的运行。

    总结来说，你几乎不需要做额外的工作就可以享受固定时间间隔方式的好处。你只需要确定游戏所有的逻辑都在Update函数中，游戏就会以一个好的恒定的速率运行。

    作为程序的编写者，你可以在检测到IsRunningSlowly真的时侯自动地调节游戏的细节程度来是游戏更优秀。但对于绝大多数的游戏并不需要担心这一点。

    如果你在Update或者Draw函数中设置了断点，你可能会注意到Update函数比Draw函数调用的更多，这是因为断点使游戏尝试去追赶落下的时间。时间的调整过程反映了海森堡不确定法则：当实时系统的计时方法被改变时，结果也会较正常的情况发生改变。

    如果你希望将你的游戏运行在另一个帧频下，你可以改变TargetElapsedTime属性的值。我们选择60帧每秒作为默认值是因为它遵从标准的电视刷新率，但一些游戏可能希望减慢到30帧每秒。

    Game.IsFixedTimeStep = false

    如果你禁用了固定时间间隔模式，XNA并不会帮你做什么聪明的事，在这种模式下，我们的算法相当简单。

    1. Update
    2. Draw
    3. 等待，然后重复

    （实际上说得稍微有一点简化，但其中的细节并不重要）

    在这种模式下运行也有一些好处：

    1. 因为游戏并没有固定到任何更新频率，游戏就能够更好的匹配你的显示器的刷新率。对于FPS游戏来说，提供改变固定帧频或是匹配显示器的选项很重要。
    2. 这个模式在较慢的机器上会运行更高效。不再需要调用Update函数多次来追赶时间，而是在更大的时间间隔中进行循环。如果这个游戏被良好的编程，它也许能够比不停得追赶运行得更高效。

    非固定间隔模式不好的一面是使游戏变得更难编写。即使是像“加速移动到某地点”这样的简单运算都需要使用时间间隔作为参数， 不固定的时间间隔可能会要求你进行积分等计算。一些人可能长于计算，但我并不，而且我并不喜欢在仅仅只需要移动游戏中的一个物体的时间处理这样的事情。

    那么，那种方式更好呢？游戏程序员在时间诞生之初就在争论这个问题，而且可能到到宇宙大爆炸的时候他们还在争论。

    一条准则是这样的，控制台（指XBOX之类）程序员偏向固定时间间隔，而PC程序员通常考虑多种时间模式。有两个原因导致了这样的差异。

    1. 控制台通常连接到60hz的电视，而PC的显示器能够被设置为多种不同的刷新率。
    2. 控制台的速度通常是超前的。所以即使有时单帧花的时间比预期的长，但这样的情况在当前运行的控制台上通常并不会持续。相比而言，PC游戏需要支持更大范围的硬件，所以适配慢的的机器对PC游戏更加重要。

    但在这一点上并没有绝对的规则，我见过控制台上的游戏在不同的时间间隔模式下运行得很好，而我个人组装的一台PC机也能够很好的以60fps在固定时间间隔模式下运行。

 

 

-