Gráficos 2D: ¿por qué usar spritesheets?

He visto muchos ejemplos de cómo renderizar sprites desde una hoja de sprites, pero no he comprendido por qué es la forma más común de tratar con sprites en juegos 2D.

Comencé con la representación de sprites 2D en las pocas aplicaciones de demostración que hice al tratar cada cuadro de animación para cualquier tipo de sprite dado como su propia textura, y esta colección de texturas se almacena en un diccionario. Esto parece funcionar para mí, y se adapta bastante bien a mi flujo de trabajo, ya que tiendo a hacer mis animaciones como archivos gif / mng y luego extraigo los marcos a png individuales.

¿Existe una notable ventaja de rendimiento al renderizar desde una sola hoja en lugar de texturas individuales? Con un hardware moderno que es capaz de dibujar millones de polígonos en la pantalla cien veces por segundo, ¿importa incluso para mis juegos 2D que solo se ocupan de unas pocas docenas de rectángulos de 50x100px?

Los detalles de implementación de cargar una textura en la memoria de gráficos y mostrarla en XNA parecen bastante abstractos. Todo lo que sé es que las texturas están unidas al dispositivo gráfico cuando se cargan, luego, durante el ciclo del juego, las texturas se procesan en lotes. Entonces no me queda claro si mi elección afecta el rendimiento.

Sospecho que hay algunas razones muy buenas por las que la mayoría de los desarrolladores de juegos 2D parecen estar usándolas, pero no entiendo por qué.

Un argumento fuerte para usar hojas de sprites es que el número de texturas disponibles en una tarjeta gráfica puede ser limitado. Por lo tanto, su biblioteca de gráficos tendría que eliminar constantemente la textura y reasignar texturas en la GPU. Es mucho más eficiente simplemente asignar una textura grande una vez.

También tenga en cuenta que los tamaños de las texturas suelen tener una potencia de 2. Por lo tanto, si tiene un Sprite de 50x100px, asignará texturas con un tamaño de 64x128px o, en el peor de los casos, 128x128px. Eso solo está desperdiciando memoria gráfica. Es mejor empacar todos los sprites en una textura de 1024x1024px, lo que permitiría 20x10 sprites y solo perderá 24 píxeles horizontal y verticalmente. A veces, incluso los sprites de diferentes tamaños se combinan en una gran hoja de sprites para usar la textura de la manera más eficiente posible.

Anexo: Una razón muy importante para usar las hojas de sprites es reducir la cantidad de llamadas de extracción en su GPU, lo que puede tener un impacto notable en el rendimiento. Esto se ha indicado en otras respuestas y estoy agregando esto en aras de la integridad para que esto tenga más visibilidad.

Diría que el argumento a utilizar sería la capacidad de representar varias cosas en una sola llamada de sorteo. Tomemos, por ejemplo, la representación de la fuente, sin una hoja de sprites necesitaría representar cada carácter con un intercambio de textura separado seguido de una llamada de dibujo. Tírelos en una hoja de sprites y puede renderizar oraciones completas con una sola llamada de dibujo (los caracteres de diferencia en la fuente se seleccionan simplemente especificando los diferentes UV para las esquinas). Esta es una forma mucho más eficiente de renderizar cuando una sobrecarga muy real de renderizar cosas en muchas plataformas es hacer demasiadas llamadas API.

También puede ayudar a ahorrar espacio, pero depende de lo que empaques en la hoja de sprites en primer lugar.

Cada llamada de sorteo tiene una cierta cantidad de gastos generales. Mediante el uso de hojas de sprites puede agrupar el dibujo de cosas que no están usando el mismo cuadro de una animación (o más generalmente, todo lo que está en el mismo material) mejorando en gran medida el rendimiento. Esto puede no importar demasiado para las PC modernas dependiendo de su juego, pero definitivamente importa en, por ejemplo, el iPhone.

Además de las consideraciones de rendimiento, las hojas de sprites pueden ser útiles al crear el arte; cada personaje puede estar en su propia hoja, y puede ver todos los cuadros simplemente desplazándose. Me ayuda a mantener una apariencia consistente en todos los cuadros.

Además, codifico en AS3, y cada archivo de imagen requiere una instrucción de inserción separada. Prefiero tener una sola incrustación de una hoja de sprites completa que 24 incrustaciones para todos los marcos, incluso si estoy usando una clase de recurso separada.

Otra razón para usar las hojas de sprites con XNA es que con el desarrollo de Xbox360 hay un problema conocido con tiempos de implementación / carga lentos en relación con la cantidad de archivos que tiene en su proyecto. Por lo tanto, combinar muchos archivos de imagen pequeños en un solo archivo de imagen ayudará a combatir ese problema.

No voy a mencionar la memoria / GPU aquí, ya que hay suficientes respuestas como esa.

En cambio, puede aclarar su arte mientras trabaja en él, y después. En lugar de tener que pasar 10 imágenes para ver el ciclo de caminata, puede ver todos los cuadros de una vez. Si desea distribuir esto, solo tiene 1 archivo para tratar en lugar de 10.

Y luego también es más limpio (desde el punto de vista de la organización) tener character.png y enemy.png sobre characterwalk01 hasta characterwalk10, luego characterattack01 a characterattack05, y continúa.

La memoria de gráficos no tiene una administración de memoria inflada como los sistemas de archivos en discos; lo contrario es el caso: se mantiene simple y rápido .

Una gestión de memoria tan simple y rápida podría ser como tener un solo sprite gigante 4096x4096 que se corta en múltiples sprites más pequeños al reducir a la mitad su ancho y / o altura. (Existe una técnica de administración de memoria unidimensional similar, pero olvidé el nombre). Eventualmente, se debe realizar la desfragmentación.

Para omitir dicha gestión de memoria en tiempo de ejecución , los desarrolladores llenan sprites grandes individuales con múltiples sprites más pequeños automáticamente en tiempo de compilación o incluso durante el proceso de diseño de los gráficos.

Además, no olvide las operaciones de E / S que podría salvarlo durante la inicialización. Si está cargando desde una unidad de CD, cada archivo es una llamada de E / S adicional y puede tomar un tiempo para buscar (los discos duros modernos son de aproximadamente 15 ms por archivo, ¿los CD pueden ser de 50-100 ms?). Esto puede ahorrarle mucho tiempo de inicialización ya que solo se debe recuperar un archivo. También permite que su sistema operativo almacene en caché estas operaciones de E / S, en caso de que su aplicación esté haciendo otra cosa (como esperar a la GPU).

Además de ser más eficiente en el rendimiento, lo encuentro simplemente más fácil. Se requiere un poco de trabajo extra para asegurarse de que sus imágenes siempre estén dentro de sus límites al crear el arte, pero es mucho más fácil poder ver todas las imágenes con las que está lidiando en este momento.

También es más fácil de codificar, en mi opinión. Simplemente tengo una serie de objetos como:

sheet = {
    img: (the actual image),
    rects: [
        {x:0, y:0, w:32, h:32},
        {x:32, y:0, w:32, h:32},
        {x:64, y:0, w:32, h:32}
    ]
};

sheets.push(sheet);

Luego, para cada elemento, le doy dos valores, hoja y rect. La hoja sería el índice en la matriz de objetos, y el rect sería el índice en la matriz de rectos de esa hoja.