关于游戏循环，刻度和实时编程的一些问题

Question

首先，我想为我的近似英语道歉，因为我是法国人。我目前正在使用LWJGL在java中进行实时游戏。 我对游戏循环有一些疑问：

• 我正在线程中运行渲染例程。这是个好主意吗？通常，渲染例程相当慢，并且不应该减慢世界更新（tick）例程，这更为重要。所以我想在这里使用一个线程似乎是一个好主意（减去使用线程的复杂性）。
• 在世界更新例程中，我正在使用当前时间更新实体列表。然后，每个实体可以计算自己的deltaTime，对应于它们上次更新的时间。这与通常的更新循环不同，后者使用相同的deltaTime更新列表中的每个实体。由于线程渲染，这似乎是合适的。这是个好主意吗？我应该使用第二种方法吗？如果是这样，还需要线程渲染吗？如果是，我是否必须添加最大deltaTime？
• 一般来说，最大化deltaTime是个好主意吗？

谢谢你的时间！

Answer 1

1. 这是个好主意吗？单独的线程是相当高级的东西，我认为没有理由开始多线程。到目前为止，我所使用的所有手机游戏都不需要多线程，即使它们是“实时”的。硬核PC和控制台游戏是多线程真正开始发挥作用的地方。如果感兴趣，请点击此处关于该主题的最新演讲的链接：http://archive.assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding。

2. 如果物理学不能一次性处理，这听起来会引起一些奇怪的事情。对此不确定。将已经更新的对象与另一个时间的对象碰撞到另一个位置，例如，纠正这种情况可能会成为问题？快速移动的碰撞可能需要细分，这可能就是为什么你有单独的更新线程，但为什么不将它们全部计算为同时发生？

3. '可变时间步长'和'固定时间步长'是可用于渲染的选项。目前大多数游戏似乎都选择了30 fps的固定时间步长。渲染必须保持在极限之下，因此不需要追赶。 变时间步的一个问题是您被迫将deltaTime传递给所有与时间相关的区域。固定的时间步长很方便，因为你可以假设你以30 fps的速度运行，并且在任何地方都使用该值。据我所知，目前这是一种首选方法。

Answer 2

虽然这个问题已经有几年了......

AFAIK，

渲染通常在分离的处理器 - GPU中完成，因此它们已经是一个独立的线程。但是，绘图命令必须在发送到GPU之前由图形驱动程序（在CPU中运行）处理，并且可以通过多线程保存此处理。无论如何，在这种情况下，您负责管理逻辑和呈现线程之间的同步。

一般来说，游戏都是关于对象之间的交互，并且将状态图划分为完全分离的部分非常困难。结果，整个游戏状态通常变成单个图形，并且该图形在渲染时不能被更新。在这种情况下，您可以通过多线程获益。

如果你可以保留一个单独的不可变数据进行渲染，那么你可以从分离的线程渲染中获得一些好处。但除此之外，我不推荐它。

此外，如果你真的想要一个实时游戏，你应该考虑GC。 GC相关的性能问题通常是制作实时内容的最大障碍。