奇怪＆QUOT;口吃＆QUOT;在不同的Android设备的Box2D [英] Strange "stutter" in box2D on different android devices
问题描述
我开发的同时在C ++中引擎和游戏，我使用的Box2D的物理后端。我测试在不同的Android设备，并于2出3个设备，游戏正常运行等方面做了物理。然而，在我的Galaxy Tab 10.1，我偶尔得到一种口吃的。这里是一个YouTube视频片段：
I'm developing an engine and a game at the same time in C++ and I'm using box2D for the physics back end. I'm testing on different android devices and on 2 out of 3 devices, the game runs fine and so do the physics. However, on my galaxy tab 10.1 I'm sporadically getting a sort of "stutter". Here is a youtube video demonstrating:
http://www.youtube.com/watch?v=DSbd8vX9FC0
游戏上运行的第一个设备是Xperia播放...第二个设备是Galaxy Tab的10.1。不用说，Galaxy Tab的具有比Xperia PLAY的更好的硬件，但Box2D的滞后在随机时间间隔的时间随机长度。在$ C $下两台机器是完全一样的。此外，发动机/游戏的其余部分实际上没有滞后。整个时间，它在固体60帧每秒。因此，这种口吃，似乎是某种形式在实际上是从Box2D的读值延误或毛刺。
The first device the game is running on is an Xperia Play... the second device is a Galaxy Tab 10.1. Needless to say the Galaxy tab has much better hardware than the Xperia Play, yet Box2D is lagging at random intervals for random lengths of time. The code for both machines is exactly the same. Also, the rest of the engine/game is not actually lagging. The entire time, it's running at solid 60 fps. So this "stuttering" seems to be some kind of delay or glitch in actually reading values from box2D.
您看到移动的检查，看他们是否有一个附加的身体在渲染时并根据身体的世界上的地位设置它们的位置值的精灵。因此它似乎是在这个特定的过程，Box2D的似乎是不同步的与应用程序的其余部分。很奇怪。我知道这是一个长镜头，但我想我会张贴在这里反正，看是否有人有想法......因为我完全难住了。感谢提前任何输入！
The sprites you see moving check to see if they have an attached physical body at render time and set their positional values based on the world position of the physical body. So it seems to be in this specific process that box2D is seemingly out of sync with the rest of the application. Quite odd. I realize it's a long shot but I figured I'd post it here anyway to see if anyone had ideas... since I'm totally stumped. Thanks for any input in advance!
呵呵，附：我使用的是固定时间的步骤，因为这似乎是对这样的事情是最常见的建议的解决方案。我搬到了一个固定的时间步长，而我的桌面上开发这个，我遇到了一个类似的问题只是更严重的和固定的步骤是解决方案。也就像我说的游戏在60 fps的，它是由一个低延时定时器控制，运行稳定，所以我怀疑简单滞后的问题。再次感谢！
Oh, P.S. I am using a fixed time step since that seems to be the most commonly suggested solution for things like this. I moved to a fixed time step while developing this on my desktop, I ran into a similar issue just more severe and the fixed step was the solution. Also like I said the game is running steady at 60 fps, which is controlled by a low latency timer so I doubt simple lag is the issue. Thanks again!
推荐答案
正如我所提到的意见在这里，这归结为是一个计时器的分辨率问题。我用这是要访问的最高分辨率系统计时器，跨平台的定时器类。一切伟大的工作，除了当它来到的Android，某些版本的工作，一些版本中，它没有。 Galaxy Tab的10.1是这样的一个情况下。
As I mentioned in the comments here, this came down to being a timer resolution issue. I was using a timer class which was supposed to access the highest resolution system timer, cross platform. Everything worked great, except when it came to Android, some versions worked and some versions it did not. The galaxy tab 10.1 was one such case.
我结束了重新写我的 GETSYSTEMTIME（）的方法来使用一个新的除了C ++ 11名为的std ::时辰:: high_resolution_clock 。这也很好工作（无处不在而Android）...但它尚未在任何NDK为Android来实现。它应该是在crystax NDK R7，这在这篇文章的时候是80％，完成第5版实现的。
I ended up re-writing my getSystemTime() method to use a new addition to C++11 called std::chrono::high_resolution_clock. This also worked great (everywhere but Android)... except it has yet to be implemented in any NDK for android. It is supposed to be implemented in version 5 of the crystax NDK R7, which at the time of this post is 80% complete.
我做了一些研究，访问系统时间或东西由我基地可靠的计时器上的NDK侧的各种方法，但它归结为是，这些不同的方法并不支持所有的平台。我已经经历写我自己的引擎从头开始只是这样我就可以支持所有Android版本，因此投注上都不一致实现的方法的痛苦过程又是荒谬的。
I did some research into various methods of accessing the system time or something by which I could base a reliable timer on the NDK side, but what it comes down to is that these various methods are not supported on all platforms. I've went through the painful process of writing my own engine from scratch simply so that I could support every version of android, so betting on methods that are inconsistently implemented is nonsensical.
的人面临这个问题的唯一明智的解决方案，在我看来，是简单地放弃对NDK方实施此类code的想法。我要做到这一点在Java，而不是结束，因为迄今为止，所有的考试，这已经足够可靠的跨越，我已经测试过的所有设备。更多关于这里：
The only sensible solution for anyone facing this problem, in my opinion, is to simply abandon the idea of implementing such code on the NDK side. I'm going to do this on the Java end instead, since thus far in all my tests this has been sufficiently reliable across all devices that I've tested on. More on that here:
<一个href="http://www.$c$cproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7" rel="nofollow">http://www.$c$cproject.com/Articles/189515/Androng-a-Pong-clone-for-Android#Gettinghigh-resolutiontimingfromAndroid7
更新
我现在已经实现我提出的解决方案，做到定时在Java端，它已经奏效。我还发现，在处理任何比较大的数量，而不管数据类型（数字如调用单调时钟纳秒）在NDK侧也导致在某些版本的Android的严重滞后。因此我已经优化了这项尽可能通过传递一个指针，系统时间，以确保我们不及格，被拷贝。
Update
I have now implemented my proposed solution, to do timing on the java side and it has worked. I also discovered that handling any relatively large number, regardless of data type (a number such as the nano seconds from calling the monotonic clock) in the NDK side also results in serious lagging on some versions of android. As such I've optimized this as much as possible by passing around a pointer to the system time, to ensure we're not passing-by-copy.
最后一件事也是如此，我的声明，呼吁从NDK侧单调时钟是不可靠的。然而，这似乎假。从上 System.nanoTime了Android码头（），
One last thing too, my statement that calling the monotonic clock from the NDK side is unreliable is however, it would seem, false. From the Android docks on System.nanoTime(),
...和System.nanoTime（）。这个时钟是保证是单调的， 并且是通用的时间间隔定时推荐的基础 用户界面的事件，性能测试，和其他任何 这并不需要在设备的睡眠以测量经过时间。
...and System.nanoTime(). This clock is guaranteed to be monotonic, and is the recommended basis for the general purpose interval timing of user interface events, performance measurements, and anything else that does not need to measure elapsed time during device sleep.
所以它似乎，如果这是可以信任的，在调用时钟是可靠的，但提到有一些再出现其他的问题，如处理分配和倾销数量庞大导致仅此一项几乎把我的帧率一半上的Galaxy Tab 10.1采用Android 3.2。 终极结论： 支持所有Android设备同样可以是该死的接近或平出不可能的，使用本机code似乎使情况变得更糟的
So it would seem, if this can be trusted, that calling the clock is reliable, but as mentioned there are other issues that then arise, like handling allocating and dumping the massive number that results which alone nearly cut my framerate in half on the Galaxy Tab 10.1 with Android 3.2. Ultimate conclusion: supporting all android devices equally is either damn near or flat out impossible and using native code seems to make it worse.
这篇关于奇怪＆QUOT;口吃＆QUOT;在不同的Android设备的Box2D的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
