Full HD 2D Texture Memory OpenGL

Question

Estoy en el proceso de escribir un motor 2D con capacidad Full HD para una compañía de artistas que con suerte será multiplataforma y está escrita en OpenGL y C++.

El principal problema que he tenido es cómo lidiar con todos esos sprites HD. Los artistas han dibujado los gráficos a 24 fps y se exportan como secuencias png. Los he convertido en DDS (no es ideal, porque necesita el encabezado directx para cargar) DXT5, que reduce mucho el tamaño del archivo. Algunas escenas del juego pueden tener 5 o 6 sprites animados a la vez, y estos pueden constar de más de 200 cuadros cada uno. Actualmente estoy cargando sprites en una serie de punteros, pero esto lleva demasiado tiempo cargar, incluso con texturas comprimidas, y usa bastante memoria (aproximadamente 500 mb para una escena completa).

Así que mi pregunta es, ¿tiene alguna idea o consejo sobre cómo manejar volúmenes tan grandes de marcos? Hay un par de ideas que he thought've de:

• uso del formato SWF para almacenar los marcos de flash
• Implementar un sistema de animación del esqueleto en 2D, en sustitución de las secuencias png (no tengo preocupaciones acerca de la las uniones son visibles)

¿Cómo se cargan juegos como Castle Crashers tan rápido con excelentes gráficos HD?

Answer 1

24 fps animaciones hechas a mano? ¿Has considerado reducir el framerate? Incluso la animación de cine de calidad cinematográfica rara vez se dibuja a los 24 fps completos. Incluso bajar a 18 fps eliminará el 25% de sus datos.

En cualquier caso, no especificó donde sus tiempos de carga fueron largos. ¿El problema es la carga del disco duro a la memoria, o es la carga de la textura de la memoria el problema? ¿Con frecuencia intercambia conjuntos de datos de textura en la GPU, o simplemente crea un montón de texturas en el tiempo de carga?

Si se trata de un problema de carga de disco, entonces la única opción real es comprimir los datos de textura en el disco y descomprimirlos en la memoria. La compresión al estilo S3TC no está tan comprimida; está diseñado para ser una técnica de compresión útil para texturizar hardware. Generalmente, puede hacerlo más pequeño utilizando una biblioteca de compresión estándar, como zlib, bzip2 o 7z. Por supuesto, esto significa tener que descomprimirlo, pero las CPU se están volviendo más rápidas que los discos duros, por lo que generalmente es una ganancia general.

Si el problema está en el ancho de banda de carga de texturas, entonces no hay muchas soluciones para eso. Bueno, dependiendo de su hardware de interés. Si su hardware de interés es compatible con OpenCL, entonces siempre puede transferir datos comprimidos a la GPU, y luego usar un programa OpenCL para descomprimirlo sobre la marcha directamente en la memoria de la GPU. Pero requerir soporte OpenCL impactará el nivel mínimo de hardware que puede soportar.

No descarte animaciones esqueléticas 2D tan rápidamente. Los juegos como Odin Sphere logran una mejor animación de los esqueletos en 2D al tener varias versiones de cada una de las posiciones de los brazos. El que se dibuja es el que coincide con el más cercano a la parte del cuerpo al que está unido. También usan arte inteligente para ocultar cualquier defecto, como ropa acampanada, etc.

Answer 2

Bueno, lo primero a tener en cuenta es que no todas las plataformas son compatibles con DXT5 (específicamente los móviles).

Más allá de eso, ¿ha considerado usar algo como zlib para comprimir las texturas? Es probable que las texturas tengan un alto grado de similitud entre ellas, lo que significa que se comprimirán mucho. Hoy en día, la descompresión es barata debido a la velocidad de los procesadores y el tiempo ahorrado para sacar los datos del disco puede ser mucho más útil que el tiempo perdido para la descompresión.

Comenzaría allí si fuera usted.