延迟与deltaTime

Question

我是一名新手游戏开发者，我遇到了一个我正在努力解决的问题。我正在使用JAVA在Android游戏中工作。

案例是我在任何设备中使用deltaTime进行平滑移动等等，但我遇到了一个问题。在游戏的特定时刻，它实现了相当昂贵的操作，其增加了下一次迭代的deltaTime。有了这个，下一次迭代就会有所滞后，而旧的慢速设备可能会非常糟糕。

为了解决这个问题，我想在一个解决方案中，我想与大家分享一下，并就这可能发生的事情提供一些反馈。 algorythm如下：

1) Every iteration, the deltatime is added to an "average deltatime variable" which keeps an average of all the iterations

2) If in an iteration the deltaTime is at least twice the value of the "average variable", then I reasign its value to the average

有了这个，游戏将适应设备的实际性能，并且不会滞后于混合迭代。

你怎么看？我刚刚完成了，我想更多的人遇到了这个，还有另一种更好的解决方案......需要提示！感谢

Answer 1

有一种比存储平均值更简单，更准确的方法。我不相信你的建议会得到你想要的结果。

• 取自上一帧开始以来的总时间（包括分数） - 这是你的 三角洲时间。通常是几毫秒或几秒钟。
• 在申请之前将您的移动速度乘以增量时间 它。

这为您提供帧速率独立性。您需要进行试验，直到速度正确。

让我们考虑上面评论中的例子：

  

如果你有一帧需要1毫秒，而物体需要移动10个单位   每帧以每毫秒10个单位的速度移动。但是，如果   一帧占用10毫秒，你的物体减速到每毫秒1个单位。

• 在第一帧中，我们将速度（10）乘以1（增量时间）。这给了我们10的速度。
• 在第二帧中，我们的delta是10 - 帧慢十倍。如果我们将速度（10）乘以delta（10），我们得到100.这与物体在1ms帧中移动的速度相同。

我们现在在游戏中拥有一致的移动速度，无论屏幕更新频率如何。

修改：

回应您的意见。 更快的计算机就是答案;）没有简单的帧速率一致性解决方案，它可以通过各种方式表现出来 - 屏幕撕裂是最严峻的两难选择。

你在使用极度不一致的增量的帧中做什么？考虑优化该代码。以下操作可以真正杀死您的帧率：

• AI例程如Pathing
• 磁盘/网络访问等IO操作
• 程序资源的生成
• 物理<！/ LI>
• 其他任何不会呈现代码的内容......

这些都会导致增量增加X，具体取决于算法的顺序和正在处理的数据量。考虑在单独的线程中执行这些长时间运行的操作，并在它们准备就绪时执行/显示结果。

更多修改： 无论游戏规则如何，您在解决方案中实际执行的操作都会减慢所有内容，以避免屏幕位置跳跃。

考虑一个射手，反射就是一切，估计速度非常重要。如果帧速率加倍并且你将玩家的旋转速度减半会发生什么？现在，玩家的帧速率出现了飙升，他们的十字线移动速度比他们想象的要慢。更糟糕的是，因为您使用的是平均值，后续帧的移动速度会变慢。

对于一个缓慢的帧来说，这似乎是一个很好的效果。如果你有一个物理引擎，这个慢帧甚至可能对游戏世界产生非常实际的影响。

最后的想法：增量时间的想法是将游戏规则与您运行的硬件断开连接 - 您的解决方案重新连接它们