nae*_*n84 9 c++ java android opengl-es android-ndk
我知道以前曾问过类似的问题,但......
我们希望开发(至少希望)一个独立游戏,但仍然是一个高质量图形的游戏,如果不是屏幕上移动对象的数百个,那么我们期望非常多的多边形和对hittest和可能一些AI的要求.
我知道java的基本问题是垃圾收集.但这不是问题,我们计划在游戏开始之前分配所有必需的内存,对于瞬态对象,我们将使用池(因此在游戏循环中,永远不会写入新关键字).我们计划使用这里提到的所有技术(Google I/O 2009 - 为Android编写实时游戏).
我们坚持使用Java的主要原因是部署,我们只想为Android开发(至少现在)
因此,使用Java可以获得游戏中相同的性能(即使这意味着丑陋/非惯用代码),就好像我们使用c ++一样.如果没有,具体是什么？或者,如果可能但非常非常不实用,这些原因是什么？
(例如我读过一些关于java Buffers和OpenGL的东西不是最好的配对但是不记得细节 - 也许是一些专家)
fad*_*den 10
您将为每次调用支付固定的额外费用,以便从Java源代码中使用OpenGL.Android提供围绕调用的Java语言包装器.例如,如果调用glDrawArrays,则调用GLES20.java中声明的本机方法,该方法在android_opengl_GLES20.cpp中定义.您可以从代码中看到它只是以最小的开销转发呼叫.
在文件中查找,您可以看到执行其他检查的其他调用,因此稍微贵一些.
就不可避免的成本而言,最重要的是,使用Java源进行大量GLES调用的价格高于本地源.(在查看带有systrace的Android Breakout的性能时,我注意到驱动程序中有很多CPU开销,因为我正在进行大量冗余状态更新.从本机代码执行此操作的成本会降低,但是零工作的成本低于做少工作的成本.)
更深层次的问题与您是否需要以不同方式编写代码(例如,避免分配)有关,而您无法获得相同级别的性能.您必须使用直接ByteBuffer对象而不是简单数组,这可能需要您进行更多管理.但是除了Android上计算密集型本机代码和Java代码之间当前的速度差异,我不知道从根本上阻止严格Java实现的良好性能的任何事情.
| 归档时间： |
|
| 查看次数： |
6145 次 |
| 最近记录： |