pesa - Rendimiento e imágenes de fondo para OpenGL ES/iPhone
ios 12 (6)
Es posible que desee probar el uso de VBO (Vertex Buffer Objects) y ver si eso acelera las cosas. El tutorial está aquí
Además, acabo de ver que, desde OpenGL ES v1.1 , hay una función llamada glDrawTex (Draw Texture) diseñada para
reproducción rápida de pinturas de fondo, glifos de fuentes bitmapped y elementos de encuadre 2D en juegos
Estoy desarrollando un juego 2D para iPhone usando OpenGL ES y me gustaría usar una imagen de mapa de bits de 320x480 como fondo persistente.
Mi primer pensamiento fue crear un quad de 320x480 y luego asignarle una textura que representa el fondo. Entonces ... Creé una textura de 512x512 con una imagen de 320x480. Luego asigné eso al quad 320x480.
Dibujo este fondo en cada cuadro y luego dibujo sprites animados sobre él. Esto funciona bien, excepto que el dibujo de todos estos objetos (fondo + sprites) es demasiado lento.
Hice algunas pruebas y descubrí que mi ralentización está en la tubería de píxeles. No es sorprendente que la gran imagen de fondo sea la principal culpable. Para probar esto, eliminé el sorteo de fondo y todo lo demás se procesó muy rápido.
Estoy buscando consejos sobre cómo mantener mi historial y también mejorar el rendimiento.
Aquí hay algo más de información:
1) Actualmente estoy probando en el simulador (aún estoy esperando la licencia de Apple)
2) El fondo es una textura PVR exprimida hasta 128k
3) Tenía la esperanza de que podría haber una forma de almacenar estos fondos en un buffer de color, pero no he tenido suerte con eso. eso puede deberse a mi inexperiencia con OpenGL ES o simplemente podría ser una idea estúpida que no funcionará :)
4) Me doy cuenta de que no es necesario actualizar todo el fondo, solo las partes que han sido dibujadas por los sprites en movimiento. Empecé a buscar técnicas para refrescar (según sea necesario) partes del fondo, ya sea como texturas separadas o con una caja de tijera, sin embargo, esto parece menos que elegante.
Cualquier consejo / consejo sería muy apreciado ...
Gracias.
No tengo mucha experiencia con OpenGL ES, pero este problema ocurre en general.
Su idea sobre el ''búfer de color'' es una buena intuición, esencialmente desea almacenar su fondo como un búfer de cuadros y cargarlo directamente en su búfer de renderizado antes de dibujar el primer plano.
En OpenGL, esto es bastante sencillo con Frame Buffer Objects (FBO). Desafortunadamente, no creo que OpenGL ES los admita, pero podría darle un lugar donde comenzar a buscar.
Si está haciendo un juego 2D, ¿hay alguna razón por la que no esté utilizando una biblioteca existente? Específicamente, el cocos2d para iPhone puede valer la pena. No puedo responder a tu pregunta sobre cómo solucionar el problema haciendo todo tú mismo, pero puedo decir que hice exactamente lo que estás diciendo (tener un fondo de pantalla completa con sprites en la parte superior) con Cocos2d y funciona estupendo. (Suponiendo 60 fps es lo suficientemente rápido para ti). Puedes tener tus razones para hacerlo tú mismo, pero si puedes, te sugiero que al menos hagas un prototipo rápido con cocos2d y veas si eso no te ayuda. (Los detalles y la fuente de la versión de iPhone están aquí: http://code.google.com/p/cocos2d-iphone/ )
- No hagas pruebas de rendimiento en el simulador. ¡Nunca!
Las diferencias con el hardware real son enormes. En ambas direcciones. - Si dibujas el fondo de cada fotograma:
No borre el framebuffer. El fondo se sobrecargará todo de todos modos. - ¿Realmente necesitas una textura de fondo?
¿Qué pasa con el uso de un degradado de color a través de colores vértice? - Intenta usar el modo de 2 bits para la textura.
- Gire todos los pasos de renderizado que no necesita para el fondo.
Ejemplo: iluminación, mezcla, prueba de profundidad, ...
Si pudieras publicar algo de tu código de dibujo, sería mucho más fácil ayudarte.
- Podría usar objetos de búfer de cuadro similares al ejemplo de GLPANT de Apple.
- Use un atlas de textura para minimizar el número de llamadas de sorteo que realiza. Puede usar glTexCoordPointer para establecer las coordenadas de su textura que mapeen cada imagen a su posición correcta. Recuerde establecer su búfer de vértice también. Idealmente, una llamada de sorteo representará toda su escena en 2D.
- Evite habilitar / deshabilitar estados siempre que sea posible.
Gracias a todos los que proporcionaron información sobre esto. Todos los consejos ayudaron de una forma u otra.
Sin embargo, quería dejar en claro que el principal problema aquí fue el comportamiento del simulador en sí (como lo sugiere Andreas en su respuesta). Una vez que pude obtener la aplicación en el dispositivo, funcionó mucho, mucho mejor. Menciono esto porque, antes de desarrollar mi juego, había visto muchas publicaciones que indicaban que el dispositivo era mucho más lento que el simulador. Esto podría ser cierto en algunos casos (por ejemplo, la lógica de aplicación general), pero en mi experiencia, la animación (particularmente las transformaciones en 3D) es mucho más rápida en el dispositivo.