android - 奇怪的 "stutter"在不同的 android 设备上的 box2D

Question

我正在用 C++ 同时开发一个引擎和一个游戏，我使用 box2D 作为物理后端。我正在不同的 Android 设备上进行测试，并且在 3 台设备中的 2 台上进行测试，游戏运行良好，物理效果也是如此。但是，在我的 galaxy tab 10.1 上，我偶尔会遇到一种“口吃”。这是一个 youtube 视频演示:

http://www.youtube.com/watch?v=DSbd8vX9FC0

游戏运行的第一台设备是 Xperia Play...第二台设备是 Galaxy Tab 10.1。不用说 Galaxy 选项卡的硬件比 Xperia Play 好得多，但 Box2D 在随机时间间隔内随机滞后。两台机器的代码完全相同。此外，引擎/游戏的其余部分实际上并不滞后。在整个过程中，它以稳定的 60 fps 运行。所以这种“卡顿”似乎是实际从 box2D 读取值时的某种延迟或故障。

您看到移动的 Sprite 在渲染时检查它们是否有附加的物理 body ，并根据物理 body 的世​​界位置设置它们的位置值。所以在这个特定的过程中，box2D 似乎与应用程序的其余部分不同步。很奇怪。我意识到这是一个远景，但我想无论如何我都会把它贴在这里看看是否有人有想法......因为我完全被难住了。感谢您提前输入!

哦，附​​言我使用的是固定时间步长，因为这似乎是针对此类事情最常建议的解决方案。在我的桌面上开发这个时，我移动到一个固定的时间步骤，我遇到了一个更严重的类似问题，固定的步骤是解决方案。另外就像我说的那样，游戏以 60 fps 的速度稳定运行，这是由低延迟计时器控制的，所以我怀疑简单的延迟是问题所在。再次感谢!

Answer 1

正如我在这里的评论中提到的，这归结为计时器解析问题。我正在使用一个定时器类，它应该访问最高分辨率的系统定时器，跨平台。一切都很好，除了在 Android 上，有些版本有效，有些版本无效。 galaxy tab 10.1 就是这样一个例子。

我最终重写了我的 getSystemTime() 方法，以使用 C++11 的新添加项 std::chrono::high_resolution_clock。这也很好用(除了 Android 之外的任何地方)...除了它还没有在任何 NDK for android 中实现。它应该在 crystax NDK R7 的第 5 版中实现，在撰写本文时已完成 80%。

我对访问系统时间的各种方法或我可以在 NDK 端建立可靠计时器的方法进行了一些研究，但归根结底是并非所有平台都支持这些不同的方法。我经历了从头开始编写自己的引擎的痛苦过程，只是为了支持每个版本的 android，所以押注于实现不一致的方法是荒谬的。

在我看来，对于任何面临此问题的人来说，唯一明智的解决方案是简单地放弃在 NDK 端实现此类代码的想法。我将改为在 Java 端执行此操作，因为到目前为止，在我所有的测试中，这在我测试过的所有设备上都足够可靠。更多相关信息:

http://www.codeproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7

更新
我现在已经实现了我提出的解决方案，在 Java 端进行计时并且它已经奏效。我还发现，在 NDK 端处理任何相对较大的数字，无论数据类型如何(数字，例如调用单调时钟的纳秒数)也会导致某些版本的 android 严重滞后。因此，我通过传递一个指向系统时间的指针来尽可能地优化它，以确保我们不会按拷贝传递。

还有最后一件事，我关于从 NDK 端调用单调时钟不可靠的说法似乎是错误的。来自 System.nanoTime() 上的 Android 扩展坞,

...and System.nanoTime(). This clock is guaranteed to be monotonic,and is the recommended basis for the general purpose interval timingof user interface events, performance measurements, and anything elsethat does not need to measure elapsed time during device sleep.

所以看起来，如果这是可信的，那么调用时钟是可靠的，但如前所述，还会出现其他问题，例如处理分配和转储所产生的大量数字，这几乎将我的帧率减半在 Android 3.2 的 Galaxy Tab 10.1 上。 最终结论: 平等地支持所有 android 设备要么该死的接近要么完全不可能，使用 native 代码似乎会使情况变得更糟。