studio - juego android, lienzo o opengl?

opengl android tutorial español

Question

Debo escribir un juego para android, tengo que elegir entre canvas o opengl para dibujar. He leído que el lienzo no tiene una buena velocidad de cuadros, pero ¿qué es bueno? Imagina que ibas a escribir un juego de pájaros enojado, ¿bastaría con una tasa de cuadros por segundo?

Answer 1

Si vas a hacer un juego tan grande, definitivamente deberías considerar usar AndEngine: http://www.andengine.org/

Si se usa correctamente, es una gran ayuda. Lamentablemente, no hay documentación en el código. Pero el foro en el sitio está bastante bien. E incluso aquí en SO, aparecen más y más preguntas sobre AndEngine. Afortunadamente hay muchos buenos ejemplos para comenzar.

And Engine usa OpenGL, por lo que no tiene que perder el tiempo con posibles tasas de fotogramas bajas mientras dibuja en el lienzo.

Consulte la aplicación de ejemplos: https://market.android.com/details?id=org.anddev.andengine.examples

Answer 2

Todo depende del tipo de juego que necesites implementar.

Teniendo en cuenta que estás pidiendo una implementación de canvas, supongo que te refieres a un juego de sprites en 2D puro.

Si los sprites no son muchos y el número es muy bajo, la verdad es que posiblemente desee notar una gran diferencia (tenga en cuenta que muchos juegos con gráficos 2D básicos utilizan lienzos).

Si el rendimiento importa o si tiene un número muy elevado de sprites, entonces vale la pena implementar un sistema basado en OpenGL.

Considere que al usar OpenGL se beneficiará del hardware dedicado de la GPU para que su CPU se descargue de la carga de la representación de gráficos.

Además, se beneficiará de mucha más flexibilidad que una implementación de lienzo utilizando efectos de fusión, iluminación y procesamiento posterior. Realmente no hay límites en lo que puedes hacer.

Un ejemplo simple es la rotación y escalado que usar un motor 3D como OpenGL es muy barato y ofrece excelentes resultados.

El lienzo debe ser adoptado para implementaciones simples.

PD: si opta por OpenGL ES 2.0 y la tubería programable, realmente no tiene límites en lo que logra (brillo, desenfoque y miles de opciones diferentes). El límite es realmente nuestra fantasía en ese caso.

:)

Answer 3

Inicialmente escribí mi juego usando Canvas, pero luego tuve que cambiar a OpenGL por las siguientes razones:

• Usando Canvas, tus sprites se almacenan en el montón (a menos que los almacenes en caché específicamente en el disco), esto pone un límite en el tamaño total de tus recursos de sprite dependiendo del teléfono, ¡no es bueno! Encontré que esto era alrededor de 42mb en mi teléfono. Tenga en cuenta que este es el tamaño descomprimido de mapas de bits. Si tiene varios tipos de entidades, cada una con diferentes animaciones, entonces puede alcanzar este tamaño muy rápidamente.

• OpenGL almacena sus activos de sprite por separado en el montón que aumenta la memoria disponible de forma espectacular.

• Canvas no se escala muy bien. Cuantas más llamadas .draw (...) haga, más lento se ejecutará. La relación es bastante lineal.

• Al usar OpenGL puede combinar sus llamadas de sorteo para mejorar el rendimiento.

Puede ser intimidante comenzar con OpenGL, lo que hace que Canvas parezca atractivo. Sin embargo, por experiencia, desearía haber empezado con OpenGL. Mi recomendación sería ''morder la bala'' e ir con OpenGL si estás haciendo un juego.

Para hacer las cosas un poco más fáciles de empezar, he escrito algunas útiles clases de utilidad que hacen todo lo esencial de OpenGL para usted. Permiten hacer llamadas .draw (..) simples similares a cuando se usa Canvas. El siguiente video tutorial debe comenzar:

http://www.youtube.com/watch?v=xc93rN2CGNw

EDITAR: 03/04/13

Parece que a medida que salen nuevos dispositivos Android y sistemas operativos, Google ha aumentado el rendimiento de Canvas. Un usuario de la clase de utilidad que describo más arriba me lo devolvió con el siguiente correo electrónico después de hacer una evaluación comparativa:

Dibujando 500 sprites en posiciones aleatorias en el lienzo de cada cuadro.

Estos son los resultados: Huawei Honor (Gingerbread, single core 1.4 Ghz): SpriteBatcher: 19-20 FPS, Canvas: 23-24 FPS

Nexus 7 (JellyBean, 4 núcleos 1.3 Ghz): SpriteBatcher: 29-30 FPS, Canvas: 57-58 FPS

Ahora, en mi respuesta a este usuario, expliqué que esto podría tener que ver con ineficiencias en la forma en que escribí la clase de utilidad SpriteBatcher. Sin embargo, desde mi propia experiencia con Canvas en un HTC Desire con Froyo 2.2, puedo decir que definitivamente fue un sprite más lento para Sprite.

En los sistemas operativos y dispositivos posteriores puede haber superado la eficiencia, pero algunos de los puntos en mi respuesta original siguen siendo válidos. Por ejemplo, moverse por una OutOfMemoryException sin tener que recurrir a almacenar en caché texturas en el disco, etc.

Si aprendo más, continuaré actualizando esta respuesta.