Multithreading 关于游戏循环、勾号和实时编程的一些问题

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

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

谢谢你的时间

这是个好主意吗？独立线程是相当高级的东西，我认为没有理由一开始就使用多线程。到目前为止，我开发的所有手机游戏都不需要多线程，即使它们是“实时”的。硬核PC和控制台游戏是多线程真正开始发挥作用的地方。如果有兴趣，这里有一个最近关于这个主题的演讲的链接：

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

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

---

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

阿福

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

一般来说，游戏都是关于对象之间的交互，很难将状态图划分为完全分开的分区。因此，整个游戏状态通常变成单个图形，并且在渲染时无法更新该图形。在这种情况下，多线程对您没有好处

若您可以为渲染保留一个分离的不可变数据，那个么您可能会从在分离线程中渲染中获得一些好处。但除此之外，我不推荐它

---

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

如果不保持时间步长正确，您将获得随帧速率变化的物理效果。