En 1995 comenzamos a desarrollar una biblioteca de funciones gráficas para modo 13h de MCGA/VGA (320×200 con 256 colores). Por aquella época lo que más nos motivaba era la prestación pura, así que no es de extrañar que estuviera escrita casi al completo en ensamblador. Las primeras versiones hacían uso del juego de instrucciones básico del 8088/8086, pero en seguida nos dimos cuenta que si queríamos ir en serio, debería obtener el rendimiento extra que daban primero las instrucciones del 286, y luego del 386, llegando incluso a jugar con el scheduler del Pentium. El nombre que le dimos fue glib.
Iba acompañada de los habituales casos de prueba, y monitores de rendimiento que comparaban su evolución, hasta que fue los suficientemente estable, rápida y flexible, en el que decidimos usarla en algo real. La idea inicial era escribir un juego de lucha estilo Street Fighter, pero esto lo complicaba mucho a nivel gráfico y de código, así que tras unas pocas pruebas de concepto la descartamos.
Entre tanto escribí Ice Fury, que a nivel de concepto e implementación era muy sencillo, pero que ponía en práctica mucho de lo que ofrecía glib, que incluso en su modo 8086, era bastante veloz.
Habíamos pasado horas y horas comparando rendimiento, y tardes enteras de análisis con Turbo Profiler, hasta que conseguimos tener lo que queríamos. Podía ser tosca, pero era muy rápida. A nivel de funcionalidad, soportaba casi todo, salvo rotaciones (sprites con y sin transparencia; transferencia de pantallas con y sin transparencia; manipulaciones de píxels, escalado de sprites en factores enteros, lineas, rectángulos, manipulación de paleta sobre el DAC; lectura y escritura de PCX y TGA; control de teclado; salida de texto; …).
Estamos ya a mediados de 1996, cuando me entero que la revista PC-Actual convoca un concurso de desarrollo de videojuegos, con un plazo límite de unos 5 meses más, así que se me ocurre crear una versión de West Bank, el título de Dinamic de 1985 para Spectrum, que era sencillo y adictivo a la vez.
Por aquella época los remakes eran algo desconocido, pero me pareció una buena idea actualizar un concepto de juego atractivo, con gráficos a 256 colores, y sonido Sound Blaster para PC, así que nos ponemos manos a la obra con el desarrollo. Lo que pretendía conseguir era la calidad gráfica y experiencia de juego de los arcade 2D de la época, y que a la vez funcionara en el PC más modesto que pudiéramos. Así que el enfoque sería Borland C++ 3.1 para la lógica de juego, y ensamblador siempre que fuera posible para la base.
Tuve la idea de cómo podíamos implementarlo en junio de 1996, así que a la vuelta de vacaciones Rog y yo como líder, nos pusimos a desarrollarla. Luego se unirían Pablo y Juanjo que se encargarían del apartado gráfico, Pedro que se encargó de los raytraces, Felipe que nos hacía de betatester, y hasta Toni que nos ayudó con algunos textos en inglés.
La cosa parecía factible, pero la falta de tiempo de todos los miembros, hace que el progreso no sea lineal, cuando el cuello de botella no era el código, lo eran los gráficos. Además nuestra idea original de hacerlo para 8086, optimizado para funcionar a plena capacidad en un 286, en seguida se ve un imposible. Si queríamos animar el fondo con 3 frames a pantalla completa, eso requería ya 192 Kb. de memoria, que sumados a la memoria para el doble buffer eran ya 256 Kb. A esto había que sumar el consumo del resto de sprites, el sonido, y por supuesto el código.
Decidimos aprovechar que glib tenía funciones optimizadas para 386, y aprovechar la memoria XMS con un wrapper que creamos también en ensamblador, y empezamos a convertir el código a XMS. Sin embargo, y con objeto de granularizar el consumo de memoria, optamos por la mala idea de guardar cada elemento en su propio bloque de memoria, así que pronto llegamos al límite de los 128 handles por defecto de XMS.
En seguida nos damos cuenta, que el inconveniente de usar el modo de 256 colores con paleta es que todas las imágenes deben usar la misma, así que creamos una plantilla en Deluxe Paint II, con la paleta que vamos a usar, y hacemos que todas las imágenes usen esa plantilla.
No habíamos tenido ocasión de incorporar en ningún desarrollo la animación de D.T.S. que habíamos creado con raytracing en Pov-Ray en un 486 a 33 Mhz, la convertimos a formato FLI y la incluimos en Outlaw. Puede parecer increíble hoy día, pero llevó casi 2 horas renderizarla completamente a 320×200. La reproducción se hacía con la ayuda de flilib 1.0 (Dancing Flame).
Creamos además un controlador de teclado leyendo directamente del hardware, que permita menos overhead, y sobre todo pulsar varias teclas al mismo tiempo, sin que interfieran, ni se llene el buffer de teclado. Nos hacemos además con algunas librerías de uso gratuito: PC Sound 2.0 (David S. Hoelzer) que nos permite reproducir efectos de sonido VOC, y Mod-Obj 1.02 (Mark J. Cox) que permite reproducir archivos MOD. Ambos soportan tanto altavoz interno como Sound Blaster, así que se mantiene el nivel compatibilidad que buscábamos. Sin embargo esto implica un trabajo adicional, hacer un programa de configuración. Este es CONFIG.EXE, escrito en Turbo Basic 1.1 con TBWINDOW, para detectar y escoger dispositivo de salida de audio, y la velocidad de la mezcla dependiendo de la potencia del procesador. Naturalmente aprovechamos el también programado en Turbo Basic Manual Enhancer para distribuir algo de documentación en MANUAL.EXE.
Usar un controlador de teclado por hardware, impide la depuración sobre el IDE de Borland C++, así que migramos todo a linea de comandos con Borland C++ 4.5, Blinker 3.1, y escribimos código con QEdit 4. El binario de fliblib no funciona con BC 4.5, así que recompilamos la librería aplicándole algunos ajustes, y más optimizaciones de compilación. Como además operábamos en modo gráfico, printf y las funciones de la librería de C estándar no valían para sacar información de depuración por pantalla, de modo que ver el valor de una variable, requería editar el código, convertir a un array de caracteres lo que había que sacar por pantalla, usar gputsfnt88 de glib para mostrarlo, esperar a que se pulsara una tecla, y terminar.
El problema ahora es que compilar todo el proyecto requiere de casi 5 minutos, es obvio que las optimizaciones adicionales de Borland C++ 4.5 requieren más tiempo, y además cada vez compilamos todos los módulos, que con el tiempo son mucho más que al principio. No sabemos como funciona MAKE de Borland, así que optamos por crear Smart C, que permita recompilar solamente los módulos que han sido modificados.
Al crear CONFIG, nos damos cuenta que hará falta también un instalador, así que con la potencia de los SFX de RAR para DOS, empezamos a crear uno: INSTALL.EXE, con los menús imitando los de CONFIG, y que demuestra ser más laborioso y engorroso de lo que iba a parecer.
Nos gustaba el trabajo a bajo nivel, e insisto en que nos daría una apariencia profesional que el juego detectara las capacidades del equipo en las que funciona, independientemente de que sacara partido de ellas o no, así que invertimos un tiempo desproporcionado en detectar memoria convencional, XMS, EMS, espacio en disco, disponibilidad de CD-ROM, tipo y velocidad del procesador, …
La carga de los recursos gráficos se hace descomprimiendo PCX para ahorra espacio en disco, con una rutina que intercepta la interrupción de reloj, y por tanto es capaz de ir moviendo el cartel de “Loading” en paralelo mientras las carga. Una característica que lo hacía mucho más suave que títulos de calidad comercial que clavaban la máquina mientras se cargaba o descomprimía el contenido.
Por supuesto no queremos que a simple vista se sepa que son vulgares PCX, así que los renombramos en SCREEN\*.SCR y SPRITE\*.SPR, que no dejan de ser los PCX (con paleta incluida) y PCC (sin paleta) que genera Deluxe Paint, pero al que modificamos un poco la cabecera para que no sean facilmente editables, lo que nos obliga a escribir PCXALT y PCXNOR para alterarlos, y volverlos a su estado normal.
Terminamos el menú principal, que es capaz de gestionar la animación del fondo con 3 fotogramas, una bola de rastrojo típica del oeste, la rotación de paleta de los elementos del menú, las instrucciones del juego que van pasando secuencialmente, las respuestas al teclado, mientras de fondo suena música en formato MOD.
Implementamos la pantalla de records, que va acompañada del tema Alphaville. Está creada también en Pov-Ray, contradictoriamente se ordenan por el método de la bajara, que al ser sólo 10 no es problema, a cambio, se guardan en disco encriptados por una tabla de translación, y se verifica su integridad cuando se cargan para evitar la manipulación.
Esto nos lleva a crear RESET.COM, para restaurar records a sus valores por defecto, como es simplemente eliminar un par de archivos, lo hacemos todo en ensamblador.
El código empieza a ser complicado de mantener, y es que con más de 10.000 lineas de código sólo para Outlaw, sin contar las librerías de terceros, escritas en un entorno DOS por unos aficionados que preferían el rendimiento a la claridad, empieza a notarse. El plazo para el concurso termina, se publican los resultados, y sin desmerecer el esfuerzo, vemos que de haber llegado habríamos ganado. Y es la mayoría de los participantes optaban por simples juegos sobre BGI, de tipo tablero o similares. El nuestro era un arcade, con tecnología y capacidades de nivel casi profesional.
Las copias de seguridad de todo el juego con fuentes, datos, y ejecutables, ocupa 2,5 Mb. en RAR a máxima compresión, y tarda del orden de 20 minutos en hacerse en el 386/40 que usábamos para desarrollar. Si contamos que probar el juego requiere salir de QEdit, compilar, lanzar el ejecutable, llegar hasta donde se quiere probar, y ver que ocurre, vemos que la depuración es rudimentaria y lenta.
Creamos algunos trucos que con combinaciones de teclas nos permitan subir y bajar de nivel, y aumentar o disminuir vidas, además añadimos un argumento por linea de comandos para entrar en el juego en modo “turbo”, sin detección de hardware, sin presentación, …
Nos decimos que podemos volver a intentarlo el año que viene, y seguimos desarrollando. A partir de aquí, nos damos cuenta del esfuerzo a nivel gráfico que se requiere. Sólo a nivel de fondos son 3 por nivel, más los 8 de cada duelo. Los sprites de personajes son 12 frames cada uno, y teníamos 8 personajes. Es decir un total de 22 fondos a pantalla completa, y 96 de sprites. Se me ocurre hacer una versión shareware que sería la que presentaríamos al concurso, con solamente 2 pantallas y el duelo, dejando las 7 pantallas restantes para después.
