Ya llega a vuestra web favorita la cuarta parte del Taller de los Mojon Twins para aprender a usar la Churrera. En este capítulo aprenderemos a crear nuestros sprites. Si has llegado hasta aquí ya tienes los elementos necesarios para avanzar considerablemente en tu futuro juego de Spectrum. ¿Qué bien suena, eh? Bueno, vamos allá que nos consta que tienes ganas de seguir con el Taller.
Capítulo 4: Sprites
Antes que nada, bájate el paquete de materiales correspondiente a este capítulo pulsando en este enlace:
http://www.mojontwins.com/churrera/churreratut-capitulo4.zip
¿Qué son los sprites?
A estas alturas del cuento, si no sabes lo que es un sprite, mal vamos… Y no, no voy a hacer la típica gracia de la bebida carbonatada, (jajá, jijí, qué graciosos somos, los reyes de la fiesta, tralarí, alocados, divertidos, amigos de nuestros amigos). Sin embargo, como este capítulo va sobre sprites, habrá que empezar explicando que son. Por si no lo sabes, se trata de una de las leyes de los tutoriales de videogüegos. No importa de qué nivel sean o sobre qué sistema traten: es obligatorio explicar qué es un sprite. Lo manda su eminencia ilustrísima Paco Perales, el papa de los tutoriales.
Pulsa aquí para seguir leyendo…
Veamos: el concepto de sprite, realmente, no tiene absolutamente ningún sentido en sistemas como el Spectrum, en el que la salida gráfica se limita a una matriz de píxels. Absolutamente ningún sentido. Sin embargo, se emplea por analogía. Elaboremos: tradicionalmente, un chip de gráficos diseñado para funcionar en una máquina de güegos manejaba dos entes, principalmente: el fondo y un cierto número (limitado) de sprites. Los sprites no eran más que puñados de píxels, normalmente cuadrados o rectangulares, que el procesador gráfico se encargaba de componer sobre el fondo a la hora de enviar la imagen al monitor o la TV. Esto es: se trataba de objetos completamente ajenos al fondo y que, por tanto, podías mover sin afectar a éste. La CPU del sistema no tenía más que decirle al procesador gráfico dónde estaba cada sprite y olvidarse, ya que dicho procesador gráfico era el que se encargaba de construir la imagen enviando al monitor píxels de sprite en vez de píxels de fondo cuando era necesario. Es como si los muñequitos no estuviesen realmente ahí, de ahí su nombre: la palabra “sprite” significa “hadas” o “duendecillos”.
Casi todas las videoconsolas de 8 y 16 bits (las de Nintendo y SEGA por lo menos, que los sistemas de Atari eran raros de narices), el MSX y el Commodore 64, entre otros sistemas, tienen un procesador de gráficos de verdad que hace fondos y sprites.
En ordenadores como el Spectrum o el Amstrad CPC, o cualquier PC, el concepto de sprite no tiene sentido. ¿Por qué? Pues porque el hardware sólo maneja una matriz de píxels, lo que sería equivalente a sólo manejar el fondo. En estos casos, los muñequitos tiene que pintarlos la CPU: tiene que encargarse de sustituir ciertos píxels del fondo por píxels de los muñequitos. Además, el programador debe currarse algún método para mover los muñequitos: debe poder restaurar la pantalla a como estaba antes de pintar el muñequito y redibujarlo en la nueva posición. Sin embargo, por analogía, a estos muñequitos se les llama sprites.
Nosotros les llamamos sprites, y eso que a veces somos unos puristas de la hostia (purista significa frikazo).
Sprites en la Churrera
La Churrera maneja cuatro sprites de 16×16 píxels para bicharracos (incluido el personaje que maneja el jugador) y generalmente hasta tres sprites para proyectiles (en los güegos de matar). Los sprites de los bicharracos se dibujan usando los gráficos que podemos definir en lo que se conoce como el spriteset. Dicho spriteset contiene 16 gráficos, de los cuales 8 se usan para animar al personaje principal y 8 para animar a los 4 tipos de enemigos (2 para cada uno, si se te dan bien las matemáticas). Un spriteset tiene esta pinta (este es el spriteset del Dogmole):
Como verás, siempre hay un gráfico de un muñeco y al lado hay una cosa rara justo a su derecha. Vamos a explicar qué es esa cosa rara antes de seguir. En primer lugar, no se llama cosa rara. Se llama máscara. Sí, ya sé que no se parece a una máscara ni de coña, pero se llama así. Tampoco los ratones de ordenador parecen ratones ni el gráfico de Horace parece un niño y no he visto a nadie quejarse todavía. La máscara se usa para decirle a la biblioteca gráfica (en este caso, splib2), que es la que se encarga de mover los sprites (recordad que “esto es Spectrum y aquí hay que mamar”: no hay chip gráfico que haga estas cosas), qué píxels del gráfico son “transparentes”, esto es, qué píxels del gráfico NO deben sustituir los píxels del fondo.
Si no hubiera dicha máscara, todos los sprites serían cuadrados o rectangulares, y eso queda bastante feo.
Nosotros hemos ordenado nuestro spriteset de forma que cada gráfico tiene su máscara correspondiente justo a la derecha. Si te fijas, las máscaras tienen píxels negros en las zonas donde debe verse el gráfico correspondiente, y píxels de color en las zonas donde debe verse el fondo. Es como si definiésemos la silueta.
¿Por qué son necesarias las máscaras? Si eres un poco perspicaz lo habrás adivinado: en Spectrum los gráficos son de 1 bit de profundidad, lo que significa que cada píxel se representa usando un solo bit. Eso se traduce en que sólo tenemos dos posibles valores para los píxels: encendido o apagado (1 o 0). Para poder especificar qué píxels son transparentes necesitaríamos un tercer valor, y eso no es posible (¡es lo que tiene el binario!). Por eso necesitamos una estructura separada para almacenar esta información ¡la máscara! ¡las máscara molan!.
Construyendo nuestro spriteset
Antes de construir el spriteset es muy importante saber qué tipo de vista tendrá nuestro güego: lateral o genital. Supongo que, llegados a este punto, es algo que ya tenemos decidido (vaya, si ya hemos hecho el mapa). El orden de los gráficos en el spriteset depende del tipo de vista de nuestro güego.
Spritesets de vista lateral
Para los güegos de vista lateral, los 16 gráficos de 16×16 (acompañados por sus máscaras) que componen el spriteset tienen que tener este orden:
Como vemos, los ocho primeros gráficos sirven para animar al personaje principal: cuatro para cuando mira a la derecha, y otros cuatro para cuando mira a la izquierda.
Tenemos tres animaciones básicas para el personaje: parado, andando, y saltando/cayendo:
Parado: La primera es cuando el personaje está parado (como su propio nombre indica). Parado significa que no se está moviendo por sí mismo (si lo mueve un ente externo sigue estando “parado”). Cuando el personaje está parado, el motor lo dibuja usando el frame 2 (gráfico número 1 si mira a la derecha o 5 si mira a la izquierda).
Andando: Es cuando el personaje se desplaza lateralmente por encima de una plataforma. En ese caso se realiza una animación de cuatro pasos usando los frames 1, 2, 3, 2, … en ese orden (gráficos 0, 1, 2, 1… si miramos a la derecha o 4, 5, 6, 5… si miramos a la izquierda). A la hora de dibujar, el personaje deberá tener ambos pies en el suelo para el frame 2, y las piernas extendidas (con la izquierda o la derecha delante) en los frames 1 y 3. Por eso usamos el frame 2 en la animación “parado”.
Saltando/Cayendo: Es cuando el personaje salta o cae (joder, ¡menos mal que lo he aclarado!). Entonces el motor dibuja el frame “saltando” (gráfico número 3 si mira a la derecha o número 7 si mira a la izquierda.
Los siguientes seis gráficos se usan para representar a los enemigos. Los enemigos pueden ser de tres tipos, y cada uno tiene dos frames de animación.
Para acabar, los dos últimos gráficos se usan para las plataformas móviles, que también tienen dos frames de animación. Las plataformas móviles son, precisamente, y como su nombre indica, plataformas que se mueven. El personaje principal podrá subirse en ellas para desplazarse. Para dibujar los gráficos tenemos que cuidar que la superficie sobre la que se debe posar el personaje principal debe tocar el borde superior del gráfico.
Para que quede claro, veamos algunos ejemplos:
El spriteset de arriba corresponde al Cheril Perils. Como vemos, los ocho primeros gráficos son los correspondientes a Cheril, primero mirando a la derecha y luego mirando a la izquierda. Luego tenemos los tres enemigos que vemos en el güego, y al final la plataforma móvil. Fíjate bien en el tema de la animación de andar, imaginate pasar del frame 1 al 2, del 2 al 3, del 3 al 2, y del 2 al 1. Mira el gráfico e imagínatelo en tu cabeza. ¿lo ves? ¿ves como mueve las paticas? Ping, pong, ping, pong… Fíjate también como el frame 2 es el que mejor queda para cuando el muñeco está parado.
Este otro spriteset corresponde al Monono. De la misma forma, tenemos 8 gráficos para Eleuterio (¡qué guapo sale el joío, qué porte!), tres tipos de enemigos, y al final la plataforma móvil. Fíjate como siempre la superficie superior de la paltaforma móvil toca el borde superior del cuadro del sprite. Fíjate también en como está hecha la animación de andar de Eleuterio y como la cabeza está más baja en los frames en los que las piernas se extienden. Esto queda de la hostia de chulo.
Spritesets de vista genital
Para los güegos de vista genital, los 16 gráficos del spriteset tienen que tener este orden:
De nuevo, los ocho primeros gráficos sirven para animar al personaje principal, pero esta vez el tema es más sencillo: como tenemos cuatro direcciones en las que el personaje principal puede moverse, sólo disponemos de dos frames para cada dirección.
Los ocho gráficos restantes corresponden a cuatro tipo de enemigos, ya que en un güego de vista genital no hay plataforma móvil que valga.
Una vez más, para que quede bien claro, veamos algunos ejemplos:
Este es el spriteset de nuestra genial conversión de el Hobbit (uno de nuestros grandes honores: quedar los últimos en un concurso. Es casi mejor que quedar los primeros). Fíjate como el tema cambia: arriba tenemos 8 gráficos con 2 frames para cada dirección, y abajo tenemos cuatro tipos de enemigos en lugar de tres más las plataformas.
Este otro spriteset es el de Mega Meghan. Aquí volvemos a tener a la prota (Meghan, la asesina malvada) en las cuatro direcciones posibles con dos frames de animación para cada una en la tira superior, y a cuatro mujeres encueras (que hacen de enemigas) en la tira inferior.
Fíjate como, en este caso, nuestra vista genital la hemos diseñado con cierta perspectiva: cuando los muñecos van para arriba se dan la vuelta y cuando van para abajo miran de frente. Eso queda super chuli.
Dibujando nuestro spriteset
Nada más fácil que crear un nuevo archivo de 256×32 píxels, activar la rejilla para no salirnos, y dibujar los gráficos. Aquí tendremos que respetar una regla muy sencilla (o dos, según se mire). Para pintar gráficos y máscaras usaremos dos colores:
En los gráficos, el negro PURO es el color del PAPER, y el otro color (el que queramos, es buena idea usar el blanco) es el color del INK. Recuerda que los sprites tomarán el color de los tiles que tienen de fondo al moverse por la pantalla.
En las máscaras, el negro PURO es la parte del gráfico que debe permanecer sólida, y cualquier otro color sirve para definir las partes transparentes (a través de las que se ve el fondo).
En nuestros ejemplos verás que usamos un color diferente (además del negro) en gráficos y máscaras, pero es más que nada por claridad. Puedes usar los colores que quieras. Yo, personalmente, uso colores diferentes porque suelo pintar la máscara y el sprite en la misma casilla de 16×16, para luego seleccionar sólo los píxeles del “color máscara” y moverlos a la casilla siguiente. Es un truco que puedes aplicar si eres mañoso con tu editor de gráficos.
Una vez que tengamos todos nuestros gráficos y sus máscaras dibujaditos en el archivo del spriteset, lo guardamos como sprites.png en gfx y estamos listos para convertirlos en código C directamente usable por la Churrera.
Por cierto, vuelve a asegurarte que el negro que has usado es negro PURO. Todos los píxeles negros deben ser RGB = (0, 0, 0).
Convirtiendo nuestro spriteset
De nuevo tenemos entre manos un poquito de trabajo de ventana de linea de comandos. Usaremos otra utilidad de la Churrera la cual, como habréis podido adivinar, fue la tercera que hicimos: sprcnv.exe, el conversor de spritesets. Esta utilidad es realmente tontorrona y sencilla, y únicamente toma dos parámetros. Nos vamos a \gfx y ejecutamos:
..\utils\sprncv.exe sprites.png ..\dev\sprites.h
Ejecutando esto, y mediante un mágico y misterioso proceso, obtendremos un archivo sprites.h en nuestra carpeta dev. Y ya hemos terminado.
Jodó, ¿ya?
Sí, tío. El tema de los sprites era sencillo y tenía muy poca chicha… O al menos eso creo. Si crees que algo no queda claro ya sabes qué hacer: te aguantas. No, que es coña. Si crees que algo no queda claro simplemente pregúntanos. Pero tienes que poner voz de niña.
En el próximo capítulo vamos a explicar el tema de las pantallas fijas: el título, el marco del juego, y la pantalla del final. Hasta entonces, ¡a hacer sprites!
Vaya pdf final os va a quedar! Este capítulo me ha gustado mucho, lo de las máscaras algún día tengo que aprender a usarlas. Avanti cracks!
Ola k ase..sprites o k ase .. Jajaja he flipao o.O …que bueno.
Sois unos cracks…asi da gusto aprender
Genial como de costumbre!
Se hace muy ameno el seguir un curso así.
A la espera del PDF recopilatorio final de nuestros amigos de Mojonia, dejo este yo con los 4 cursos aparecidos hasta ahora, en un solo archivo y con índices para saltar al capítulo deseado.
http://www.putlocker.com/file/CA3C3D9C5D869D5B
Saludos!
Jarlaxe, tu PDF es un EXE que intenta hacer cambios en el equipo… DANGER!
Anda, que le he dado a otro DOWNLOAD! :O
Estos servidores de descargas con "trampitas" no deberían ser usados…
Que susto me has dado Josepzin!!!
Si, la verdad es que la mayoría de los host de descargas de archivos suelen tener esas "trampas" 🙁
Y ahora despues de leerme detenidamente el capítulo de hoy… preguntita para nuestros profes.
La verdad es que 3 enemigos, me parecen bastante poco variados.
Si en lugar de usas sprites animados con dos frames, usamos una sola imagen estática a modo de enemigo, ¿se podría llegar a tener el doble de "mostrus"?
Quedaría más rústico el güego, pero con más variedad.
O la churrera está diseñada para aceptar ese diseño de "plantilla" de sprites, y si nos salimos de ahí, ¿corremos el riesgo de descuajeringar la churrera?
Saludos!
Otra vez el pesao de turno.
Perdón por el doble post (como echo de menos el botón Edit en esta página) XD
Me he dado cuenta, que en el Dogmole, cuando aplastamos a un mago, aparece una especie de nubecilla de polvo o algo así.
Esa nubecilla, no aparece en el spriteset ni en el tileset (ni tan siquiera en el tileset de extras)
Donde anda esa imagen para poder editarla?
Graciassss!
Amigo jarlaxe, para ese efecto al morir el bicho tendrás que esperar algún capitulillo… pero puedes hacerte un tile de 16×16 con el efecto que ya te diremos dónde ponerlo.
Sobre los sprites, la cosa es que más de 3 y personaje por pantalla queda mal, así que preferimos tenerlos con animación. No obstante, entrando en el código no creo que sea muy complicado tener más personajes de 1 frame y poder colocarlos. Pero la churrera está preparada para este número. 😀
En efecto, como dice Anjuel este tema está fijado en el motor, y para cambiarlo habría que tocar código en C. Quería dedicar algunos capítulos al final del curso a las modificaciones a pelo del propio engine, me apunto el tema que sugieres para uno de los ejemplos. No es nada complicado, pero hay que cambiar el motor.
De coña marinera profes!
Si lo vemos al final como un extra ya me está bien! 🙂
Anjuel, mi idea no era saturar una sola pantalla con todos los bichos a la vez, si no, repartirlos por el mapeado por zonas para dar más variedad 😉
Voy a ir dibujando el tile de la "explosión" para cuando muere el enemigo. Así lo tengo preparado cuando lleguemos a ese punto.
Gracias por todo chicos!
¿Entonces solo se pueden crear 3 enemigos para todo el juego o se pueden crear otro set e intercambiarlos? Estaría muy chulo poder hacer eso, de esa forma se puede incluso cambiar el personaje y los enemigos por ejemplo para entornos marinos 🙂
La memoria manda y cada gráfico y su máscara ocupa 144 bytes. Eso significa que sólo en el spriteset que usamos ya se nos van 2304 bytes. Todo suma, y los apenas 30Kb que tenemos para nosotros (restando runtimes y buffers necesarios) se acaban rapidísimo.
En principio no es posible cambiar el spriteset al vuelo tal y como está programado el motor, pero todo puede alterarse. El código fuente está ahí para que metáis toda la mano que queráis.
Hemos sacado más de 20 juegos con ese número de enemigos, creo que es más que suficiente, aunque me plantearé el cambio de spriteset según la zona del mapa como extra, para el final.
Podría hacerse de varias maneras. De hecho, (y ya estoy adelantando acontecimientos) el motor está preparado para tener varios niveles comprimidos, cada uno con su tileset, su spriteset y su mapa. Además, tal y como está construido, llevar el motor a los 128K y disponer de las páginas extra de RAM como almacenamiento es muy sencillo.
Pero, como dicen los ingleses, first things first. Creo que es mejor empezar sencillo e ir complicándose poco a poco, juego a juego.
Por supuesto na_th_an!!
Las cosas se han de aprender por el principio y poco a poco, y más en mi caso, que tengo nastante poca idea de estos menesteres.
Es el ansiavivaaaa que nos puede. jejeje
Gracias por vuestro tiempo y esfuerzo compañeros!
…mensaje eliminado por expreso deseo de su autor…
Se me va acumulando!!!
Enhorabuena por el trabajo que estáis haciendo.
Tremendas las posibilidades. Sí es cierto que se podrían añadir nuevas funcionalidades pero creo que de momento es una pasada todo lo que se puede hacer.
Sigo preparando el mio. Va para largo pero os sorprenderá. 🙂
…mensaje eliminado por expreso deseo de su autor…
@SPC: Suelta prenda "mardito roedooooó"!! XD
Que será? algo relacionado con la página?
El mío ya podéis ver por donde va tras mi cambio de avatar 😉
Sorry por el doble post, pero como no se puede editar… 😉
@spc: ve planteandote hacer un concurso de creación de güegos con la churrera una vez se finalice el taller!
Ahí lo dejo caer… 😛
Jarlaxe: lo del tema de un concurso es buena idea… anotada! respecto al PDF que te estas currando me parece de 10.
Uyyyy! que esta semana nos habéis dejado sin nuestra dosis de tutorial! 🙂
Genial el tema de los sprites. A la espera de la proxima entrega.
Jarlaxe, es sorpresa. Si lo digo se pierde el "hype"… 🙂 Respecto al concurso me parece muy buena idea. Como ha dicho Javi, tomamos nota.
El capítulo 5 está terminado, enseguida estará disponible 🙂
Perdón por la tardanza, pero el verano aminora la marcha 😀
Muchas gracias!
Lo espero como agua de mayo! 😉
Me parece genial la idea del concurso de juegos hechos con la churrera. Por el momento, hasta un torpedo de la programación como yo puede seguir el curso, así que sólo puedo decir… ¡¡¡Sois cojonudos!!!
Hola!
Gracias por este magnífico tutorial que estoy siguiendo al dedillo!!!!
El caso es que llegado a este capítulo, me gustaría que me resolvierais una duda que tengo ¿es posible hacer gráficos más grandes? Me explico, podría usar sprites para hacer unas patas andando que la usarían todos los gráficos (los buenos y los malos), y sobre esas patas "montar" el tronco de los distintos personajes.
Así los gráficos serían más grandes (no en plan Trap Door, pero con algo más de resolución)
Saludos!!!
Errata de nuevo en la llamada a la util. Donde dice:
..utilssprncv.exe sprites.png ..devsprites.h
Debería decir:
..utilssprcnv.exe sprites.png ..devsprites.h