MINI-PROYECTO 1

CO-DISEÑO DE SPACE INVADERS EN

TARJETA SPARTAN 3AN

Juan Diego Bolaños, Nixon Yesid Cardona

Grupo O1, Banco 2

DEFINICIÓN.

Space Invaders es un juego clásico para matar marcianos. El jugador controla una nave

espacial que puede moverse de derecha a izquierda o viceversa en la pantalla, tiene un botón

de disparo para destruir a los extraterrestres (que son de tres tipos, con forma de calamar,

cangrejo y pulpo) los cuales van acercándose conforme el juego avanza, el juego termina

cuando los invasores llegan a la nave o la nave defensora es destruida.

Cada cierto tiempo, aparece en la pantalla, en la parte superior, un platillo volador que se

mueve aleatoriamente de la misma forma que la nave del jugador, dicha nave no da una

puntuación definida, sino puntos extras en una cantidad aleatoria. Además se cuenta con

cuatro escudos de protección que se van destruyendo gradualmente con los disparos de

alienígenas y de la nave defensora.

BITÁCORA DEL PROYECTO.

Inicialmente se investigó y se tomó como base el juego en blanco y negro de la página

spaceinvaders.org en donde se observó con cuidado el comportamiento de los marcianos y

de la nave del jugador, notando varios estados en los objetos de pantalla mientras se movían,

como por ejemplo el movimiento autónomo de los marcianos y su explosión de dos pasos.

Se decidió dividir el código en dos partes, la primera seria conformada por el bloque de

gráficos que iba ser incluido con lenguaje VHDL, y consistiría de sub-módulos de ROM con

todas las imágenes y caracteres necesarios para el desarrollo.

La segunda parte incluía a la máquina de estados y el comportamiento (Inteligencia Artificial)

de los objetos, para de esta manera corresponder a los objetivos de la asignatura.

Se procede entonces a iniciar con el desarrollo completo en VHDL para asegurar el correcto

funcionamiento de todos los bloques y de la máquina de estados, se encontraron problemas

tales como dibujar los 55 marcianos, realizando los movimientos en su posición y a la misma

vez se movieran de manera horizontal y vertical.

Para facilitar el manejo del diseño gráfico se dividió la pantalla en cuadrantes de 16 bits, es

decir, transformando la pantalla de 640 x 480 a 40 x 30, sirviendo de referencia para las

posiciones de los elementos gráficos descritos en memoria y con dimensiones en base a

potencias de 2; para dibujar el gran número de marcianos y sus posibles estados se

construyendo una matriz (memoria RAM) de 11 x 5 que contenía en cada posición los estados

de los marcianos en base a una codificación que puede ser apreciada en la descripción a

continuación.

Así mismo se desarrolló el comportamiento de la nave, permitiendo su desplazamiento en el

eje horizontal, los muros los cuales también tenían estados y se almacenaron en una memoria

ram. las vidas que se muestran como otras naves defensivas y que deben ir aumentando o

disminuyendo en base a un valor ingresado por la máquina de estados y el OVNI que se

desplaza horizontalmente en lo más alto del área.

Todos estos elementos fueron realizados y para su prueba se conectó las señales de control a

valores adecuados en la descripción para observar su comportamiento en pantalla.

Sobre el diseño del score y hi-score se realizó su correspondiente diseño gráfico, sin embargo

para la implementación no se alcanzó a realizar el multiplexor que escogía los valores para

cada marciano según la destrucción.

Sobre el desarrollo de la gestión de disparo y la destrucción, no se logró realizar el objetivo

propuesto por falta de tiempo, debido a la cambio en la característica de comparación sobre

el diseño hecho en base a las posiciones de la matriz 40 x 30, para solucionar este

inconveniente se necesitaba comparar todo el vector de 10 bits correspondiente a x y y, en la

posición de cada figura, pero no se logró compilar una versión funcional de esta característica

en el juego.

Por último el diseño del procesador en picoblaze (máquina de estados y comportamientos)

no logró ser terminado por la importancia en las interrupciones del módulo anterior,

generando un comportamiento errático en el programa en las versiones que se intentó adaptar.

DESCRIPCIÓN DE BLOQUES

ASCII (American Standar Code for Information Interchange).´

Este bloque contiene un código de caracteres basados en el alfabeto latino que son utilizados

en el juego. El código utiliza 8 bits para representar los caracteres.

Hay 128 caracteres ASCII imprimibles.

Al bloque ingresa una señal de reloj, una señal addr, quien se encarga de buscar el carácter

deseado por medio de la dirección de la ROM; y sale la señal data, que es la letra o símbolo

que se utiliza y se llama por medio de la dirección.

TEXTO FIJO

Este bloque se encarga de mostrar los caracteres específicos del juego, como por ejemplo la

palabra SCORE, la puntuación, etc. esta acción se realiza por medio de una serie de

codificadores, que des-encripta el código ASCII y lo convierte en un objeto. A este módulo

ingresan una señal de enable que se encarga de habilitar la señal de figura que lleva la

información del elemento de salida, clk que es el reloj y pixel-x y pixel-y que recorren pixel

por pixel de la pantalla indicando que bit pertenece a determinada imagen y que bit no

pertenece.

VGA

En esta parte se sincronizan las imágenes del juego con una pantalla con conexión VGA

disponible, la resolución establecida en este código es de 640x480. A este bloque ingresan la

señal clk que es el reloj, rst que es el reset y salen todas las señales que necesita el periférico

