【问题标题】:Libgdx game logic in Render?渲染中的Libgdx游戏逻辑?
【发布时间】:2013-01-09 22:24:29
【问题描述】:

我正在学习 Libgdx,并且有一些关于在渲染方法期间更新我的游戏逻辑的问题..

理想情况下,我希望将我的游戏逻辑和渲染分开。这样做的原因是,如果我在系统上具有高 FPS,我的游戏循环会“运行”得更快。

我正在寻找的是保持体验不变,并可能限制我的更新..如果有人能指出我关于如何做的教程 a)通过 DeltaTime 限制我的渲染更新 b)通过 Deltatime 限制我的游戏逻辑更新。

谢谢你:)

【问题讨论】:

标签: java libgdx


【解决方案1】:

在重新阅读您的问题后,我认为您缺少的技巧(基于您的评论,即在更高刷新率的系统上运行会导致您的游戏逻辑运行得更快),您实际上是根据传递给渲染的“增量”时间。 Andrei Bârsan 在上面提到了这一点,但我想我会详细说明一下如何使用 delta。

例如,在我的游戏的 render() 中,我首先调用我的 entityUpdate(delta),它更新和移动游戏中的所有对象,按时间“delta”移动的距离缩放(它不会渲染它们,只是移动它们的位置变量)。然后我调用 entityManageCollisions(delta),它解决了由更新引起的所有冲突,最后我调用 entityDraw(batch, delta),它使用 delta 获取精灵动画的正确帧,并实际在屏幕上绘制所有内容。

我使用实体/组件/系统模型的变体,因此我一般处理我的所有实体,而我上面提到的那些方法调用本质上是“系统”,它们作用于具有某些组件组合的实体。

所以,总而言之,将 delta(传递给 render() 的参数)传递到您的所有逻辑中,这样您就可以根据自最后一次通话。这要求您根据实体的单位/秒设置速度,因为您正在传递一个值来缩放它们,只需几分之一秒。一旦你这样做了几次,并试验了结果,你就会处于良好的状态。

另请注意:这将使您在交互式调试会话中发疯,因为自上次渲染调用以来,增量计时器一直在累积时间,导致您的实体飞过整个屏幕(甚至更远——为您测试这些边界!)因为它们通常会获得亚秒级的更新,但最终可能会超过 30 秒(或者无论您花多长时间查看单步调试器的内容),所以在我的渲染()的最顶部,我有一行写着 @ 987654321@(该数字是我的开发工作站的样本 detla,似乎给出了不错的结果——您可以通过在测试运行期间将其写入控制台来捕获视频系统的典型增量,并使用该值代替,如果你喜欢)我注释掉要部署的构建,但在调试时不要注释,所以每一帧都会使游戏向前移动一个一致的量,不管我在调试器中查看的时间有多长。

祝你好运!

【讨论】:

  • 不错的调试技巧(静态增量)
  • 在调试期间在渲染循环中设置增量是天才,我不知道为什么我没有想到它。
【解决方案2】:

到目前为止的答案不是使用并行线程 - 我自己过去也有过这个问题,但有人建议我不要这样做 - link。一个好主意是首先运行世界更新,然后如果帧中没有足够的时间来进行渲染,则跳过渲染。尽管如此,应该使用增量时间来保持一切顺利并防止滞后。

如果使用这种方法,明智的做法是防止发生超过 X 次连续跳帧,因为在(不太可能,但可能,取决于与渲染相比有多少更新逻辑)更新逻辑持续的情况下超过为一帧分配的总时间,这可能意味着您的渲染永远不会发生 - 这不是您想要的。通过限制您跳过的帧数,您可以确保更新可以顺利运行,但您也可以保证在有太多逻辑需要处理时游戏不会死机。

【讨论】:

  • 为什么你认为拥有并行线程是不可行的? render() 方法由图形模块调用,因此,拥有单独的线程将是有益的。
  • 老实说,我只是假设 libgdx 主要用于 Android 游戏。而且目前还没有那么多具有多核处理器的移动平台。
  • 不知道运行android的多核设备有多少,但听说android调度器不能高效处理多核。无论如何,我对将所有内容都进行渲染持怀疑态度。我可能必须自己测试它,什么是最好的。也许调度器变得更好了,你问的问题已经超过一年了。
  • 确实如此 - 尽管有文章(虽然也很旧)建议全部完成 in render(...),例如:koonsolo.com/news/dewitters-gameloop
  • 它在哪里说,你不应该使用单独的线程?
猜你喜欢
  • 2018-09-13
  • 1970-01-01
  • 2014-03-12
  • 1970-01-01
  • 2019-05-26
  • 1970-01-01
  • 1970-01-01
  • 2014-10-24
  • 2011-12-13
相关资源
最近更新 更多