Android drawBitmap Rendimiento para muchos mapas de bits?

Question

Estoy en el proceso de escribir un juego de Android y parece que tengo problemas de rendimiento al dibujar en el Canvas. Mi juego tiene múltiples niveles, y cada uno tiene (obviamente) una cantidad diferente de objetos en él.

Lo extraño es que en un nivel, que contiene 45 imágenes, se ejecuta sin problemas (casi 60 fps). Sin embargo, otro nivel, que contiene 81 imágenes, apenas funciona en absoluto (11 fps); es bastante injugable. ¿Esto le parece extraño a alguien además de mí?

Todas las imágenes que uso son .png y la única diferencia entre los niveles antes mencionados es el número de imágenes.

¿Qué está pasando aquí? ¿Puede el Lienzo simplemente no dibujar tantas imágenes en cada bucle de juego? ¿Cómo recomendarían que mejore este rendimiento?

Gracias de antemano.

Answer 1

Creo que this lecture te ayudará. Ve a los 45 minutos. Hay un gráfico que compara el método Canvas y el método OpenGl. Creo que es la respuesta.

Answer 2

Me parece extraño también. También estoy desarrollando un juego, muchos niveles, puedo tener fácilmente 100 objetos de juego en la pantalla, no he visto un problema similar.

Utilizado correctamente, drawbitmap debe ser muy rápido; es poco más que un comando de copia. Ni siquiera dibujar círculos de forma nativa; Tengo mapas de bits de círculos prestados.

Sin embargo, el rendimiento de Bitmaps en Android es muy sensible a cómo lo hace. La creación de mapas de bits puede ser muy costosa, ya que Android puede escalar automáticamente los pngs que consumen mucha CPU. Todo esto debe hacerse exactamente una vez, fuera de su ciclo de representación.

Sospecho que está buscando en el lugar equivocado. Si crea y utiliza el mismo tipo de imágenes de la misma manera, duplicar el número de imágenes de pantalla no debería reducir el rendimiento en un factor superior a 4. Como máximo, debería ser lineal (un factor de 2).

Mi primera sospecha sería que la mayor parte del tiempo de su CPU se utiliza en la detección de colisiones. A diferencia de los mapas de bits de dibujo, esto normalmente aumenta como el cuadrado de la cantidad de objetos que interactúan, ya que cada objeto debe probarse para colisión contra cualquier otro objeto. Dobló el número de objetos del juego, pero su rendimiento bajó a un cuarto, es decir, según el cuadrado de la cantidad de objetos. Si este es el caso, no te desesperes; hay formas de hacer detección de colisión que no crecen como el cuadrado de la cantidad de objetos.

Mientras tanto, haría las pruebas básicas. ¿Qué sucede si no dibujas la mitad de los objetos? ¿El juego se ejecuta mucho más rápido? Si no, no tiene nada que ver con el dibujo.

Answer 3

me encontré con un problema similar con el rendimiento - es decir, nivel 1 corrió grande y nivel 2 no

lo convirtió no era la representación que era un fallo (por lo menos no específica). Era algo más específico de la lógica de nivel que causaba un cuello de botella.

El punto es ... Traceview es tu mejor amigo.

El perfilado del método mostró dónde estaba pasando el tiempo la CPU y por qué estaba ocurriendo la falla en la velocidad de fotogramas.(por cierto, el costo de renderizado también fue mayor en el Nivel 2 pero no fue el cuello de botella)