multithreading - 关于游戏循环、滴答和实时编程的一些问题

Question

首先，我想为我的近似英语道歉，因为我是法国人。我目前正在使用 LWJGL 在 Java 中制作实时游戏。我有一些关于游戏循环的问题:

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

感谢您的宝贵时间!

Answer 1

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

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

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