Diario de una Demo en CPC

1a sesión

Esta sesión fue casi toda remota ya que cada uno la hizo en su casa y tan solo al final quedamos para una puesta en común de lo q habíamos aprendido…

Lo primero q hay q plantearse es como trabajar y dadas las facilidades q daba un emulador de CPC para Win32 q se llama WinAPE (assembler y debugger incorporados tipo Maxam y poder reiniciar la maquina en menos de 2 segundos), pues hemos decidido programar en emulador toda la base y luego retocar en la maquina real.

Dentro de esta primera sesión tambien entra la inevitable búsqueda de información técnica de la maquina que, en este caso, es el CPC de Amstrad. Para esta tarea, contamos con el todopoderoso Google y con nuestra gran paciencia.

Y que es lo que encontramos? pues muuuuuchos juegos, muchas paginas que no van pero también unos bonitos y útiles pdfs que describen el firmware del CPC así como unas imprescindibles imágenes de disco .dsk con diskmags y documentos mas interesantes si cabe...

Después de un par de lecturas sobre assembler de Z80 y algunos efectos gráficos típicos y, como no! después del tradicional "Hello World!", surge el segundo paso para llegar a nuestro objetivo:

Poner un punto en pantalla.

2a sesión

Bien, como ya sabéis de la anterior sesión, ahora se trata de poner un punto en pantalla. El CPC tiene una serie de rutinas de serie llamadas "firmware" q sirven para hacer un poco mas fácil la programación pero q son muuuuuuuuuuuy lentas... bueno, por lo menos en el apartado grafico.

Solución: Pintar directamente a memoria de video.

Una miradita a la documentación del hardware y 2 horas y media para entender como van los distintos modos de video (si, es q somos un poco lentos).

Al final de la noche de otro día dedicado al CPC sabemos q la memoria de video del CPC ocupa los 16k del bloque superior de los 4 que tiene el CPC o sea, q va desde la posición #C000 hasta la #FFFF y que esta rellenada por líneas pero no seguidas sino con saltos de 8 en 8 (o sea por caracteres). así pues, si leemos la memoria linealmente, nos encontramos las línea 0, 8, 16, 32, etc. hasta la 192 y luego vuelta arriba a por las 1, 9, 17, 33, etc. hasta la 193 y así hasta las 200 líneas de resolución vertical que tiene (25x8=200).

Cada línea consta de 80 bytes con lo que se llega a una resolución de 160 puntos y 16 colores en modo 0, 320 puntos y 4 colores en modo 1 y 640 puntos y 2 colores en modo 2.

La selección del color la vimos muy chunga a esas horas de la madrugada y la dejamos para otro día... o sea, para la tercera sesión.

3a sesión

Desde la ultima sesión, ya sabemos como va mas o menos el mapa de memoria de video pero... y los colores?

Pues bien, si tenemos 2 píxeles por byte en el modo 0 (q es el q intentamos usar), disponemos de 4 bits por color, lo q nos ofrece un máximo de 16 colores. Para el punto de la derecha se usan los bits pares (0,2,4,6) y para el de la izquierda los impares (1,3,5,7) pero... todavía es mas complicado porque se ordenan 0,4,2,6 y 1,5,3,7 así, si quisiera usar el color 3 en el píxel derecho, pondría a 1 el bit 4 del byte correspondiente lo cual en binario representa un 8 realmente.

Con una bonita tabla del Excel, buscamos el equivalente del 1 al 16 con los bits intercambiados con lo cual, ya no había excusas... ahora tocaba pelearse con el assembler...

Después de un F6 en el magnifico WinAPE, ya tenemos nuestro assembler esperando instrucciones. Copiamos la tabla con las posiciones de memoria y las definiciones de nuestros colores; movemos uno de estos números a la posición 80, 100 (el medio de la pantalla) y... funciona! Tanto la rutina de posicionamiento en los ejes de coordenadas como la tabla de colores están bien salvo un pequeño bug q se resuelve en segundos:

