3

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

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

谢谢你的时间！

4

2 回答 2

0

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

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

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

于 2011-08-12T00:20:09.787 回答
0

虽然这个问题是几年前的......

AFAIK，

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

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

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

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

于 2014-05-09T04:06:01.240 回答