Internal Beeper


Sprites
marzo 25, 2005, 1:52 am
Filed under: Informtica variada

Voy a hablar un poco de los sprites, ya que tengo intención de ir poniendo de tanto en tanto posts un poco técnicos sobre el interior de los videojuegos, como ya hice el otro día explicando el significado del 255.

Un sprite es, sobretodo en los juegos 2D (también llamados juegos de sprites para diferenciarlos de los que utilizan modelos 3D), un objeto móvil.

A resumidas cuentas, todo lo que no forma parte del escenario y que tiene capacidad para variar.

Los sprites siempre han sido una parte vital en los videojuegos, por motivos obvios.

De hecho, podemos pensar en los sprites como un tampón de matasellos. Un juego de ordenador almacena todos los sprites (o, como mínimo, todos los sprites que vayan a ser utilizados antes de la siguiente carga) en la memoria. Entonces, cuando debe ser mostrado por pantalla, se busca el tampón correspondiente y se copia a la pantalla (concretamente, a la memoria gráfica, y el ordenador la mostrará en pantalla en cuestión de milisegundos, en el siguiente refresco).

link_lttp.png
¡Hola, soy un sprite en memoria!

Aquí vemos a Link en memoria. El dibujo está apañado para que Link salga identificable, pero en realidad esto deberíamos verlo (en la mayoría de sistemas) como una linea alargada de cuadros, correspondiente a posiciones de memoria. La información de esta memoria es, concretamente, el color que debe dibujar, dejando un color concreto como transparencia. En este caso, el color “transparente” es el negro, y todo lo del dibujo de Link que sea negro no se dibujaría. Observad como Link tiene los ojos de un gris oscuro, pero nunca negro, ya que entonces, podríamos ver lo que Link tiene detrás transparentado en sus ojos.

Las animaciones, como podeis suponer, se basa en ir poniendo distintos sprites muy parecidos en el mismo lugar a intervalos cortos. Más o menos como se hacían los dibujos animados.

Pero lo más importante de los sprites, sobretodo en los sistemas antiguos, era saber optimizarlos para que, en poca memoria, pudiéramos abarcar gran variedad de gráficos. Porque, hagamos lo que hagamos, tiene el mismo “coste” de tiempo imprimir en pantalla 10 veces el mismo sprite que imprimir 10 sprites diferentes.

Consolas

Las consolas lo tienen fácil. La NES o la SNES, o la GBA, tienen una memoria específica para los sprites. La GBA, en concreto, tiene ciertas zonas de mapeado que sirven únicamente para poner sprites o fondos. Es decir, cuanto más sprites tengamos en memoria, menos variedad de fondos podremos poner. Pero ya está. Siempre podemos contar con una variedad de sprites notable.

Los sistemas como el PC (o los más antiguos como CPC o Spectrum) no tienen esta baza. Si ocupas los 128 kb de memoria de un antiguo CPC en una variedad de músicas, o en mapeado de muchos niveles, o en un algoritmo de inteligencia artificial para que los enemigos sean más “listos”, vas a tener muchos problemas para presentar una variedad de gráficos en pantalla.

Decolorar

El Spectrum optaba por la decoloración. Imaginemos que tenemos 1000 animaciones posibles (nada raro si contamos el movimiento de un protagonista, unas cinco variedades de enemigos y los objetos), de sprites que cada uno mide 10 pixels de ancho por 10 de alto. Eso son un total de 100 píxels por sprite. A un total de 1000 sprites, nos salen 100.000.

Si contamos que el Spectrum tiene 8 colores, para representar cada color necesitamos 3 bits. En total, 300.000 bits, que corresponden a 37’5 kb.

Pero, claro, con la poca memoria de un Spectrum, no podemos poner 37 kb de Sprites. ¿Dónde pondríamos los fondos, o la música, o el código? Así pues, el Spectrum utilizaba solo 1 bit por pixel. 0 no pintaba nada (trasparente) y 1, lo pintaba. Entonces se le indicaba a cada grupo de sprites de que color era. Si el protagonista iba de azul, pues todo azul. De esta forma, reducíamos por tres el tamaño de los gráficos.

Paleta

Algo muy importante (no imprescindible, pero aumenta significativamente la variedad gráfica de un juego) cuando se utilizan los sprites es no utilizar colores fijos. Es decir, no pintar a Link de verde claro, verde oscuro, marrón, etc… sino pintarlo de color 1, color 2, color 3, etc…

Entonces tenemos una serie de paletas. Las paletas son asignaciones del color de referencia (color 1, color 2, color 3…) a los colores concretos (verde claro, verde oscuro, marrón…).

Así pues, si tenemos, por ejemplo, una paleta “luz” y una paleta “sombra”, simplemente con cambiar la paleta activa, podremos hacer que link se vea más oscuro cuando pasa por debajo de un árbol. No es necesario (afortunadamente) tener en memoria dos Links.

Esto se nota mucho en los clásicos Final Fantasy en 2D. Debido a la variedad de enemigos, se utilizaban distintas paletas “facil”, “medio”, “difícil”. De esta forma, podíamos ver tres tipos distintos de monstruos, de distinta dificultad, pero que en realidad eran los mismos sprites pero con otra paleta.

Divide y Vencerás