del VGA para que funcione correctamente (h_sync, v_sync, x_pixel, y_pixel, video_on).

MARCIANO 4

En este módulo se desarrolla el graficado de los objetos así como sus movimientos y los de

otros elementos en base a señales externas o internas, dependiendo del tipo de movimiento.

Cada tipo de marciano creado en la ROM son llamados para crear una matriz de 11 x 5 = 55

objetos en una RAM donde se controla el estado de cada uno de estos, teniendo en cuenta

que cuando se comprueba el impacto del disparo hace cambiar el estado de la posición de la

RAM donde se detectó esta colisión. Es necesario aclarar que solo necesita de una

comprobación para iniciar los cambios de estados.

Estados

11 Marciano completo.

10 Primera explosión.

01 Segunda explosión.

00 Queda vacía la posición de la RAM.

Los muros defensores están compuestos por 4 cuadrados descritos en la ROM que se

encuentra en el módulo OVNI, funciona de una manera similar a la destrucción de los

marcianos, donde se comprueba cada impacto de los disparos para cambiar a un estado

diferente, es decir, se necesitan de 4 disparos para destruir un cuadrado del muro, para un

total de 16 disparos para destruir esta defensa en su totalidad.

Estados.

11 Cuadrado completo.

10 Estado 1 de destrucción.

01 Estado 2 de destrucción.

00 Destruido.

Se genera el movimiento del ovni que aparece en la parte superior de la pantalla con un

contador generado en el código, limitándolo en “x” y en “y”, para que solo se mueva en “x”

y cuando llegue a los limites en “y” este objeto desaparezca del juego y solo volverá a

aparecer cuando se mande un habilitador del procesador, el cual tiene sus propias condiciones

para ser habilitado.

En el juego se puede observar que cuando los marcianos están activos estos cambian de

estado de tal forma que parece que se mueven, esta acción es realizada tomando el 5 bit más

significativo el cual es la mitad de un desplazamiento de 16 bits para los enemigos, con este

bit se modifica la dirección de memoria donde está la figura, obteniendo como resultado un

movimiento de las extremidades de los marcianitos cada vez que estos se mueven en x o en

y.

Para el movimiento de la nave defensora se asignan enables que activan contadores hacia la

izquierda o hacia la derecha según se escoja en el juego, limitando el movimiento a todo el

eje x y dos límites (izquierdo y derecho) en el eje y para impedir que la nave se desaparezca

de la pantalla.

La gestión del disparo consiste en primero identificar la posición actual de la nave del jugador

y guardarla para que el disparo salga de forma vertical desde dicha posición en “x”, el disparo

es generado en una ROM, luego debería comprobar bit a bit donde se encuentra un 1 del

muro o de los marcianos y comprobar y cambiar los estados del objeto con que haga contacto.

Las vidas son programadas con un contador que se habilita cada vez que se destruyen todas

los marcianos en su totalidad (no es necesario destruir el ovni), estas no tienen límite de

conteo, pero se van a acumular hasta que haya desbordamiento y no se puedan mostrar en la

pantalla.

Por último se multiplexan todas las imágenes generadas en el juego y se vuelven en señales

que luego se utilizan para el RGB.

OVNI

Es una ROM donde se guardan las formas de las figuras de los marcianos, las explosiones,

la nave, ovni y los muros que defienden la nave. Contiene una señal que se le ingresa llamada

addr, la cual es el código con el que se identifica la imagen necesitada en ese instante de

juego.

FIGURAS DISEÑADAS EN VHDL.

Marciano 1, primera posición.

Marciano 1, segunda posición.

Marciano 2, primera posición.

Marciano 2, segunda posición.

Marciano 3, primera posición.

Marciano 3, segunda posición.

Explosión 1.

Explosión 2.

Nave jugador.

Nave ovni.

Las demás figuras (letras, números, etc.), se encuentran en una memoria ROM tipo ASCII

dentro del programa. Por medio de la variación en la sincronización con el VGA, se leen y

realizan figuras correspondientes y la variación de las mismas según la situación.

TOP MODULE.

En esta última parte, es donde se instancian todos los bloques anteriormente explicados y

donde se genera la señal RGB para ser mostrado el juego en la pantalla.

PICOBLAZE.

En el procesador se incluyó parte de la inteligencia artificial de los marcianitos y también la

máquina de estados con que funciona el juego realizado. Sin embargo en la versión

implementada no está finalizado y su funcionalidad no es correcta.

INCONVENIENTES EN EL PROYECTO.

En la gestión del disparo no se pudo verificar el momento de la colisión de este con algún

otro objeto en la imagen, debido a que el diseño fue realizado en base a 16 bits, es decir, se

tenía que reconstruir las señales de pixel-x y pixel-y para comprobar bit a bit la presencia de

un 1, además la imagen del disparo fue generada con una matriz de 16x8 bits lo que complica

aún más dicha comprobación.

El SCORE que se necesita para el juego con tiene demasiados dígitos, lo cual su lógica se

complica cuando se quiere introducir al procesador, debido a la poca capacidad de este.

Uno de los problemas claves es adaptar el procesador a la descripción realizada, debido a la

lógica de entrada y de salida que mostraron un comportamiento inesperado y no se logró

llegar al correcto funcionamiento.

La integración con el procesador de 8 bits no logró ser completada, siendo necesaria la

máquina de estados para un juego completamente funcional.

La escritura en la memoria RAM para marcianos y muro es otro de los elementos no

implementados debido la falta de una gestión de disparo y máquina de estados funcional.