Nos planteamos pasar a Watcom C++ 10.5, necesitamos sobre todo menos lío con la gestión de XMS, pero lo que en realidad nos gusta es su rendimiento. Sin embargo, tenemos tanto código específico para Borland de cara a exprimirlo al máximo, y tanto ensamblador en modo real, que hacerlo vendría a ser casi como empezar de cero. Por no hablar de eliminar otra vez las dependencias de XMS, y buscar nuevas librerías sustitutivas. Tiempo después nos sorprendería que si bien títulos punteros y que admirábamos como Mortal Kombat, lo usaban, Street Fighter II, nuestro preferido, lo hacía con Borland C++.
Tenemos ya el primer nivel funcionando, de momento es demasiado fácil, y poco jugable, pero es cuestión de ir ajustando tiempos, así que lo dejamos para después. En este punto, la escopeta se mueve por la pantalla, se anima al disparar, se escogen aleatoriamente los personajes que aparecen en las puertas, y se dibuja su secuencia de fotogramas, en el caso de que fueran buenos, y de que fueran malos. A falta de pulirlos, los personajes básicos están también creados.
Añadimos entonces un marcador de puntuación en la pantalla, que sorprendentemente consume más recursos de los que nos imaginábamos a priori, así que optimizamos las rutinas de impresión de texto, y finalmente acaba siendo una macro para aumentar al máximo su rendimiento.
Para el primer nivel sólo faltan detalles, y nosotros, desconocedores de la regla del 80/20, lo dejamos un poco de lado, nos damos cuenta que hace falta una pantalla de introducción para que el juegador se familiarice con la dinámica, así que creamos el nivel 0. En paralelo, terminamos de crear los personajes que faltaban.
Nos queda todavía mucho por hacer, y llega la siguiente edición del concurso, a la que tampoco llegamos a tiempo, lo que nos desmotiva un poco. Cuando se publican los ganadores, vemos como ha cambiado el nivel en esta edición, y es que de un año para otro, todas las técnicas que empezamos a usar, se habían popularizado ya lo suficiente. Quizás eran ideas algo menos elaboradas que la nuestra, pero eran completas, y jugables.
El duelo tiene un nivel gráfico excepcional, pero programarlo va a ser todavía más difícil que el primer nivel, así que lo dejamos un poco de lado, y nos centramos en la pantalla de pausa, que sin más sentido que resultar virguero, tiene una ilustración de un gangster, junto a un ecualizador gráfico mientras suena el tema “Espíritu electrónico”.
En esta época avanzamos a trompicones con días de mucha motivación, y semanas sin tocar el teclado. El ejecutable pesa unos 205 Kb., de manera que hasta a Blinker le lleva su tiempo enlazarlo, una vez comprimido, se queda en unos 100 Kb. Necesita picos de 2,5 Mb. de memoria XMS, con unos 400 Kb. de memoria convencional. Da el rendimiento óptimo incluso en un 386/25, y con las salidas a pantallas sincronizadas con el retrazo, funciona perfectamente en un Pentium/133.
Seguimos en la época virguera, así que aprovechamos la rutina de fuego que había implementado, y la incluímos una vez se ha escogido salir, con la excusa de que al ser shareware, se le recuerde al usuario que debe hacerlo. Ya puestos, incluímos la rutina de humo en modo texto, antes de inicializar el modo gráfico para difuminar las letras en pantalla.
A principios de 1997, del duelo hemos avanzado poco, la animación introductoria, y poco más, los niveles siguen siendo fáciles y poco jugables, y esos ajustes pendientes nunca llegaron a hacerse. Sin embargo la apariencia de todo el conjunto que comenzáramos casi 2 años atrás, sigue siendo moderna y profesional.
El día de Reyes de 1998 es cuando hacemos las últimas modificaciones al Outlaw original, que queda definitivamente olvidado.
En 1999, encuentro una copia de seguridad de Outlaw en discos de 3,5, y decido hacer una versión web que aproveche los gráficos y el sonido que teníamos. Es la época de Internet Explore y Netscape, así que empiezo a convertir todo a GIF, incluyo DynAPI, y consigo tener casi todas las tareas de fondo, pero sin ninguna lógica de juego. En seguida lo dejo de lado, y hago una copia en CD de todo, sin haber reparado que en había eliminado todo lo que no iba a necesitar en la conversión. He borrado los fuentes de glib, xms, los fuentes de las herramientas de apoyo CONFIG, RESET, MANUAL e INSTALL, los ajustes sobre flilib, todos los archivos BAT que automatizaban la construcción, y por supuesto los ejecutables. Craso error.
Hace unos días he encontrado esa copia, es decir, el 80% de lo que teníamos desarrollado del juego, pero sin las partes que más esfuerzo nos costaron, y por tanto sin posibilidad de reconstruirlo, así que sirva esta entrada como el homenaje que se merece, y que quede el material original disponible de nuevo (822 Kb. en formato RAR).
¡Excelente! Me ha recordado mucho, salvando las distancias, a algunos pinitos que hice con C++ y unas librerías para manejar sprites que publicó PCMANÍA en su día. Yo entré al mundo del PC desde los 8 bits, y una de las cosas que más extrañé al principio era lo alejado que quedaban los sprites y la programación. En MSX sólo encenderlo ya tenías el BASIC con sus rutinas gráficas y hasta pequeñas llamadas a código máquina.
Te felicito por los dos artículos, ¿tienes algún otro juego que puedas contarnos más?
Me ilusiona que te haya gustado joanra. En mi caso, también empecé con los 8 bits, en mi caso con el Spectrum, y cuando pasé a PC, sobretodo conociendo amigos con entornos Atari ST y Amiga, me decepcionó un poco.
También me llamó la atención como máquinas mucho más baratas y básicas, como el Commodore 64, eran capaces de manejar sprites por hardware, cosa que los PC no conseguirían hasta que se implantaron las aceleradoras 2D en los tiempos del Pentium.
No fue hasta que comprendí un poco el funcionamiento del hardware a bajo nivel, que con BASIC, Pascal, C y ensamblador, empecé a ver la potencia a las capacidades gráficas del PC, que de otra forma pasaban desapercibidas.
Hubo algún prototipo del juego de lucha que te comenté, pero era más que nada una prueba de concepto y de rendimiento, y no conservo nada al respecto. Si que está todavía el Ice Fury que menciono, que aunque concebido como una demo de nuestra librería glib, servia como ejemplo sencillo de introducción.
Gracias por responderme. Bueno yo programaba mucho en MSX pero el Spectrum sigue estando en mi corazoncito, ajjaa. Mi hermana tenía un Spectrum 48 kb y flipaba un montón con los juegos. Luego más mayor me regalaron el MSX y allí empezó mi pasión por la programación. Sobretodo en esa época por hacer algo parecido a un juego.
Por cierto, hace unos años empecé a investigar sobre el Spectrum Sam Coupé y quedé flipado con su Basic y sus rutinas gráficas. Es como si hubieran hecho el mejor Basic pensado para hacer juegos. Todas las rutinas gráficas aún y ser en Basic se dibujaban a velocidad casi de Ensamblador. Y hasta sacaron un programa para crear videojuegos rollo point and click. Una gozada vaya.
Por desgracia para mi, nunca llegué a ver un Sam Coupe real, pero si recuerdo la expectación que las revistas de la época exponían sobre él. Lamentablemente llegó tarde al mercado, cuando los 8 bits estaban ya en las últimas.
Usando emuladores, he trasteado un poco con él, y todo lo que dices es cierto, muchos más comandos de BASIC, especialmente para gráficos, y sobretodo implementados de una forma mucho más eficiente. Por lógica tendrían que ser entorno al doble de rápidos que en un Spectrum original, por la velocidad del procesador del Sam, pero sin tener datos exactos en la mano, me aventuro a decir, que en realidad eran al menos 4 veces más rápidos.
Sobre calidad gráfica del Sam, no te pierdas el artículo Sam Coupe, y si todavía te queda más curiosidad, pásate por Spectrum en un SAM, donde verás el Sam emulando un Spectrum, que a su vez está emulado en un PC.