A veces sale mucho más a cuenta, en cuestiones de memoria, separar los sprites. Si tienes un sprite muy grande, pero el movimientos solo afecta a una parte, en vez de tener un sprite grande para cada movimiento, es mucho mejor tener un sprite grande fijo y después uno pequeño de cada movimiento de la zona en cuestión.

Uno de los primeros juegos que utilizaron esa técnica fue el After the War, de Dinamic. Tenía un problema. Podías caminar, saltar, agacharse, etc. Pero también golpear, empuñar distintos tipos de armas, apuntar hacia arriba…

After_The_War.gif
El prota de After the War, partido pero feliz.

Así pues, si teníamos que repetir todos los sprites de caminar con cada una de las armas posibles, o acciones posibles, salía un número de sprites descomunal.

Así pues, ¿qué hizo Dinamic? Separar al protagonista en dos sprites. Una serie de sprites para la mitad inferior y otra para la mitad superior. Así pues, en vez de contar con un total de 2500 sprites con todos los movimientos posibles, teníamos sólo 100, 50 de los movimientos con la mitad inferior y 50 con la superior.

La calidad gráfica muchas veces sorprendente en sistemas antiguos venía dada por estos trucos. Una mala utilización de los sprites hace que un juego deba limitarse a pocos movimientos y enemigos repetitivos. En cambio, una buena utilización permite una gran variead y, de esta forma, unos gráficos superiores a la media de los demás juegos de ese sistema.

Anuncios

7 comentarios so far
Deja un comentario

Por cierto, me gustaría especialmente que realizarais algún comentario sobre que os parece este artículo o, ya siendo más generalistas, este tipo de artículos. Más que nada para saber si este tipo de divagaciones más técnicas tienen cabida en este blog.

Comentario por DonDepre

A mi me encantan, son casi una clase de teoria de la programacion de videojuegos. Luego a luego podrias pensar en recopilarlos todos y ofrecerlo como un cursillo…

Comentario por BigBang

A mi tambien me gustan este tipo de artículos. Siempre me ha gustado saber que había “debajo” de los videojuegos. Enhorabuena, sigue así.
un saludo
Trokkes

Comentario por trokkes

Creo que cometes un error con el spectrum, o bien es un error de apreciación mío. No es que los programadores “optaran” por decolorar los sprites en spectrum, es que, sencillamente, no había más narices que hacerlo así.

El área de memoria de pantalla de spectrum se divide en dos grupos: una en la que se representa un bit activo como un pixel iluminado (blanco, para entendernos) y un bit inactivo como un pixel apagado (negro), y otra que representaba los colores que debían colocarse en pantalla. Pero casualmente, los colores en spectrum solo podían representarse en una matriz de 40*25, que era el nº de caracteres que podian escribirse en pantalla.

Otro problema que hay en spectrum para representar un sprite es que si sólo tienes 1 y 0, blanco y negro… ¿cómo representas las áreas transparentes? Pues bien, el truco que había era utilizar otro sprite llamado “máscara”. La cosa funcionaba de forma parecida a los sprites “multicolores” de otras plataformas, pero en dos fases: si en un punto de la máscara hay un 0 (negro) no se dibuja el punto equivalente del sprite, y si en la máscara hay un 1 (blanco), se dibuja el pixel equivalente del sprite “real”.

Ah, y en cuanto a los sprites, la forma más habitual de representarlos en cualquier plataforma es leyendo el área de memoria de izqda a dcha y pintándolos en el mismo sentido, pero para ahorrar memoria, con el mismo sprite se puede leer de izqda a dcha y se imprime de dcha a izquierda, con lo que se obtiene un efecto “mirror” y te ahorras un webo de memoria.

Comentario por Naranek

Claro, olvidé mencionar el hecho que solo hacen falta las imágenes de sprites en una dirección (e invertir las de la otra dirección) o incluso, en muchos casos, partir un sprite, cuando es simétrico, en dos, la parte izquierda y la derecha invertida (pero esto último no se suele hacer).

Lo del spectrum, sí, falta lo de las máscaras (que lo dejo para otro día, cuando hable de colisiones), pero evidentemente, como opción me refería a obligación, a igual que en las consolas, utilizar la memoria destinada explícitamente a los sprites también es una obligación.

Comentario por DonDepre

Este artículo en concreto debería yo usarlo como apoyo teórico a las tiras de sprites en las que colaboro 😛

Comentario por Eme A

El Spectrum tiene 15 colores, y no 8, son los 8 colres primarios: Blanco, Azul, Rojo, Morado, Verde, Cyan, Amarillo y Negro, asi como los mismo 7 primeros colores listados con cambio de luminosidad, salvo el negro que no tiene color con brillo, por lo que se necesitarian 24.576 bytes, el 50% de la memoria maxima de un Spectrum, y faltaria RAM para los Spectrum mas basicos, aparte del precio astronomico de tener un ordenador con esa cantidad de memoria grafica, en los que el ordenador incluida memoria grafica y para usar disponia de 16 KB, quednado libre 9.25 KB, esceptuando variables del sistema.

Bitmap 256*192 =6144 bytes
Color 32*24 = 768

40×25, 80×25, 40×50 y 80×50 son resoluciones de ordenadores PC para modos de texto que no tienen nada que ver con un Spectrum, a lo sumo 42×24, que usaban algunos programas, con fuentes e letra de 8×6 en vez de las normales de 8×8

Comentario por Z80user




Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s



A %d blogueros les gusta esto: