实现用户输入和处理器速度在游戏进行时间内的去耦。
(摘自《游戏编程模式》 )
游戏作为实时交互软件，实时是其核心。 在某些程序中，这样的代码总是在软件的运行周期中重复，监听用户的输入，并根据输入进行对应，这就是游戏的循环代码。 应该注意的是，游戏循环中不会发生类似于UI事件循环的块。 即使不输入，游戏也在运行游戏循环。
试着将游戏逻辑简化为输入处理ProcessInput ()、逻辑更新LogicUpdate ()、画面渲染Render ()、物理更新PhysicUpdate () )这三个部分，实际上有很多模块的循环最简单的游戏循环代码如下。
wile(true ) { ProcessInput ) (逻辑更新)； 物理更新(； Render (； }如果是单机游戏，在指定的设备上玩的话，这种游戏周期的写法可能没什么问题。 但是，当今游戏的运行设备、平台很多，运行效率因性能而异。 在编写游戏循环代码时，必须考虑此游戏在低性能和高性能机器上有什么区别，以及这些区别会引起什么问题。 接下来逐一讨论。
以前的术语：帧速率(fps )这是一个频率单位，例如对于屏幕，fps表示屏幕每秒刷新几次。 对于游戏周期来说，fps是一秒钟运行几次游戏周期。
性能要求游戏周期是整个游戏的根基部分。 因为程序的大部分时间都在运行游戏周期中的内容，所以需要优化游戏周期中调用的函数。
循环游戏看我们上面最简单的游戏代码，能发现那个问题吗？ 对每个设备执行上述代码会不一致。 对于性能良好的计算机，请每秒多次(例如100次)快速运行三个函数。 性能稍差的机器，一秒钟只能工作五次。 这是游戏不能接受的。 这不会同步游戏对象由不同硬件表示的游戏状态。 (高性能电脑游戏进行得更快； 低端计算机游戏进行得很慢)。
方案1 )基于时间差的状态更新使游戏状态同步，将自上次更新起的时间传递给状态更新函数，使游戏状态更新函数能够根据该差分计算并更新游戏状态。 这样创建的游戏周期在每个设备上以不同的时间差进行更新，以确保状态的一致性。
双光栅时间=time.time； wile (真) { double current=Time.time； doubledeltatime=current-lasted time； 逻辑更新(delta time； 物理更新(delta time； Render (； lastedTime=current； 但是，这种方法也有缺陷。 就缺陷进行分析吧。
对于高性能计算机。 FPS高，更新次数多。 另一方面，游戏中的数据计算被认为浮点数多，计算次数多则误差变大，两者的最后状态不一致。 为了提高性能，将对游戏的物理引擎进行减少运算。 此归约运算经过仔细安排，以便在一定时间内进行，而不是随时调用进行计算。 然而，在不同的设备中，该方案与PhysicUpdate的调用频率不匹配，这对于物理引擎来说无疑是灾难性的(因为如果两者错位，物理引擎模块可能会丢失几帧的计算)。 方案二：既然一定的状态更新保证不同设备上的状态更新次数一致。 必须限制对状态更新相关函数的调用，以确保在任何计算机运行时调用更新函数的频率一致。 也就是说，是一定的FPS。 代码如下。
双时间标记=time.time； double ms _ update _ interval=1000/60； 双精度加速=0； wile (真) { double current=Time.time； doubledeltatime=current-time tag； 时间标记=current； 加速=delta time； if (accumulation ms _ update _ interval )逻辑更新(ms _ update _ interval )； 物理更新(ms _ update _ interval； 加速=0； (} Render )； } MS_UPDATE_INTERVAL值的设定有一定的讲究。 首先，该值优选为1000 /60 ms (1 (小于1 (1秒内刷新次数为60次以上)，如果刷新频率过低，则成为画面跳帧原因； 然后，MS_UPDATE_INTERVAL设置为大于更新处理的时间——。 更新完成后，需要准备进入下一个更新。
渲染和更新不同步的问题可以优化的问题是什么？ 从上面的代码可以看到，Render (代码中没有固定的更新步骤。 这意味着更新状态和渲染屏幕不是同一时间，因此下图中的更新顺序会导致一些问题。 如果一个渲染命令位于两次更新之间，则即使状态前后更新了两次，渲染也只会执行一次。 其结果是，下次更新时游戏状态的变化幅度过大，发生帧跳跃。
我以前考虑过更新。 可以将时间差传递给渲染引擎，以了解渲染引擎应该渲染的程度。
渲染(accumulation/ms _ update _ interval； 控制游戏循环方式的选择基于平台的事件循环。 我们不要花太多时间写游戏循环的核心代码。 平台开发得很好，失去了对时间的控制。 而且很多平台的事件周期并不像想象的那么敏捷。 跨平台现成游戏引擎的游戏循环利用现成稳定的游戏循环无法获得时间的控制。 自定义选项完全依赖于引擎的现有实现。 要自己编写游戏周期，必须自己编写所有代码。 需要自己实现平台的接口。 https://blog.csdn.net/QQ _ 38134452/article/details/8873879 SPM=1001.2014.3001.5501