关于游戏循环、tick和实时编程的一些问题
首先，我想为我的英语水平道歉，因为我是法国人。我目前正在使用 LWJGL 用 java 制作实时游戏。 我有一些关于游戏循环的问题：
- 我正在线程中运行渲染例程。这是个好主意吗？通常，渲染例程相当慢，并且不应该减慢更重要的世界更新（滴答）例程。所以我想在这里使用线程似乎是一个好主意（减去使用线程的复杂性）。
- 在世界更新例程中，我正在用当前时间更新实体列表。然后，每个实体可以计算自己的 deltaTime，对应于它们上次更新的时间。这与通常的更新循环不同，后者使用相同的 deltaTime 更新列表中的每个实体。由于线程渲染，这似乎是合适的。这是个好主意吗？我应该使用第二种方法吗？如果是这样，还需要线程渲染吗？如果是这样，我是否必须添加最大 deltaTime？
- 一般来说，设置最大 deltaTime 是一个好主意吗？
感谢您抽出时间！
First I want to apologize for my approximate English, as I'm French. I'm currently making a real-time game in java, using LWJGL.
I have some questions regarding game loops:
- I'm running the rendering routine in a thread. Is it a good idea? Usually, the rendering routine is fairly slow and should not slow down the world update (tick) routine, which is way more important. So I guess using a thread here seems like a good idea (minus the complications from using a thread).
- In the world update routine, I'm updating a list of entities with the current time. Each entity can then compute their own deltaTime, corresponding to the last time they were updated. This differs from the usual update loop, which updates every entity in the list with the same deltaTime. This seemed appropriate because of the threaded rendering. Is it a good idea? Should I use the second method instead? If so, is the threaded rendering still needed? If so, do I have to add a maximum deltaTime?
- In general, is it a good idea to have a maximum deltaTime?
Thanks for your time!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是个好主意吗？单独的线程是相当高级的东西，我认为没有理由一开始就进行多线程。到目前为止，我开发的所有手机游戏都不需要多线程，尽管它们是“实时”的。硬核 PC 和主机游戏是多线程真正开始发挥作用的地方。如果有兴趣，这里是最近关于该主题的演讲的链接：http ://archive. assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding。
听起来如果不一次性处理物理问题可能会导致一些奇怪的事情。对此不太确定。例如，已经更新到另一个位置的对象与另一个时间出现的对象发生碰撞，纠正这种情况可能会出现问题？快速移动的碰撞可能需要细分，这可能就是为什么你有单独的更新线程，但为什么不让它们全部计算为同时发生呢？
“可变时间步长”和“固定时间步长”是可用于渲染的选项。目前大多数游戏似乎都选择 30 fps 固定时间步长。渲染必须保持在限制范围内，因此不需要赶上。
可变时间步长的一个问题是您被迫将 deltaTime 传递到所有与时间相关的区域。固定时间步长很方便，因为您可以假设您以 30 fps 的速度运行，并在任何地方使用该值。据我所知，这是目前的首选方法。
Is it a good idea? Separate threads are fairly advanced stuff, I see no reason to do multithreading to begin with. All the mobile games I have worked on so far have not needed multiple threads, even though they are 'real-time'. Hardcore PC and console games are where multithreading really starts to come into play. Here is a link to a recent talk on the subject if interested : http://archive.assembly.org/2011/seminars/adventures-in-multithreaded-gameplay-coding.
Sounds like this could cause some strange things if the physics are not handled in one go. Not sure about this. Colliding an object that has already been updated to another position with an object that comes another time, for example, correcting this sort of situation may become problematic? Fast moving collisions may need to be subdivided, which may be why you have the separate update thread, but why not have them all calculated as happening at the same time?
'Variable timestep' and 'Fixed timestep' are the options available for rendering. Most games at the moment seem to choose a 30 fps fixed timestep. The rendering has to be kept under the limits so no catching up should be needed.
One problem with variable timestep is you are forced to pass deltaTime to all time-dependent areas. Fixed timestep is handy as you can assume you are running at say 30 fps, and use that value everywhere. It is a preferred method at the moment as far as I know.
虽然这个问题已经有几年了……
据我所知，
渲染通常是在单独的处理器——GPU 中完成的，所以它们已经是一个单独的线程了。但是，绘图命令在分派到 GPU 之前必须由图形驱动程序（在 CPU 中运行）处理，并且可以通过多线程来节省此处理。无论如何，在这种情况下，您负责管理逻辑和渲染线程之间的同步。
一般来说，游戏都是关于对象之间的交互，并且很难将状态图划分为完全独立的部分。结果，整个游戏状态通常变成单个图，并且该图在渲染时无法更新。在这种情况下，多线程并没有任何好处。
如果您可以保留单独的不可变数据进行渲染，那么您可能会从在单独的线程中渲染中获得一些好处。但除此之外，我不推荐它。
另外，如果你真的想要一个实时游戏，你应该考虑GC。 GC 相关的性能问题通常是制作实时内容的最大障碍。
Though this question is a few years old…
AFAIK,
Rendering is usually done in separated processor — GPU, so they're already a separated thread. But, drawing command must be processed by graphics driver (which is running in CPU) before dispatched to GPU, and this processing may be saved by being multi-threaded. Anyway in this case, you're responsible to manage synchronization between logics and rendering thread.
Generally speaking, games are all about interactions between objects, and it's very hard to divide state-graph into fully separated divisions. As a result, whole game state usually becomes single graph, and this graph cannot be updated while being rendered. In this case, you have no benefit by being multi-threaded.
If you can keep a separated immutable data for rendering, than you may gain some benefit from rendering in separated thread. But otherwise, I don't recommend it.
In addition, you should consider GC if you truly want a realtime game. GC related performance issues usually the biggest obstacles to make realtime stuffs.