2D物理游戏性能问题(android中的libgdx box2d)

时间:2017-02-20 13:55:25

标签: java android performance libgdx box2d

我正在制作一款2D汽车游戏,就像赚到2级。我几乎完成了它。唯一的问题是物理引擎的性能。我使用box2d,有10米长的边缘形状,完全建立100公里的地形。 1辆车,通常30-40箱。活动动态机构的数量大约是60-100,最大120.游戏流畅地在桌面上工作但在android fps中当活动体超过60时降到30以下。汽车和盒子之间以及盒子和盒子之间都有碰撞到地面。

我使用的是libgdx framework 1.9.4作为版本,java是1.7,用eclipse neon编写,windows 7。

这就是我计算世界活跃身体的方式

    int num=0;
    Array<Body> bodies=new Array<>();
    world.getBodies(bodies);
    for(Body b:bodies){
        if(b.isActive())num++;
    }

活跃的动态身体通常在100左右

这不是一个绘图问题,所有的地形和地下网格和汽车和盒子花费6-7毫秒秒我测量它们当box2d调试渲染关闭和世界步骤方法调用成本约30毫秒,当有大约30盒当汽车撞到它们时

我没有加载所有游戏对象(现在是方框)我将整个地图分成块,地图大小为100公里,当汽车在接下来的50米(大块区域)时,大小为50米我从一个准备好的池中加载框(这些对象的box2d世界表示也被合并,当框在池中时,我使用setActive(false)停用它们的box2d体,并在加载块时返回true)

我也将这个块系统应用于地形。我在加载游戏时加载所有地形,然后通过使用此方法设置setActive(false)来停用它们,并且当汽车继续通过地图时,如果块范围包括car&#s; sx轴坐标我激活下一个包含的块地形静体有大约20个大小为10米的固定装置,使得大小总共200米。

here an ss of the part of map to visualize my performance optimizing plan :)

绿色线条是活动的地形形状,因为在距离停用后左右看到地图结束时此部分距地图的中心100公里地图约60公里。

当车辆移动时,如果它们距离车辆20米处,那么新的箱子将在前方装载,而旧的箱子将被收集起来。

我的问题是

1)这个fps(20 fps)是正常的还是预期的?(android 7这是手机规格http://www.androidpolice.com/2016/02/23/the-general-mobile-gm-5-plus-is-the-most-powerful-android-one-device-yet/

2)100公里地形是否有问题,如果是这样我应该如何管理?

- &gt;我尝试在屏幕矩形外面激活/停用地形体。

- &gt;我在单个机身上尝试了数百个灯具,或者每个地形都是分离的机身,但最好的表现是我将100公里的地形分成200米的块,每个块都是一个机身,由大约20个灯具组成。 / p>

3)模拟100个具有巨大边缘形状地形的动态物体是完全不可能的? (但是在赚钱的时候他们做到了)

4)我应该为这种游戏(一个简单的特定游戏)编写我自己的简单物理学吗?

5)我应该使用子弹物理而不是box2d用于2D目的吗?可能吗?我会遇到性能问题吗?

如果您需要任何代码请注释,我会添加。

如果你有什么建议改变box2D的话,有什么真正快速的物理引擎我无法在网上找到吗?

值得注意的是:

我用恒定时间步模拟了box2d我尝试了1/60 1/45 1/30和8-3,6- 2作为迭代步骤。

对于所有物体,我使用高阻尼值,如.9,线性和角度。

我也想将这些盒子拆分成实际上我正在做的但是当汽车被击碎时没有分裂下摆我正在经历这个fps下降所以我暂时禁用它。

在地图的任何地方,只有关节是车轮关节,用于车轮,不再有关节。

尺寸是现实的,那些箱子高1.2米。

用于盒子和汽车用于所用地形边缘形状的多边形形状(链形)

速度阈值在世界设置中默认为1。

如果有任何笔记我忘了请评论,我会分享。

谢谢。

1 个答案:

答案 0 :(得分:1)

免责声明: 我无法回答您的所有问题,以下只是我的猜测。

几年前,我用Java + box2d + plain Opengl(LWJGL)开发了一个游戏原型和游戏库。

我认为你正面临着一些我遇到的问题。

然而,由于经验不足,我可能错了。
如果专家(读者)认为我的帖子中有任何错误,请在下面评论,我会解决它。

我的猜测

Java很慢/不太适合游戏。

免责声明:关于此,有很多争论 我不是一个专家,在这里发表一个坚实的声明,但我看到很多我的游戏原型在C ++中的运行速度比Java快3到10倍。 (使用不那么不同的算法)

内存碎片

您可能已经知道,即使您使用游泳池,与C ++相比仍然很差 你把盒子集中在一起,但是你不能把所有东西都汇集起来,例如:游戏逻辑数据结构,vector2D,普通数组(通常是new []),你使用的一些库中的一些恐怖算法。

停用的主体仍会耗费内存(间接加剧内存碎片)。

你有很多静态物体/静态物体的高复杂性。

你没有提到你有多少静止的身体,以及它们是什么 您是否在地形中使用了大量的顶点形状?
像Box2D和Bullet这样的流行物理引擎在凸起的形状下很酷,并且在原始形状方面很专业,但是在凹形(例如你的土地)中往往效果不佳

你的形状不断相互碰撞。

例如,100个盒子的堆叠比围绕场景散布的100个盒子花费更多的计算。

太大的世界

据我所知,box2d将场景(世界)划分为网格。如果你的世界非常大,但很多身体集群进入同一格的网格,Box2D的工作效果会相对较差。

不限于Box2D Bullet和Ogre3D - 在某些配置中 - 也遇到了这个问题。

回答(再次猜测)

  

1)这个fps(20 fps)是否正常且预期?

我不了解moblie,但您的代码仍然可以在某些方面进行优化。 (见下文)

  

2)100公里地形是否有问题,如果是这样我应该如何管理?

未聚焦的块 - &gt;移除身体(不只是停用它)。

是的,说起来容易做起来难,你可能只是在块附近停用,但删除(删除)远处的块中的所有物体(> 3块距离,可能是)。

如果删除的块可以返回到场景,则可能必须找到将其保存在某处的方法。 (例如,只保存身体,体型,体重的位置)

  

3)模拟100个具有巨大边缘形状地形的动态物体是完全不可能的? (但是在赚钱的时候他们做到了)

他们做了,或者你只是认为他们做了? 在某些方面,编程是一门艺术 你看到的东西可能与实际实施方式有很大的不同 你的瓶颈可能只是地形 - 降低其细节水平也可能有所帮助。

  

4)我应该为这种游戏(一个简单的特定游戏)编写我自己的简单物理学吗?

不,除非你想学习&amp;&amp;有很多时间&amp;&amp;真的很喜欢数学。

  

5)我应该使用子弹物理而不是box2d用于2D目的吗?可能吗?我会遇到性能问题吗?

我认为你还会在某种程度上面对 Box2D和Bullet的约束是昂贵的 你确定你真的需要约束吗? 在某些情况下,可以通过游戏的复合形状/修改设计来避免一点。

我认为如果你改用C ++和Bullet,你将获得至少3倍的性能,但我根本不确定