Este pseudocodigo muestras las operaciones a realizar. La primera vez que se ejecuta la orden 2º no tiene mucho sentido, pues aun no se ha dibujado el personaje en pantalla, pero en conjunto funciona (¿Qué pseudocodigo no funciona?).

Bien, pues llegados a este punto tenemos a nuestro personajes moviéndose por pantalla, de izquierda a derecha, en un fondo negro. Sin embargo, muy pocos juegos usarían un fondo de un solo color, en realidad ninguno. En vez de eso, nuestro personaje debería estar caminando sobre una carretera, un edificio, sobre un cielo azul de nubes blancas o sobre el mar y tal como esta por ahora nuestro personaje al borrar la imagen en el paso 2º también borraría el dibujo de fondo con lo que nos encontraríamos con un problema ¿Qué hacer?, pues sencillo, en vez de machacar el fondo de la pantalla con un cuadrado en negro, lo que hacemos es guardar el fondo en memoria antes de dibujar nuestro personaje y cuando este vaya a cambiar de posición, dibujar de nuevo el fondo guardado donde estaba, aquí tenemos la modificación al pseudocodigo para que realice esta ultima función de guardar el fondo:

1. Posición = 0
2. Si hay fondo guardado en memoria lo pinto en la posición Posición.
3. Aumentamos Posición en dos unidades
4. Antes de imprimir guardo la zona del fondo donde voy a imprimir en memoria para mas tarde poder restaurarla
5. Dibujo a nuestro personaje
6. Se repiten las operaciones desde 2 a 6 hasta que se pulse una tecla
7. Fin

Como se puede observar solo hemos insertado una nueva función, la de guardar el fondo de la pantalla, en memoria y hemos sustituido el dibujar un cuadro en negro por dibujar lo que habíamos guardado en memoria.

Ahora sí que nuestro personaje puede moverse por cualquier tipo de pantalla, tenga un fondo en negro, multicolor o como queramos. El siguiente paso que vamos a ver es cómo, además de este movimiento, el sprite debería tomar diferentes formas para conseguir un movimiento mas real, es decir, imaginemos a nuestro personaje visto lateralmente, si solo tuviera una imagen parecería como si flotara en pantalla, en vez de eso podríamos dibujar a nuestro personaje en distintas posiciones, por ejemplo, moviendo piernas y brazos con lo que conseguiríamos un mejor movimiento.

Un sprite lo forma, como mínimo, un Frame. Según eso podemos decir que contra mas Frames tenga el sprite, mejor estará definido el movimiento. Cuando dibujamos el sprite, en realidad vamos dibujando las distintas posiciones de éste por pantalla, se suele usar un contador de frames que indica por cuál vamos, es decir, qué frame del sprite toca dibujar. En nuestro ejemplo, tenemos un sprite con 5 frames que se ejecutan cíclicamente de izquierda a derecha. Del uno al cinco y de vuelta al uno. Pero no tiene por qué ser todos los sprites cíclicos, por ejemplo, el caso de una explosión debería mostrar cómo al principio una pequeña masa blanca crece convirtiéndose en amarilla y roja hasta desaparecer. Ese tipo de efecto seria un sprite en pantalla que mostraría sus frames por orden pero tan solo una vez.

Bueno, y una vez que tenemos pensado que sprites va a necesitar nuestro juego (nuestro personaje, los malos, explosiones, etc. ), ¿cómo los dibujamos? y más importante aún ¿cómo lo guardamos para que nuestra aplicación pueda usarlos?. Pues para estas preguntas hay varias respuesta que paso a explicar.

Esta opción se basa en dibujar con nuestra herramienta de dibujo preferida los frames del sprite y después guardarlos todos en un archivo gráfico. La mayoría de juegos que usan este método adoptan los PCX aunque no todos (y no voy a explicar ahora el por qué este formato es idóneo para estas imágenes). Pero además de que el fichero contenga la imágenes, éste debe tener una estructura definida por nosotros para que podamos localizar rápidamente, en la imagen, dónde se encuentra el frame que buscamos. Para ello podemos optar en dividir el gráfico en celdillas. En cada una de estas celdillas, colocaremos un frame del sprite. Algo así, he hecho con la demo de estos artículos; he divido el archivo PCX en celdas de 64x64 pixel, o sea, que cada uno de mis frames empiezan en múltiplos de 64, el primero en la 0, el siguiente en el 64, el tercero en 128, y así hasta el quinto.

Este método suele ser el mejor que podemos adoptar por varias razones. La primera seria que hay multitud de herramientas en el mercado para dibujar nuestros sprites en cualquier formato, PCX, BMP, JPG, etc. Otra gran ventaja es que estos tipos de gráficos ya tienen incorporado un sistema de compresión como puede ser el RLE del PCX, con lo que ocuparán menos en disco. Como única desventaja puedo destacar que estos ficheros no han sido diseñados para construir sprites y que pueden tener algunas pegas a la hora de aprovechar el espacio, es decir, en nuestro ejemplo decidí dividir las celdas entre 64 para que el tamaño del PCX (320x200) me diera para incluir 5 frames, sin en vez de un tamaño de 64 tuviera que haber elegido uno de 60x60, existiría espacio no usado por el sprite, y para poner un ejemplo mas claro, mirad todo el espacio que desaprovecho en el PCX de nuestro personaje, tan solo he utilizado los 64 pixel altos de los 200 que disponía la altura de la imagen.

Esta opción también es muy usada aunque necesita de un mejor nivel para llevarla acabo. Se basa en la construcción de nuestro propio tipo de gráfico sprite. Aunque no quiero hablar mucho sobre el tema, pues en próximos números de Macedonia hablaremos sobre él (incluso en la construcción de nuestro propio editor de sprites), adelantare algunas ideas. Para realizar esta 'proeza', deberíamos primero en pensar el formato del fichero, por ejemplo, debería tener una cabecera donde indicara el tamaño en pixel de cada imagen, el tamaño en x y en y, el numero de frames, paleta adicional, nombre, etc. después de esta cabecera, vendrían los frames uno por uno. Entonces este formato creado tendría que ser usado en nuestros programas, e incluso estaría bien crear herramientas de conversión entre archivos gráficos comunes como los PCX y nuestro formato, a la inversa, y para finalizar aumentar nuestro fichero de sprites al concepto de librería de sprites, donde este nuevo fichero pudiera soportar varios sprites, del mismo modo que creamos una cabecera indicando cuantos frames tiene el sprite, ahora indicaríamos cuántos sprites tiene la librería, etc.

Todo esto que he comentado será expuesto mas extensamente con la elaboración de nuestro propio formato de sprite y nuestro propio editor de sprites, además de demostrar en un programa real (el editor) las técnicas antes comentadas sobre colores transparente, backbuffer, etc.. Todo ello llegara en nuestros próximos número. Por ahora os dejo con la demostración de este numero en C, que la disfrutéis :).

ÚLTIMA REVISIÓN EN ABRIL DE 1999