Ya tenemos la rutina de "put píxel".

Como secuela de lo anterior y para probar si realmente funcionaba bien el "put píxel", no podía faltar una prueba de llenado de pantalla. Un simple bucle y voila! Pantalla entera pintada… y ahora… que mas?

Pues ahora toca pensar efectos y funciones q nos puedan servir cuando hagamos la demo... y el primero es... cargar un grafico.

4a sesión

Ahora toca cargar gráficos señores... después de un rato de imprescindible documentación y búsquedas en Google, MadGoblin encuentra un par de programas rarísimos para convertir imágenes al formato CPC pero estos no son lo suficientemente prácticos.

Se trata de hacer posible q un grafista del grupo, con su Photoshop o con cualquier programa q grabe en formato RAW, pueda trabajar y aportar contenido sin complicarse la vida ni el ni nosotros.

Al final, Mad (MadGoblin) opta por hacerse su propio conversor en Ansi C (portable y tal, ya sabéis...) y una vez hecho el programa y con una lista de los colores RGB de la paleta del CPC, ya podremos pedir cositas a los grafistas que se presten a ello :P

Pero... sabiendo q el CPC tiene una paleta de 27 colores y q en modo 0 solo se pueden usar 16 a la vez... como se cambia la paleta del CPC?

En la próxima sesión quizás nos de por intentar descubrirlo... o no! XP

5a sesión

Bien, la verdad es que esta sesion es un compendio de varias de ellas (el que escribe tiene curro y no todos los dias uno tiene tiempo de ponerse a escribir :P).

En la 4a sesion, nos propusimos definir la paleta de colores y tras mirar un par de ejmplos que corren por internet lo conseguimos sin muchos problemas y de paso, descubrimos que esos programas que al principio no nos servian si que nos serian utiles para hacer conversiones de graficos y adaptar paletas...

El siguiente paso natural era comprender como se podia cargar un grafico en pantalla y tampoco fue mucho problema ya que tan solo se trata de volcar el gtrafico a la memoria de video con lo cual...ya tenemos graficos y paletas :)

Llegado este punto, nuestro coder de CPC, usease...MadGoblin, quiso hacer un pequeño "slideshow" con musica. La musica es algo que todavia no habiamos mirado...si que sabiamos de un par de trackers para CPC pero el que nos convenció finalmente fué el Starkos: un tracker que, a parte de estar muy currado en cuanto a opciones de edicion de samples y patrones, venia con un conversor de modulos a formato binario y el codigo del player de musica para poner en la demo y...claro...con estas facilidades...cualquiera se niega a utilizarlo! XD

Con graficos y musica resueltos nos queda una parte relacionada con los graficos que son los sprites. Los sprites son porciones de graficos que se sobreimpresionan en el fondo y que tienen que moverse a una velocidad aceptable. Los usaremos para poner textos y mostrar elementos graficos en pantalla sin tener que cargar un grafico para cada fotograma lo cual seria muy lento y consumiria muuuuucha memoria y, a parte, seria un video que no es lo que pretende ser una demo. Ya tenemos algo hecho pero todavia falta depurar algunas cosas como moverlos y limpiar pantalla cuando haga falta.

Mientras se miraba lo de los sprites...para descansar un poco MadGoblin tambien se miro un poco como podia sincronizar los efectos con el sonido y tambien lo logro (es un hacha el tio! :P). De momento sincronizaremos mediante el bombo hasta que encontremos otra forma que sea mejor.

Y ahora que? Pues ahora tocan los efectos. Una buena demo tiene que tener sus efectillos resultones que marquen la diferencia con las otras demos. Para esta primera demo y ya que estamos aprendiendo...hemos pensado hacer un par de efectos clasicos como el fuego o el starfield ya que son unos de los mas faciles aunque cualquier efecto en una maquina como el CPC re`representa un gran reto debido a su limitada capacidad. Ya veremos lo que sale.

by Silenci/Zon@ Neutr@ - Utima actualización: 23 de Febrero de 2004