artículo
Entrevista a Elmsoft
Elmar Krieger, también conocido como Elmsoft / EGS en la demoscene, fue un programador famoso, activo en la plataforma Amstrad CPC. Creó algunas demos que merecen la pena (entre ellas Chain Demo), pero se le conoce sobre todo por los siguientes juegos: Zap’t’Balls, Super Cauldron y, por supuesto, Prehistorik 2. Siendo yo un adolescente en aquella época, Prehistorik 2 me marcó especialmente. Sentía muchísima curiosidad por saber más sobre su trabajo en el CPC, así que me puse en contacto con él para una entrevista y ¡aceptó amablemente! :)
1. ¡Hola, Elmar! ¿Puedes presentarte brevemente? (edad, país, a qué te dedicas, etc.).
Nací en 1974 en Austria y vivo en Viena. Me gano la vida vendiendo el sucesor de Zap’t’Balls, un programa llamado YASARA, donde las bolas representan átomos reales y se mueven de forma más realista (lo que se llama «simulación de dinámica molecular»), para que universidades y compañías farmacéuticas puedan usarlo como ayuda en su investigación.
2. ¿Cuándo conociste el Amstrad CPC por primera vez? ¿Fue tu primer ordenador? ¿Todavía conservas alguno?
Mi primer ordenador fue un TI-99/4A en 1984/85, pero lo más divertido empezó en 1986, cuando mi padre compró un CPC 664 con monitor verde. Varios CPC siguen rondando por casa de mis padres, cubiertos de polvo, por desgracia.
3. Tengo curiosidad. Hiciste muchas demos en Amstrad CPC (la más famosa es Chain Demo). Tu grupo de demos era «Elmsoft Game Service». Es fácil adivinar de dónde viene «ELMsoft», pero ¿por qué mencionar la palabra «game» en EGS si hacías demos? ¿Hacías demos en aquella época con la intención de que las compañías de videojuegos se fijaran en ti? ¿Funcionó?
Como todos los niños, quería jugar a videojuegos; mis dos primeros juegos de CPC fueron Harrier Attack y Hunchback, y cada uno costaba lo mismo que 100 litros de gasolina. En dinero de hoy, eso son la friolera de 150 EUR por videojuego. Así que tuve la suerte de crecer en una época en la que los videojuegos eran un recurso escaso y los niños todavía se veían obligados a programar ellos mismos. En mi caso, eso se tradujo en varios juegos en BASIC absolutamente cutres hasta 1987, algunos usando Laser BASIC (era la extensión de BASIC de Ocean para hacer sprites y scrolling).
Lo divertido es que acabo de buscar Space Taxi CPC en Google y he descubierto que algún masoquista incluso ha subido una imagen *.dsk (era un «port» de un juego de C64 con el mismo nombre). Así que de ahí venía lo del «Game Service» ;-)
4. Estuviste presente en las dos demo-parties Euromeeting 1 y 2 (1991, 1992). ¡Qué suerte tuviste! :) ¿Tienes algún recuerdo, alguna anécdota… que compartir?
Euromeeting 1 fue mi primer contacto personal con la escena internacional del CPC, y cada detalle, en todo su esplendor, se me quedó grabado para siempre en el cerebro. También porque me olvidé por completo de dormir, así que al final tuvieron que llevarme en volandas. En cuanto a programación de CPC, mi recuerdo más impresionante es la demo S&KOH de Overflow, con su increíble fondo retorcido con scroll vertical y los sprites por encima. ¿Podrías entrevistarle a él la próxima vez? ;-). También recuerdo una demo de Logon con división horizontal de modos, donde las mitades izquierda y derecha de la pantalla tenían profundidades de color distintas.
5. Siguiendo con las parties Euromeeting, allí se mostró una preview de un shoot’em’up, Cyborgs. El juego nunca llegó a terminarse. ¿Por qué?
Porque envié la preview a varias compañías, pero no encontré editor. Fue en 1990, cuando el CPC todavía iba bien, así que decidí probar con otro proyecto.
6. Zap’t’Balls fue tu primer juego serio. ¿Fue un éxito publicarlo como shareware? ¿Qué aprendiste de ello?
Programé Zap’t’Balls sobre todo porque la revista alemana de CPC «Amstrad CPC International» aceptó de antemano incluirlo en el disco de portada. Y pensé que programar es mucho más divertido si sabes que el resultado se va a publicar. Como muchos juegos de coders de demos, Zap’t’Balls se hizo «al revés».
Primero se te ocurría una técnica de programación interesante y luego pensabas en un juego que pudiera aprovecharla. En Zap’t’Balls, la técnica consistía en dibujar rápidamente muchas bolas enormes a 50 imágenes por segundo. Solo funcionaba con bolas, porque son objetos redondos (así se podía restaurar únicamente una porción del fondo con forma de rosquilla, mover un poco la bola y redibujarla en la nueva posición) y, salvo por el reflejo de la luz, las bolas no eran muy coloridas (así se podía colocar el puntero de pila en la memoria de vídeo y «empujar» ahí los gráficos, descomprimiéndolos al vuelo, con un programa en ensamblador para cada tamaño de bola).
Esto se terminó en 1991, y a principios de 1992 empecé con Zap’t’Balls - The Advanced Edition. En 1992 el CPC ya estaba en declive y las compañías apenas publicaban títulos exclusivos de CPC, solo títulos multiplataforma con una versión de CPC por cubrir mercado. Así que no busqué editor, sino que lo vendí yo mismo (en realidad no era shareware) con la ayuda de otros entusiastas del CPC. Aun así fue una jugada afortunada, porque después del Euro Meeting 2 de Reims hice una escapada a París y le enseñé el juego a Titus Software, que me contrató para convertir Super Cauldron y Prehistorik 2 al CPC.
7. Super Cauldron y Prehistorik 2, ambos distribuidos por la editora francesa Titus, salieron en 1993. ¿Puedes describir tu acuerdo con Titus Software y cuál era tu relación con ellos durante el desarrollo? ¿Fueron un éxito comercial, tenías cifras de copias vendidas, etc.?
El acuerdo era crear las versiones de CPC de estos dos juegos por una cantidad fija de dinero, sin más preguntas ;-). Así que no tengo ni idea de cuántas copias se vendieron, y en 1993 probablemente ya era demasiado tarde para tener un éxito comercial de verdad en CPC. Si no recuerdo mal, fueron los dos últimos títulos de Titus para el CPC.
8. Tanto Super Cauldron como Prehistorik 2 usan la misma tecnología para mostrar con fluidez mundos enormes. ¿Puedes describir las herramientas implicadas, tu flujo de trabajo en aquella época, etc.? ¿Usaste herramientas de cross-development? ¿Los assets (sprites, imágenes…) se adaptaron de la versión de PC?
Prehistorik 2 formó parte de la última hornada comercial de juegos para Amstrad CPC (1993).
La CPU Z80A del CPC era demasiado lenta para hacer scroll fluido de la escena copiando en la memoria de vídeo. La solución oficial era dejar que el hardware hiciera el scroll cambiando simplemente la dirección de inicio de la memoria de vídeo. Por desgracia, eso solo permitía pasos de 8 píxeles en cada dirección (con la resolución del Mode 1, de 320x200 píxeles). Así que, si querías un scroll realmente suave (a la frecuencia de refresco de pantalla de 50 imágenes por segundo), esto daba lugar a juegos absurdamente rápidos; el primero fue Roland in the caves, creo, y el más famoso probablemente Ghosts’n’Goblins. Pero aplicando los trucos descubiertos por la demo scene era posible un scroll más lento y, por tanto, más amable para el jugador, de 4 píxeles en horizontal y 1 píxel en vertical, que es el que usé para los dos juegos.
El siguiente problema a resolver eran los sprites, y ahí los dos juegos se diferenciaban bastante. El CPC no tenía sprites por hardware como el C64, así que cada píxel en movimiento tenía que dibujarlo la CPU «a mano». Esto significa que el proceso de dibujado (restaurar el fondo y dibujar el sprite en la nueva posición) era, en principio, visible en pantalla. Muchos juegos usaban page flipping para ocultarlo (que sigue siendo el método preferido hoy en día), pero eso habría obligado a reducir el tamaño de la pantalla un 50 % para no pasar del límite de 64 kilobytes de memoria que impuso Titus (querían soportar también el CPC 464/664 sin ampliación de RAM, incluso con cinta magnética).
Así que el truco de los sprites en Super Cauldron funcionaba así:
- Llevar la cuenta de qué sprites se solapan y agruparlos en «paquetes de sprites».
- Estimar cuánto tiempo hace falta para restaurar el fondo común y redibujar cada paquete.
- Tener en cuenta la posición actual del rayo catódico en el monitor y planificar el dibujado de los paquetes de forma que no se vean sprites a medio terminar ni, por tanto, efectos de parpadeo.
Esta receta funcionaba bien, pero no demasiado bien. Sobre todo cuando se solapaban sprites grandes o muchos sprites, el dibujado podía tardar más de 1/50 de segundo, y entonces se veía algún parpadeo ocasional. Así que para Prehistorik 2, que además tenía sprites más grandes, cambié la receta y conservé solo el paso 1:
- Llevar la cuenta de qué sprites se solapan y agruparlos en «paquetes de sprites».
- Para cada sprite, determinar el rectángulo que engloba las posiciones antigua y nueva del sprite.
- Dibujar los gráficos del fondo dentro de ese rectángulo en un buffer fuera de pantalla.
- Dibujar en el buffer fuera de pantalla las partes de todos los sprites del paquete que se cruzan con el rectángulo.
- Copiar el buffer fuera de pantalla a la pantalla.
Este enfoque era más lento que el primero, porque requería una copia adicional, pero también estaba 100 % libre de parpadeos. Si el rayo catódico atravesaba la operación de copia, el resultado era solo un «efecto de tearing», que resulta mucho menos evidente que un parpadeo. Lo curioso es que el tearing sigue persiguiendo a los gráficos por ordenador hoy, 20 años después ;-)
En cuanto al apartado gráfico, procedía en su mayor parte de la versión de PC: Titus proporcionaba gráficos VGA con resolución de 320*200 píxeles, yo los ajustaba para el CPC con Deluxe Paint en el PC y luego lo convertía todo a 160*200 píxeles (Mode 0), lo copiaba a un disco de 5.25” y lo volvía a leer en el CPC. Para el desarrollo usaba dos CPC: uno con el ensamblador Maxam para escribir el código, y el otro para probarlo, con un MultifaceII conectado para depurar. Este montaje obligaba a cambiar los discos a mano en cada prueba. Toda una pesadilla vista desde hoy ;-)
9. Prehistorik 2 hizo un uso avanzado de las características del Amstrad Plus. ¿Qué pensabas de esta máquina en aquel momento? ¿Qué opinas ahora de ella?
Pensaba lo que pensaba todo el mundo: el Amstrad Plus habría sido una máquina fantástica en 1986, pero llegó demasiado tarde en 1990, cuando el Amiga 500 con su CPU de 16 bits ya tenía tres años. Aun así fue muy divertido añadir los efectos CPC+ a Prehistorik 2, como el scroll parallax hecho con sprites por hardware en primer plano y el cambio rápido de color al fondo (hecho con un pequeño programa de dibujo que generaba código Z80 que cambiaba rápidamente el color de fondo para crear los gráficos del fondo).
10. En algún sitio se mencionó (¿quizá en la demo Voyage 93?) que luego dejaste el Amstrad CPC por los juegos de GameBoy (ambas plataformas comparten el mismo procesador Z80). ¿Puedes contarnos tus actividades en GB, qué se publicó, etc.? Después de aquello, ¿seguiste una carrera como programador profesional de videojuegos?
Cuando terminé Prehistorik 2 para el CPC, también porté el juego a la Nintendo Gameboy, donde se llamó Prehistorik Man. Era la GameBoy original, con resolución de 160*144 píxeles y cuatro tonos de gris. Y me divertí muchísimo llevando algunos de nuestros trucos de demo del Amstrad CPC a la GameBoy, como los mensajes con scroll a pantalla completa usando split-rasters; véase por ejemplo esta intro o el primer nivel. Sorprendentemente, pude reutilizar los algoritmos de sprites por software del CPC, porque, aunque la GameBoy tiene sprites por hardware de 8*16 píxeles, estos tienen serias limitaciones (10 como máximo por línea, prioridades erróneas). Así que, curiosamente, nuestro viejo CPC permitió a la GameBoy mostrar sprites más grandes ;-)
Toda la música que usé en Gameboy era en realidad auténtica música de CPC, ya que hice un player de Gameboy para el famoso SoundTrakker de BSC.
Después de eso, los gráficos 3D ya estaban en pleno auge, y trabajé en un motor 3D para la GameBoy con mapeado de texturas, pensado para un juego llamado StuntRaceFX. Debido a la débil CPU de la GameBoy, hacerlo por software era totalmente inviable, así que lo basé en trucos de hardware como el «pixel line splitting» (donde la dirección de inicio de la memoria de vídeo y los colores se cambian en cada línea de píxeles). Gracias a quienquiera que lo subiera aquí (empieza en el minuto 1:10). Por cierto, el recorrido junto al logo «FX» y las montañas no usaba trucos de hardware, sino que se hacía descomprimiendo gráficos precalculados desarrollados por mi amigo Mark Piffer. Toda la música que usé en Gameboy era en realidad auténtica música de CPC, ya que hice un player de Gameboy para el famoso SoundTrakker de BSC.
Por desgracia, este motor 3D no llegó a ningún cartucho de GameBoy y fue mi último proyecto de entretenimiento. Justo después hice algo muy «lame» y pasé de los juegos al software de aplicaciones. Desde entonces trabajo en YASARA, que he mencionado antes. Pero —qué suerte la mía— resultó ser exactamente el mismo reto de trastear con lenguaje ensamblador que en el viejo CPC (hoy en día usando, por ejemplo, MMX/SSE/AVX), así que sigo divirtiéndome a bajo nivel ;-)
11. ¿Crees que la piratería mató la plataforma? ¿O, al contrario, ayudó a aumentar la popularidad del Amstrad CPC?
Fue simplemente el tiempo lo que intentó matar al CPC, y la piratería lo que lo salvó. Todos mis juegos fueron «crackeados», y esa es la única razón por la que siguen vivos hoy y se pueden jugar en emuladores. La mayoría de los discos originales, protegidos contra copia, se han echado a perder, igual que el código fuente y las herramientas.
12. ¿Sigues echando un vistazo de vez en cuando a la actualidad de la escena Amstrad CPC? ¿Qué opinas de sus avances?
Por supuesto, cada pocos meses estoy atento a las novedades del CPC, sobre todo a las demos, y me parece increíble cómo entusiastas como tú mantienen a flote este barco, que si no se habría hundido hace 20 años. ¡MUCHÍSIMAS GRACIAS!
¡¡Un millón de gracias, Elmar, por esta entrevista y por todas las grandes cosas que hiciste por el CPC!!