¿Por qué los videojuegos usaron sprites para varias orientaciones de personajes en lugar de una imagen individual para cada uno?

Creo que lo que realmente está preguntando es: “¿Por qué usamos un atlas de texturas en lugar de mantener cada textura en un archivo separado?” Una hoja de sprites es, después de todo, solo una imagen que contiene cuadros de animación secuenciales. Pero técnicamente, un sprite es solo una imagen 2D, y puede ser un solo cuadro.

Hay una serie de razones por las que uno podría agrupar recursos en un archivo más grande en lugar de usar varios archivos. Por un lado, reduce la cantidad de lecturas del disco. También le permite obtener una mejor compresión de sus archivos, ya que puede aprovechar el hecho de que los cuadros de una sola animación son muy similares.

Sin embargo, lo más importante es que tener los recursos de su imagen como una sola textura en la memoria le permite a su hardware de gráficos enlazarlo como una sola unidad, reduciendo el número de cambios de estado en cada ciclo de renderizado.

La única razón por la que puedo pensar que no empaqueta texturas juntas es para reducir la RAM en los casos en que necesita cargar algunos, pero no todos, los recursos para un nivel en particular. Pero entonces, simplemente empacaría todos los recursos para un nivel y separaría lo que no necesita.

No estoy completamente seguro de por qué aparece HTTP en los detalles de la pregunta. Los juegos no suelen usar HTTP para cargar recursos, a menos que estemos hablando de juegos de navegador. Por favor aclare en los comentarios si entendí mal alguna parte de su pregunta.

Los primeros videojuegos tenían muy poca memoria, por lo que lo optimizaron de la mejor manera posible. Tomaron exactamente la mayor cantidad de memoria que tenían disponible y luego la llenaron de pared a pared con la mayor cantidad posible. Esto dio como resultado hojas de sprites como esta.

El juego luego tomaría trozos de esa hoja de sprites y los manipularía. Al almacenarlos todos en un gran sprite con desplazamientos predefinidos como trozos de 16 o 32 píxeles, podrían ser mucho más eficientes.

Podrían haber tenido cada imagen como su propio recurso, pero luego debe almacenar la ubicación del índice en ram para cada recurso. En este caso, simplemente cargaron la imagen completa como datos sin procesar en la memoria del sistema.

Estas consolas funcionaban con cantidades tan pequeñas de memoria que esto era mucho más eficiente en el almacenamiento y ese era el gran problema que tenían que resolver.

El hardware fue diseñado desde cero para trabajar con sprites para lidiar con el pequeño carnero y la baja potencia de los chips en ese momento.

Sistema de entretenimiento de Nintendo

El NES contiene 2 kB de RAM de trabajo a bordo. Un cartucho de juego puede contener RAM expandida para aumentar esta cantidad. El tamaño de los juegos de NES varía de 8 kB (Galaxian) a 1 MB (Metal Slader Glory), pero 128 a 384 kB fue el más común.

El NES [81] utiliza una Unidad de procesamiento de imágenes (PPU) desarrollada por Ricoh. Todas las variaciones de la PPU cuentan con 2 kB de RAM de video, 256 bytes de “memoria de atributo de objeto” (OAM) para almacenar las posiciones, colores e índices de mosaico de hasta 64 sprites en la pantalla, y 28 bytes de encendido -die paleta RAM para permitir la selección de colores de fondo y sprite. Los 2 kB de RAM integrada de la consola se pueden usar para mapas y atributos de mosaico en la placa NES y se pueden incluir 8 kB de ROM o RAM de patrón de mosaico en un cartucho. El sistema tiene una paleta de colores disponible de 48 colores y 6 grises. Se pueden usar hasta 25 colores simultáneos sin escribir nuevos valores a mitad del cuadro: un color de fondo, cuatro conjuntos de tres colores de mosaico y cuatro conjuntos de tres colores de sprite. La paleta NES se basa en NTSC en lugar de valores RGB. Se puede mostrar un total de 64 sprites en pantalla en un momento dado sin recargar sprites en la pantalla. La resolución de pantalla estándar del NES es de 256 píxeles horizontales por 240 píxeles verticales.