Android sólo juego en OpenGL: rendimiento en C ++ (NDK) vs Java (Dalvik)

Sé que se han hecho preguntas similares antes, pero …

Queremos desarrollar (al menos esperar) un juego indie pero aún así un juego con gráficos de alta calidad con cientos si no miles de objetos en movimiento en la pantalla por lo que esperamos un número muy alto de polígonos y requisitos para hittest y quizás algunos AI.

Sé que el problema básico con java es la recolección de basura. Pero no es un problema, planeamos asignar toda la memoria necesaria antes de que comience el juego y para los objetos transitorios usaremos el pooling (por lo que en el bucle del juego nunca se escribirá la nueva palabra clave). Y planeamos utilizar todas las técnicas posibles mencionadas aquí ( Google I / O 2009 – Escribir juegos en tiempo real para Android ).

La principal razón por la que insistimos en Java es el despliegue y sólo queremos desarrollar para Android (por ahora al menos)

Así que se puede lograr el mismo rendimiento en un juego con Java (incluso si eso significa feo / no código idiomático) como si lo hicimos con c + +. Si no, ¿cuáles son los detalles? O tal vez si es posible pero muy, muy poco práctico ¿cuáles son estas razones?

(Por ejemplo he leído algo sobre java Buffers y OpenGL no son el mejor emparejamiento, pero no recuerdo los detalles – tal vez algún experto)

Vas a estar pagando un costo fijo adicional por llamada para usar OpenGL desde el código fuente de Java. Android proporciona envolturas de lenguaje Java alrededor de las llamadas. Por ejemplo, si llama a glDrawArrays , está llamando a un método nativo declarado en GLES20.java , que está definido en android_opengl_GLES20.cpp . Usted puede ver desde el código que es sólo el reenvío de la llamada con un mínimo de gastos generales.

Mirando alrededor en el archivo, puede ver otras llamadas que realizan controles adicionales y por lo tanto son un poco más caros.

La línea de fondo en cuanto a los costos inevitables es que el precio de hacer un montón de llamadas GLES es mayor con la fuente de Java que la fuente nativa. (Al mirar el rendimiento de Android Breakout con systrace me di cuenta de que había una gran cantidad de CPU en el controlador porque estaba haciendo un montón de actualizaciones de estado redundante.El costo de hacerlo desde el código nativo habría sido menor, Costo de hacer cero trabajo es menos que el costo de hacer menos trabajo.)

La pregunta más profunda tiene que ver con si necesita escribir su código de manera diferente (por ejemplo, para evitar asignaciones) que simplemente no puede obtener el mismo nivel de rendimiento. Tienes que trabajar con objetos ByteBuffer directos en lugar de arrays simples, lo que puede requerir un poco más de gestión de su lado. Pero aparte de las diferencias de velocidad actuales entre el código nativo y Java de computación intensiva en Android, no tengo conocimiento de nada que impida fundamentalmente un buen rendimiento de implementaciones estrictamente Java.

  • Cómo crear el modelo de cara de usuario dinámico en android?
  • ¿Mejor velocidad de cuadro que dibuja los mapas de bits en una lona?
  • Dibuja animaciones de alta resolución con alta velocidad de fotogramas en Android
  • Android, Transparente sub-GLSurfaceView en el diseño?
  • Cocos2d-xv 2.0.4 FATAL EXCEPTION GLThread cuando se ejecuta en el emulador de Android
  • OpenGL ES 2.0 vs OpenGL 3 - Similitudes y diferencias
  • GLSurfaceView desaparece cuando se desplaza hacia arriba y se desplaza hacia abajo nuevamente en RecyclerView
  • Límites de memoria de Android Graphics
  • Consejos sobre dibujo de alto rendimiento en Android
  • ¿La mejor manera de tener una superposición de zoom y pan en Android?
  • Genymotion no se inicia (permiso denegado para androvm.gles.first)
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.