¡VAPF!


¡Vete al peo, Fede!

Presentación del libro "Queremos su dinero"

Vengo de FNAC Callao de asistir a la presentación del nuevo libro de Jesús Martínez del Vas: "Queremos su dinero". No sé cuándo, pero es un libro que leeré con seguridad. Narra la historia personal de José Luis Domínguez, centrada principalmente (entiendo) en su etapa en Indescomp, que posteriormente se convertiría en Amstrad España.

Ha dado la casualidad de que el evento coincide en día y hora con otro al que también quería acudir, que era la charla de Carlos Buenosvinos en PHPMad. Así que he tenido que elegir y a última hora me he decantado por éste, principalmente porque me apetecía más la temática y, también, porque me pilla más cerca del trabajo para llegar, y de casa para volver. Y menos mal, porque menuda tarde de frío y lluvia que se ha quedado.

Presentación de "Queremos su dinero" en FNAC Callao

La presentación ha sido una charla de algo más de una hora en la que Jesús ha introducido un poco la temática del libro y la motivación de su escritura, y ha dado paso a que José Luis contase algunas anécdotas de su vida, sin llegar a destripar (espero) todo lo que se narra en el libro. Desde luego que es el tipo de persona a la que me tiraría horas escuchándole contar anécdotas. Me ha recordado bastante a mi antiguo jefe José Antonio Martínez Soler, cuando nos contaba sus batallitas. Es gente de la que siempre se puede aprender, y en este caso la moraleja me la llevo de una frase que pronunció más o menos así: "Todo el mundo está dispuesto a triunfar, pero no todo el mundo está dispuesto a pagar el precio". Y es cierto. El propio José Luis ha pedido públicamente "perdón" a sus hijos por haber estado 5 años sin prácticamente verlos, en la época de la vorágine de Amstrad. Y eso es un precio muy alto.

Para variar, he hecho el canelo una vez más. Podía haber comprado el libro antes de la presentación (me daba tiempo) y que me lo firmasen tanto Jesús como José Luis. Pero no lo he hecho, así que me he tenido que conformar con ser testigo de cómo le firmaban el suyo a Miguel.

Para finalizar os dejo un vídeo con la presentación, que Javier Barneo se ha preocupado de grabar, editado por Javier Ortiz. Que lo disfrutéis.


He vuelto a programar en BASIC como en los 80 (III)

Tras haber llevado el juego Dead End_ al Amstrad CPC y al MSX, tocaba el turno de la última plataforma, por descarte: el Commodore 64. Tras haber adquirido experiencia en los dos desarrollos previos, pensaba que este último paso iba a resultar más sencillo, pese a que tenía mis reticencias sobre qué me iba a encontrar en esta plataforma prácticamente desconocida para mí.

El primer paso ha sido, obviamente, localizar un emulador de Commodore 64 para macOS. De entre los disponibles, VirtualC64 fue el que más me ha convencido. Como características interesantes de cara a la tarea a la que me voy a enfrentar, mapea el teclado del Mac de forma automática, lo que permite no tener que recordar (o aprender en mi caso) la distribución de teclas del Commodore. Además permite copiar texto desde el Mac, de forma que lo convierte en pulsaciones de teclas. Esto posibilita, por ejemplo, introducir una línea de BASIC copiándola desde nuestro editor favorito sin tener que teclearla a mano. Por supuesto, permite el manejo de ficheros imagen de disco en varios formatos, e incluso tiene opciones de depuración que, como no voy a programar en ensamblador, no me van a resultar útiles en este momento.

Como herramienta adicional, disponemos de C64List, que nos permite convertir un listado BASIC de un fichero de texto en un fichero imagen de disco que podemos cargar directamente en el emulador. De esta forma, podemos programar en nuestro editor de texto favorito —en mi caso he usado Visual Studio Code, y probarlo en el emulador.

El siguiente paso también fue el lógico: obtener una copia del manual de usuario del ordenador (en este caso no dispongo de una copia física del mismo) desde la web de Commodore Spain, y hacer una lectura por encima para hacerme una idea de cómo funciona el ordenador. También aproveché que había comprado el libro Programación Retro del Commodore 64 para echarle un vistazo.

He optado por dividir la tarea en dos partes. Por un lado, creo que acertadamente, me centré en trasladar el juego entero desde el listado original de Spectrum, basándome en algunas partes de la versión para Amstrad CPC, al Commodore 64, pero obviando la parte gráfica. Para pintar los objetos usé letras. De esa forma, obtuve una versión funcional "relativamente" pronto.

Por otro lado, me puse a investigar cómo funciona el Commodore 64 en su apartado gráfico, examinar los modos de pantalla disponibles y elegir cuál es el que más se adapta a lo que el juego necesita. Adicionalmente, tenía que averiguar cómo redefinir los caracteres gráficos.

Hice algunas pruebas para usar el modo de color extendido, pero no me resolvía la papeleta
Hice algunas pruebas para usar el modo de color extendido, pero no me resolvía la papeleta

Pensaba que iba a tener más rápido la versión funcional. En teoría debería de ser así mezclando código de las versiones de Spectrum y Amstrad, pero no contaba con que, en el BASIC de Commodore 64, no podemos hacer RESTORE de los datos de una línea concreta —el BASIC de Commodore tiene algunas otras carencias, pero ésta era la más relevante hasta el momento. Estuve tiempo investigando cómo sortear este escollo. La dirección de memoria de la línea DATA que se está leyendo se almacena en memoria, pero por algún motivo mis pruebas no funcionaban. Hasta que me di cuenta que, como es lógico, si modificaba mi programa, esos valor cambiaban. Eso me obligaba a reorganizar todo el código para poner las líneas con los datos al principio.

Algo en la recuperación de datos no estaba bien, y eso hacía que las pantallas se dibujasen incorrectamente
Algo en la recuperación de datos no estaba bien, y eso hacía que las pantallas se dibujasen incorrectamente

Y, además, al final no llegué a implementar esa solución, porque me lié más adelante con el tema gráfico y esto lo dejé apartado. Lo que se hace cada vez es leer todos los datos y descartarlos hasta que llegamos a los que nos interesa. Un método que funciona pero que es lento y poco elegante.

Prototipo de Dead End_ sin caracteres gráficos
Prototipo de Dead End_ sin caracteres gráficos

Una vez tuve esa versión funcional, tocaba meterse en harina con el tema gráfico. Aquí no me quedó otro remedio que indagar sobre la arquitectura interna del Commodore 64 y, en concreto, su mapa de memoria. Es algo que quería evitar a toda costa y que habría conseguido en las versiones para los otros ordenadores. Me llevó algo de tiempo, porque no acababa de entender muy bien la información que iba encontrando, montar un prototipo en el que conseguía copiar el juego de caracteres desde la memoria ROM a la memoria RAM y, una vez allí, modificar los que me interesaban para poder generar los gráficos del juego.

La primera vez que conseguí redefinir un carácter gráfico
La primera vez que conseguí redefinir un carácter gráfico

Varios fueron los escollos. Por un lado, entender bien cómo funciona la memoria del Commodore, cómo se mapean las diferentes zonas de ROM, RAM y puertos de entrada/salida, así como la configuración del chip gráfico VIC II. Por otro, me costó bastante darme cuenta de que en la memoria no se almacenan los datos en código PETSCII (el ASCII del Commodore), sino que la codificación es otra. Usé esta tabla para poder obtener la correspondencia. Como algunos códigos coinciden y otros no, me volví loco hasta que lo hice funcionar.

Hasta que me di cuenta de que los códigos de memoria no son PETSCII, me llevó varias horas de pruebas
Hasta que me di cuenta de que los códigos de memoria no son PETSCII, me llevó varias horas de pruebas

El chasco fue mayúsculo al llevarme mi prototipo al código del juego. Y es, que, con la configuración por defecto, que es la que se encuentra en el manual de instrucciones y en casi todos los ejemplos que hay por ahí, el propio programa BASIC terminaba corrompiéndose, sobreescrito por los datos gráficos. Nuevamente, me costó bastante entender qué estaba pasando y cómo tenía que configurar el ordenador para ubicar la memoria RAM de gráficos en la parte alta, para no interferir con el listado.

Además de no hacer ningún tipo de optimización, siguiendo el enfoque de este proyecto, he tenido que renunciar a adaptar los gráficos tal y como están en las otras versiones, debido a la limitación de un único color de fondo (o bien hasta cuatro en uno de los modos gráficos disponibles, a costa de otras restricciones, y que tampoco me solucionaba la papeleta). Así que veréis que el rótulo del menú principal y el gráfico de la salida de cada nivel son algo diferentes. Tampoco he implementado ninguna solución al hecho de que, en el Commodore, no se auto repite la pulsación de teclas, por lo que no basta con dejarla pulsada, sino que hay que apretar cada vez para mover el muñeco a una posición adyacente.

Finalmente he conseguido apañar una versión bastante similar al resto y creo que digna, aunque se podría optimizar bastante, sobre todo teniendo en cuenta la arquitectura de este ordenador y la idiosincrasia de su lenguaje BASIC. Sólo he volcado una versión en imagen de disco, porque no he encontrado la manera de hacerlo con una imagen de cinta. En ese sentido estoy bastante atado a lo que me puedan ofrecer el emulador y las herramientas utilizadas.

Dead End_ (Commodore 64)

Eso sí, en algún momento he llegado a pensar en tirar la toalla, de lo desesperado que estaba de no hacer funcionar las cosas. Eso sí, sacar este proyecto adelante me ha llevado a conocer más en profundidad una máquina que desconocía casi por completo, aunque no era el objetivo.

En próximas fechas haré un resumen de lo que ha supuesto esta "aventura" de llevar un juego en BASIC del ZX Spectrum al resto de plataformas de 8 bit más conocidas. Y, si todo se da bien, seguiremos trabajando en cosas que compartir en este blog.


El final (ahora sí) de una etapa

Hace ya más de tres años y medio que dejé mi trabajo en 20minutos. Sin embargo, de alguna manera, no ha sido hasta hoy que se ha cerrado esa etapa.

Recuerdo mi primera visita a las oficinas (me resisto a llamarla “redacción”, como tienen por costumbre los periodistas) en noviembre de 2004. La ilusión por el proyecto: “tenemos un periódico que es número uno y hay que construir su web que también llegará al número uno”.

Hacía poco que había empezado este blog. Recuerdo llevar mi primer día al trabajo y ver los cinco servidores que iban a alojar el proyecto allí en el suelo. Se habían comprado pero había que instalarlos, configurarlos y llevarlos a su ubicación, que iba a ser en Acens. Para eso se contrató a un consultor, Jan Bruvoll; una de las personas brillantes con las que he tenido el lujo de trabajar estos años. Brillante, sí, pero un poco temerario (o demasiado seguro de sí mismo). El día de la salida se me puso a compilar el PHP (usábamos una distribución Gentoo).

Recuerdo el ambiente pre-navideño de ese diciembre de 2004. A la semana o dos de estar allí me puse malo del estómago. Menuda imagen para ser “el nuevo”. Por ello me perdí la primera cena de navidad de la empresa.

La redacción eran solo cuatro personas: Ricardo Villa (el director), Vanesa Rodríguez, Clara Hernández y Amanda Heredia. Nuestro diseñador era Ismael Viejo, otro excelente compañero con el que, por desgracia, he trabajado menos tiempo del que me gustaría. El equipo técnico era... yo, con el apoyo de mi jefe y el de Jan en la parte de sistemas.

Los primeros días iba armado con mi cuaderno y mi Pilot, me sentaba con Ricardo y me contaba cómo quería que fuera la nueva web y el nuevo gestor de contenidos. Íbamos a construir todo de cero, lo que tiene ser un inconsciente y poco documentado jovenzuelo. La verdad es que en aquella época no conocía ningún framework, sabía Javascript de andar por casa (el navegador que dominaba el mercado era, si mal no recuerdo, Internet Explorer 6), de PHP orientado a objetos lo justo, y también lo justo de control de versiones. Así que lo hicimos todo a lo burro, desde cero. Ni siquiera empecé a usar un IDE hasta muchos (demasiados) años después. Pero tampoco nos equivoquemos; el ecosistema que había en aquellos días no se parecía al de hoy ni por asomo: por seguir el mismo orden, no existían ni Symfony, ni jQuery, ni Git, y PHP 5 llevaba solo un puñado de meses disponible.

Uno de los muchos —de hecho el primero— cuadernos de notas que llené durante aquellos años

Lo increíble de todo aquello es que, tras decidir con qué funcionalidades íbamos a salir, el 1 de marzo de 2005 teníamos online la primera versión operativa de la nueva web y el nuevo gestor de contenidos. Lo pienso y no sé cómo pudimos hacerlo, pero lo hicimos.

La web de 20minutos en febrero de 2005, días antes del lanzamiento oficial

Desde luego, si tuviera que hacerlo ahora, creo que cambiaría casi todas las decisiones. Pero tampoco sería muy justo juzgar aquello con los conocimientos de ahora. Aunque sí que hubo dos o tres decisiones, tomadas por desconocimiento, de las que me estuve arrepintiendo muchos años.

Aquella primera versión tenía hasta comentarios de los usuarios. No sé si algún otro medio de comunicación admitía comentarios por entonces, yo creo que no. En cualquier caso, la mayoría de ellos eran constructivos. Nada que ver con lo que podemos encontrar ahora. Todos éramos más inocentes entonces. No os imagináis la sensación de estar de madrugada, tras haber lanzado la web, y que nos entrase un comentario pidiendo que implementásemos feeds RSS. ¡Dame feeds! ¡Quiero feeds!

Toda esta chapa viene a colación de que, aquellas líneas de código que se empezaron a gestar hace casi 15 años, alimentadas, mantenidas, arregladas, gestionadas por más de una decena de compañeros y compañeras, han quedado atrás. Hoy, el equipo de Henneo ha sustituido aquel gestor de contenidos por uno nuevo. El producto ya no es el mismo, el equipo directivo y humano tampoco. Y aquel vetusto software ya no daba más de sí.

Algunas cosas se han roto. La web de Tiempo y Temperatura ya no muestra las noticias de 20minutos
Algunas cosas se han roto. La web de Tiempo y Temperatura ya no muestra las noticias de 20minutos

No sé si volveré a escribir código que se mantenga tanto tiempo en uso por tanta gente. Pero, desde luego, con todos sus defectos y problemas, me siento muy orgulloso de haber formado parte de ese proyecto. Y, hablando de escribir, algún día debería sacar tiempo y contar las batallitas de aquellos años, antes de que se me olviden.

PS: Aun sigue online la versión de lanzamiento de Tiempo y Temperatura, una web con muchas limitaciones y que se ha quedado visualmente obsoleta, pero a la que tengo mucho cariño por lo que trabajé en ella, y que sigo consultando a diario para saber qué tiempo va a hacer en los próximos días.


He vuelto a programar en BASIC como en los 80 (II)

Después de dar el pistoletazo de salida a mi plan trasladando el juego Dead End_ al Amstrad CPC, toca elegir la siguiente plataforma que voy a visitar. Tengo dos para elegir: Commodore 64 y MSX. Voy a continuar con esta última. En realidad me da más o menos igual una que otra, pero me quedo con el estándar japonés porque creo que es la que más se asemeja a las dos anteriores, Spectrum y Amstrad. Ya veremos al final de todo este proceso si mi intuición ha sido la correcta.

En este caso, MSX no es un único ordenador, sino un estándar. Hubo varios fabricantes que construyeron microordenadores siguiendo esa especificación y, como suele ocurrir, no son todos iguales al 100%. Aunque creo que programando en BASIC no deberíamos tener ningún problema, es posible que nos encontremos alguna sorpresa no muy grata en ese sentido. En principio, la plataforma será un MSX de primera generación, con 64 KB de memoria.

Toda la experiencia adquirida hasta el momento me va a ayudar, no tanto a dar este paso más rápido, sino a tener muy claro cuáles son los puntos que tengo que resolver. Eso sí, antes de empezar a programar nada, tengo que elegir un emulador que me permita trabajar lo más cómodamente posible. Esto es, en el que pueda guardar el estado actual, para continuar más adelante, y que me ofrezca la posibilidad de cargar/guardar el fichero con el programa desde fuera.

Por lo que he visto, la oferta de emuladores para macOS, aunque hay algunos más disponibles, se centra en dos de ellos: openMSX y CocoaMSX —que, a su vez, está basado en BlueMSX (solo para Windows). De todos ellos, el primero parece el más completo y, desde luego, es el que más actualizado está. No obstante, su configuración no es trivial, en tanto en cuanto hay que configurar el ordenador concreto que queremos emular. Tampoco he dedicado mucho tiempo a trastear; quería entrar rápido en harina, asi que me he decantado por el segundo, con el que más o menos me he apañado. Eso sí, he echado mucho de menos no poder usar el genial Retro Virtual Machine para estos menesteres.

Lo siguiente ha sido dar un repaso rápido al manual del MSX para ver por encima qué posibilidades tengo, principalmente en cuanto a modos gráficos, y también para ir familiarizándome con el juego de instrucciones BASIC.

Manuales de BASIC del MSX

En este punto ha sido donde he empleado más tiempo a la hora de sacar adelante este proyecto. Y me temo que lo seguirá siendo si me decido por continuar portando el juego a más ordenadores. Me refiero a comprender el funcionamiento de los modos gráficos del ordenador y su implementación. Una cosa aparentemente tan sencilla, como poder pintar un carácter con un color de tinta y otro de fondo, algo en lo que se basa el código del juego en sus versiones de Spectrum y Amstrad, no es factible en el MSX.

Voy a intentar explicarlo, centrándome en el funcionamiento del Spectrum, que es el que mejor conozco, y tratando de no perderme en los detalles. En un Spectrum, se almacena por un lado la información de los píxeles (tinta/fondo, es decir, encendido/apagado) y, por otro, la información de color. Para cada grupo de 8x8 píxeles, se establece un color de tinta y otro de fondo. El MSX funciona de manera similar a como lo hacen las consolas antiguas. Hay una tabla donde se almacenan bloques (o tiles), y otra tabla donde se almacenan los colores para esos bloques. La pantalla no se compone píxel a píxel, sino que se construye a partir de esos bloques, como si fueran piezas de Lego. Por tanto, no es posible elegir un bloque (una letra por ejemplo, pero podría ser cualquier gráfico de 8x8 que definamos) y sus colores por separado, sino que bloque y color son todo uno.

Para terminar de "complicar" el asunto, en el modo "Screen 1" de MSX, la tabla de colores solo tiene 32 posiciones, por lo que se asignan colores a cada 8 bloques correlativos. Esto me costó entenderlo; después de leer el manual, yo pensaba que los colores se aplicaban a 8 bloques correlativos de la pantalla, lo cual no tenía sentido. Así que tuve que pedír consejo a Jon Cortazar, alma mater de Relevo Videogames, experto en el desarrollo para MSX (además de otras plataformas) y, sobre todo, una gran persona, quien amablemente se molestó en explicarme de forma sencilla cómo funcionaba.

Como nota mental, para próximos proyectos, esta parte del código, la encargada de "pintar cosas en la pantalla", debería estar lo suficientemente aislada para que la transición entre diferentes plataformas sea lo más sencilla posible.

Una vez superado este escollo, me quedaban por repasar los siguientes puntos:

  • Cómo se edita un programa en BASIC. En particular, cómo se edita o elimina una línea.
  • Cómo se ejecuta y se interrumpe un programa BASIC.
  • Cómo se cargan y almacenan programas BASIC.
  • Cómo se gestionan los GDU (Gráficos Definidos por el Usuario).
  • Cómo se ubica el cursor en una posición determinada de la pantalla.

Como en el caso del Amstrad CPC, voy a elegir un modelo de ordenador con disco, en este caso un MSX2 Philips NMS-8250, ya que es lo más cómodo para trabajar. Ya veremos si luego no me llevo una sorpresa al probar el juego en un MSX "pelado". El emulador me permite crear una imagen de disco vacía, que puedo leer y escribir directamente desde macOS renombrando la extensión ".dsk" por ".img". Para Windows se puede usar el programa Disk Manager

Gracias a los consejos de Jon y al trasteo previo, ya tenía claro cómo debía hacer para poner los gráficos en pantalla, así que esta vez, en vez de copiar todo el listado desde cero, lo que hice fue partir de la versión de Spectrum, modificar las palabras clave que son diferentes y, en las partes que no me valían, usar la versión de Amstrad, también copiada. Toda la edición la hice en el PC, usando el emulador solo para probar y retocar alguna cosa. Más o menos se me dio bien, casi acerté a la primera con todo, menos con el dichoso bug del buffer, que me lo volví a comer (porque se me olvidó copiar la solución que ya tenía implementada en el listado de CPC).

Debido a cómo se gestiona la pantalla del MSX, eso sí, algunos detalles no están igual que en la versión de Spectrum. Por ejemplo, el gráfico que conforma la barra inferior que separa los marcadores está invertido. Y el fondo del mensaje que aparece cuando completamos un nivel no es azul, sino negro. Tampoco me molesté mucho en indagar en los comandos de sonido. Puse un "BEEP" sin más y a correr.

Por último, sólo faltaba generar los ficheros de cinta (.cas), disco (.dsk) y cartucho (.rom). Para este último he usado la utilidad MSX-BASIC ROM creator, de José Luis Tur. Enlazo a MSX Blog porque la web original donde se aloja el programa parece que no funciona he localizado la web oficial del programa.

Sobre todo el proceso de desarrollo tenéis más detalles técnicos en el repositorio del proyecto.

A posteriori lamento no haber dedicado más tiempo a aprender a manejar OpenMSX. No sé si es problema de mi ordenador; seguramente que sí, porque si no imagino que alguien más se habría quejado y, aunque el emulador hace bastante que no lo actualizan, imagino que tendrían una issue abierta. El caso es que el teclado no me funciona bien y, cuando estoy editando el listado en BASIC, el cursor se vuelve loco y se borran las líneas enteras. El caso es que, después de finalizar el desarrollo, Miguel me pasó unos ficheros de configuración que, copiados en la ubicación adecuada, permiten disponer de un buen abanico de ordenadores emulados. Y aunque me dio algún problema adicional, y su integración con macOS tampoco es la ideal, parece funcionar mucho mejor. Incluso tiene mapeadas las teclas del teclado del Mac, para no tener que saber/recordar dónde están ubicados los símbolos en el teclado del MSX.

La sensación que me queda os la podéis imaginar. La parte de gestión de vídeo del MSX es bastante diferente a la de los ordenadores de 8 bit que conocía hasta ahora y se me asemeja más a la de una videoconsola. También me queda la impresión, que es una obviedad, de que adaptando el código en vez de copiándolo directamente podría obtener mucho mejores resultados. Desde luego que esta versión no hace honor a lo que se puede conseguir con este ordenador pero, aun a riesgo de repetirme, en esta ocasión el objetivo era otro diferente.

Dead End_ (MSX)

Juegos: Demo eFootbal PES 2020 (PS4)

Otro año más llega el momento de probar la demo de Pro Evolution Soccer, que a partir de esta entrega ha sido renombrado como eFootball PES. Este año también ha sido lanzada en julio, con lo cual la he podido catar antes de irme de vacaciones. No obstante, el partido para el vídeo no lo jugué hasta después de volver. Y este breve comentario, como tres semanas después.

Como es habitual, el juego se siente diferente, ya que el equipo de desarrollo hace pequeños ajustes aquí y allí. Pero tampoco esperemos una gran revolución, por más que nos lo quieran vender. Si acaso el juego da la impresión de ser un poco más "alocado" o "aleatorio".

Visualmente creo que se les ha ido la mano con la saturación de los colores. Por lo demás, noto pocos cambios respecto a la edición del año pasado. Si acaso un lavado de cara a los menús, supongo que más animaciones y pequeños detalles, pero nada impactante, como vuelvo a repetir.

También han retocado las físicas. El balón parece ir un poco más suelto, y los cuerpo a cuerpo de los futbolistas toman más importancia. Podemos usar nuestro cuerpo para proteger el balón, así como cargar al contrario para intentar robar el esférico. La meteorología cambiante (la verdad es que no recuerdo si estaba en anteriores entregas) hace acto de presencia. Por ejemplo, uno de los partidos que he jugado empezó nevando y terminó lloviendo.

En esta demo tenemos la oportunidad de jugar partidos tanto contra la máquina como online con un pequeño conjunto de equipos (imagino que los que tienen contrato con Konami). Lo que me ha sorprendido —para mal— es que el "efecto Konami" se hace más presente que nunca. Que igual es que no sé jugar, pero en el último partido que he echado antes de escribir estas líneas ha sido escandaloso. Desde el primer momento se notaba que el rival me iba a pasar por encima; faltas no pitadas, goles de rebote, etc. Y ya lo terminé de constatar cuando me quedé con Messi solo a portería vacía, hice un tiro colocado y lo mandó fuera.

En cualquier caso, creo que este año puede ser el primero de muchos que no compre la edición anual. ¿La causa? Falta de tiempo. Ya el año pasado jugué menos de lo que pensaba, y este año pinta que todavía lo haré menos, con un buen puñado de juegos pendientes, con algunos interesantes pendientes de salir (Star Wars Fallen Order, Luigi's Mansion 3 y alguno más) y menos tiempo libre para esta afición. De momento, si me apetece jugar algún partido, tiraré de la entrega del año pasado o de esta demo. Y, total, seguro que acaban por sacar la versión free to play en algún momento, que para el uso que le doy me sirve más que de sobra.

No me enrollo más. Aquí tenéis el vídeo de este año:


He vuelto a programar en BASIC como en los 80

Las vacaciones son momentos en los que, afortunadamente, bajamos un poco el ritmo y tenemos tiempo —o al menos lo intentamos— hasta de aburrirnos. En esos ratos es bueno dejar volar la imaginación.

En uno de esos, recordaba que mi Miguel, amigo y compañero en Compiler Software, se había currado un juego en apenas un par de días para presentarlo al Concurso de BASIC 2020 de Bytemaniacos. Un juego sencillo y entretenido para una plataforma obsoleta, pero más viva que nunca gracias a la comunidad, como es el Sinclair ZX Spectrum.

En los años 80, en España había cuatro marcas/modelos de microordenadores de 8 bit que se repartían el mercado (no a partes iguales). A saber: Spectrum, Amstrad, MSX y Commodore 64. Como es bien sabido, yo en aquella época tuve el primero y puede jugar al segundo y tercero en casa de algunos amigos. Curiosamente, hasta la universidad no conocí a nadie que tuviera un Commodore 64.

Años más tarde, a primeros de este siglo, y en plena vorágine coleccionista, terminé por hacerme con los cuatro. Pero, si cierto es que los varios Spectrum que poseo tampoco los he usado demasiado, el resto apenas se han asomado por mi monitor CRT un puñado de veces. No sé, la verdad, cuando era pequeño las compañías sacaban versiones de sus juegos para casi todas las plataformas, y aquella curiosidad que tenía por saber cómo eran, ahora que tengo todas las facilidades se había desvanecido. Hasta ahora.

El objetivo era claro y sencillo: hacer un port del juego de Miguel para Amstrad CPC. Aprovechando que el juego está hecho en BASIC, y que el BASIC de los microordenadores de la época, aunque no es estándar, sí que se asemeja bastante de uno a otro, la idea es trasladar el programa "línea a línea", adaptando sólo lo imprescindible. Nada de añadir mejoras, optimizar el código o cambiar la manera de hacer las cosas.

Basic para niños. Con estos libros, regalo de mis padres, aprendí a programar
Basic para niños. Con estos libros, regalo de mis padres, aprendí a programar

¿Por qué el Amstrad CPC y no el MSX o el Commodore? La verdad es que me hubiera dado igual uno que otro, pero lo que me hizo decantarme por la máquina de Alan Sugar fue el emulador Retro Virtual Machine. Es un emulador que llevo usando un tiempo y cuya interfaz y funcionamiento me gustan bastante. Además comprobé que me ofrecía una posibilidad que iba a necesitar tarde o temprano, que no es otra que poder pasar ficheros de mi ordenador al Amstrad virtual, y viceversa.

Como comentaba, en su época solo tuve un Spectrum. Aunque un par de años después quise comprarme —mejor dicho, que me comprasen— un CPC 6128, finalmente fue un PC Compatible el que llegó a casa; en su momento no me hizo mucha gracia pero fue una decisión acertada. Pero sí que tengo el manual de instrucciones, y con eso es suficiente, ya que nos explica tanto las características de la máquina como la sintaxis de su dialecto de BASIC.

Cuando se programa para ordenadores antiguos, usando emuladores, lo normal es usar un editor de texto en tu ordenador y luego cargar el listado en el emulador de alguna forma más o menos automática. Para Spectrum contamos con la utilidad BAS2TAP, que convierte un listado BASIC en un fichero de cinta que se puede cargar en el emulador. Para Amstrad no encontré nada parecido. Pero, aunque lo hubiese encontrado, no tengo claro que lo hubiera usado; al no conocer la máquina, se necesita teclear en ella, con el manual a mano, y ver cómo se comporta ante las instrucciones que le das; es la manera más rápida de ir aprendiendo sobre la marcha.

Manual de usuario del Amstrad CPC 464
Manual de usuario del Amstrad CPC 464

La clave para sacar adelante un "proyecto" de este tipo es, lo primero, ponerse una meta corta y asequible. Dedicar todo, o gran parte del tiempo libre, a la consecución de ese proyecto. Y, por supuesto, robar alguna que otra hora de sueño. Pero no es lo único. En este caso, ayudó bastante el ir viendo progresos de forma rápida. También el ir compartiendo los avances con los compañeros de Compiler en nuestro grupo privado de Telegram, y que ellos te vayan animando y haciendo sugerencias y correcciones.

Me costó un par de semanas (a ratos) tener una primera versión completa. Durante ese tiempo aprendí algunas de las diferencias entre el Spectrum y el Amstrad, y tuve que darle vueltas a la cabeza para implementar alguna cosa de otra forma diferente. Aunque por mi trabajo me dedico a programar bastantes horas al día, para programar en BASIC tengo que "desaprender" muchos de los conceptos que he ido adquiriendo a lo largo de estos más de treinta años desde que escribí mi primera línea de código. Y no sólo eso sino que, recordemos, el objetivo es traducir el listado de la forma más directa posible, sin cambiar algoritmos ni optimizarlos.

Ya casi lo tenía, pero quedaba un último bug; el personaje hacía cosas raras al acercarse a los bordes superior o inferior del mapeado. Hablándolo con Miguel, me hizo ver dónde estaba el problema. En realidad su código y el mío funcionaban igual, pero por cómo yo había tenido que adaptar la parte donde se guardan los datos del mapeado, en su caso no afectaba y en el mío sí. Así que una vez arreglado todo, y ajustada la parte gráfica, llegaba el punto casi más arduo de lo que viene siendo hacer un juego: probar todo bien y pulir los detallitos.

Si tenéis curiosidad, en el repositorio donde está publicado el código fuente del proyecto, he añadido un documento técnico explicando los detalles más relevantes.

Y la decepción fue mayúscula al ir a probar el juego en un Amstrad CPC 464 (emulado). Y es que el menú no se pintaba bien, devolvía un error de sintaxis, al corregirlo el mapeado se pintaba también mal, el personaje se comportaba erráticamente... un desastre. Ni en las peores previsiones hubiera imaginado que algo así podría pasar.

Presa de la desesperación, lo comenté en el grupo de Telegram de desarrolladores retro donde, por suerte, me contestó Fran Gallego, toda una eminencia en el Amstrad, y comentándole cuáles eran los síntomas, y echando un ojo al código, supo orientarme sobre qué pasaba.

Algo me olía cuando, revisando con calma, me di cuenta de que en la pantalla del 464 indica que la versión de BASIC es la 1.0, mientras que el 6128 lleva la versión 1.1. Y es que, según me contó Fran, la versión 1.0 tiene un bug a la hora de imprimir caracteres en pantalla bajo según qué condiciones (no voy a entrar en detalles por no aburrir al personal). Yo creo que jamás en la vida habría imaginado que algo así podría ocurrir. Supongo que, revisando todo una y mil veces, y más por cabezonería que otra cosa, lo habría acabado sacando; no que hay un bug, sino que habría tenido que hacer los ajustes necesarios para que todo funcionase. Pero seguro que me habría costado días.

Afortunadamente, lo pude corregir en el mismo día y, tras algún percance más generando las versiones de disco y cinta, por fin pude publicar el juego en la página de Compiler y su código fuente en GitHub. Seguro que os podéis imaginar la satisfacción que da el llevar un proyecto a término, por pequeño y poco ambicioso que sea. Y también la sensación de escribir un programa que, al ejecutarlo, hace que unos muñequitos cobren vida en la pantalla. Esa sensación que experimenté hace más de treinta años por primera vez, en mi querido ZX Spectrum, y que me orientó a ser lo que soy profesionalmente hoy en día.

Dead End_ (Amstrad CPC)

Confío que éste no sea el único proyecto que saque adelante de todos los que imaginé este verano.

PS: Al final, entre unas cosas y otras, me ha llevado casi una semana redactar esta entrada. Para que veáis el ritmo que llevo.


Lecturas: Reina Roja

Un año después, comienza una nueva "maratón de lecturas veraniegas". Debido a mi rutina, el verano es el único momento en el que saco tiempo para leer. Algo que ha cambiado mucho desde que comencé este blog, cuando iba en transporte público al trabajo y devoraba libro tras libro.

El primero al que le he hincado el diente ha sido a "Reina Roja", de Juan Gómez-Jurado. Un libro que tengo desde el mismo día de su lanzamiento, el pasado 8 de noviembre, y que tenía ganas de leer. Y éste es, en resumen, el resultado:

No es más que el resultado de combinar mi ritmo rápido de lectura, tener poco tiempo durante el año para hacerlo y dar con un relato que puede que no sea el culmen de la literatura universal, pero que propone una trama y, sobre todo, una forma de contarla que te engancha y te impide hacer prácticamente otra cosa que no sea seguir devorando renglones hasta llegar al final.

Tampoco esperemos encontrar un giro espectacular en los acontecimientos, de esos que te dejan con el culo torcido porque, en líneas generales, una vez que se nos presenta el hilo conductor, más o menos podemos intuir cómo se va a desarrollar el asunto. Pero eso no quiere decir que no haya sorpresas, que las hay (al menos para mí). Seguramente seríamos capaces de resumir la historia en un par de párrafos. Pero lo interesante aquí es el viaje, el cómo se desarrollan los acontecimientos, los pequeños detalles, cómo vamos profundizando en la personalidad de los personajes, conociéndolos y, puede ser, empatizando con ellos.

Reina Roja
Reina Roja

Además, en mi caso, se añaden un par de puntos que otros lectores no encontrarán. Primero, el hecho de que la historia tenga Madrid como escenario añade un plus de cercanía, al conocer personalmente la mayoría de los lugares en los que transcurre la trama, y dejarme con ganas de conocer aquellos que no.

Por otro lado, el seguir al autor en Twitter, haber escuchado algunos de los podcasts en los que interviene, como Todopoderosos, y conocer un poco cómo piensa, su odio a los franceses, qué opina sobre ciertos temas, qué gustos tiene, su odio a los franceses, ayuda a que, cuando nos encontramos ciertos chascarrillos salpicando el texto, no podamos evitar esbozar una sonrisa de complicidad.

En resumen: el libro está bien, pero no es un Premio Nobel, no nos volvamos locos. Desde luego que se lo recomiendo a cualquiera que le guste un buen thriller. Creo que no quedará defraudado.

El año pasado me quedó pendiente "La leyenda del ladrón" para terminar (hasta el próximo octubre) con la bibliografía del autor. Y es posible que me ponga con él, si en vez de la variedad que proclamaba hace doce meses opto por una intención completista. La respuesta la encontraréis en próximas entradas de este blog.


Juegos: Red Dead Redemption II (PlayStation 4)

Red Dead Redemption II es todo un acontecimiento. Un título que llega con la vitola de "juego del año", firmado por Rockstar (cuyos productos me suelen gustar), acompañado por un gran despliegue de marketing y al que, durante las primeras semanas, la gran mayoría de mis contactos de PlayStation Network estaba jugando. Yo mismo he caído en la tentación de comprarlo demasiado anticipadamente, aun sin planes de ponerme con él —todavía andaba liado con el Zelda Breath Of The Wild— en un futuro cercano. Así que, aunque no he pagado su precio de lanzamiento (me costó 49,50€ frente a su PVP de 70€) lo podría haber adquirido más barato si lo hubiera hecho justo al empezar a jugar, ya que creo que ha llegado a estar por unos 35€.

Red Dead Redemption II (PS4)

Bien es cierto que también lo he comprado relativamente "pronto", ya que el juego fue lanzado el 26 de octubre de 2018, así que la etiqueta de barato o caro es relativa. Por comparar con otros juegos de la propia Rockstar, en su momento pagué 64,90€ por GTA IV (más otros 20 euritos de la expansión) y 52,45€ por GTA V. Por Red Dead Redemption pagué tan solo 12 euros, al comprarlo de segunda mano y jugarlo en 2015, bastantes años después de su lanzamiento —en mayo de 2010.

Es un juego largo, muy largo. No lleva contador de tiempo, así que ignoro el número exacto de horas que le he dedicado. Si echamos un vistazo en la web Howlongtobeat, la duración reportada es de 46 horas. Yo, entre pitos y flautas, he estado unos seis meses con él. Obviamente, no jugando todo el rato, pero se trata una cantidad de tiempo considerable. Como de costumbre, he completado la historia principal y algunas misiones secundarias, sin pretensión de llegar al 100%.

Visualmente es un juego impecable, lo cual lo hace más inmersivo

La parte online prácticamente no la he catado más que un rato, así que no tengo una opinión fundada. Supongo que podrá llegar a ser divertida pero, en mi caso, ni me apetece ni estoy en condiciones de dedicarle tiempo para disfrutarla.

En cualquier caso, lo primero que me gustaría precisar es que no me ha parecido estar ante un "juego de mundo abierto", como se suele calificar, sino un "juego de mundo muy, muy grande". El mapeado es inmenso, encontraremos un buen puñado de actividades que hacer, aparte de las misiones principales de la historia, las secundarias y las "tareas de coleccionismo". Pero eso no significa que estemos ante un sandbox que establezca unas reglas y que nos permita avanzar como queramos. Y eso es así por dos motivos principales: el peso de la narrativa (la historia que nos quieren contar) y la atención enfermiza por los detalles.

No solo encontraremos praderas y montañas nevadas. Las incipientes ciudades también tienen su protagonismo

Yo venía de jugar a The Legend Of Zelda: Breath Of The Wild y las primeras horas se me hicieron muy cuesta arriba; tanto que estuve a punto de abandonar el juego para una mejor ocasión. Y es que encontraremos bastantes misiones en las que se nos va indicando, paso a paso, lo que tenemos que hacer. De todas formas, creo que ya lo he comentado en alguna ocasión: no se me ocurre la manera de dar peso a la historia sin encorsetar el desarrollo del juego. En este caso debe de haber tantos miles de horas de diálogos, de animaciones, de detalles, que me da pena pensar que ni yo ni la mayoría de los jugadores vamos a disfrutar de ese trabajo artístico.

El control del personaje se hace un poco tosco. Se supone que lo han hecho así a propósito, pero viendo que es muy parecido al de juegos anteriores, al igual que toda la parte relacionada con los tiroteos, me da más por pensar que es una limitación del motor del juego o que no han querido innovar en esa parcela y han centrado la mayoría del esfuerzo en todo lo relacionado con la parte artística que, sí, es una maldita maravilla, tanto en el apartado gráfico como en el sonoro.

No quiero pensar la cantidad de horas empleadas en recrear este enorme escenario

Un mundo tan vasto también puede llegar a ser un inconveniente cuando queremos ir "al grano". En este juego tenemos varias maneras de hacer "viajes rápidos" de un punto a otro del mapeado, pero de forma bastante restringida. Podemos coger un medio de transporte, tren o diligencia, que nos permitirá movernos entre las diferentes estaciones o postas. También hay una opción de "teletransporte" que se desbloquea a partir de cierto momento pero que sólo está disponible desde nuestro campamento (o al menos no he visto manera de usarla de otra forma).

La diligencia nos puede servir, además de objeto de robo, para movernos cómodamente entre las diferentes localizaciones

Por último, podemos marcar un punto en el mapa, cabalgar y activar la "cámara cinematográfica". Si hacemos eso, nuestro personaje completará el recorrido de forma automática. Pero cuidado, porque si por el camino nos emboscan bandidos, nos veremos inmersos en un tiroteo sin darnos cuenta. Entiendo que el objetivo de todo esto es que exploremos todo el escenario, donde encontraremos multitud de misiones secundarias y de coleccionismo. Pero creo que, en cualquier caso, debería ser algo opcional, y deberíamos tener la opción de desplazarnos rápidamente, al menos a partir de cierto momento. Sé que me repito con esto, pero en ese sentido creo que la solución implementada por Zelda: Breath Of The Wild es mucho más ágil. Y no me impidió perder horas y horas explorando Hyrule, caminando o a caballo.

Molaría disponer del globo como medio de transporte, pero es solo una de las misiones del juego

El nivel argumental de las misiones es bastante variable. No voy a desgranar los detalles para no fastidiar sorpresas a quien no lo haya jugado. No faltan las "típicas del oeste" que nos podemos imaginar, como asaltos a diligencias, bancos, trenes, etc. El guión es bastante fan service; no esperemos ningún giro imprevisible. Además, se ve lastrado por el hecho de ser una precuela y, por tanto, conocer de antemano cómo va a acabar la historia. Es fácil echar cuentas y ver qué personajes de éste aparecían en el juego anterior y cuáles no.

¿Os imagináis cómo saldremos de ésta? Sí, lo de la derecha es un barranco con un río abajo

Pero no me puedo resistir a citar una que me ha parecido sumanente estúpida. Es una en la que tenemos que volar el puente de la vía del tren. Para finalizar la misión, nos hacen subir a la vía, coger la vagoneta y sacarla del puente para que termine empujándola el tren. ¿Tiene sentido?

Este puente está pidiendo a gritos una ración de dinamita

En resumen, Red Dead Redemption II me parece una obra de arte, aunque con las sucesivas actualizaciones me ha dado la impresión de que la calidad gráfica se ha resentido a costa de una mayor fluidez (quizás pensando en la experiencia online). La banda sonora es exquisita y aporta su punto de épica cuando toca. No voy a decir que no lo he disfrutado, que lo he hecho y mucho (aunque con altibajos). Pero quizás el listón estaba demasiado alto y me queda cierto regusto a decepción.

Sí, es tan escatológico como parece. No podía faltar la típica misión de "borrachos por el mundo"

El juego implementa un montón de localizaciones, personajes secundarios, misiones, mecánicas y coleccionables que, para alguien motivado y con tiempo, puede ser la gloria. El problema es que tampoco es necesario profundizar demasiado para completar la historia y, salvo que seas un auténtico forofo del western, no hay nada que te empuje a hacerlo.

Aquí el monumento a los padres de la patria en plena construcción

Veremos —algún año de estos—qué tal otros grandes lanzamientos del año 2018 que tengo ya comprados y pendientes de jugar, como Spiderman, God Of War, o Assassin's Creed Odyssey.

PS: Ya en la recta final del juego, y dejándome llevar por la "fiebre Rockstar" y por las rebajas de PlayStation, aproveché para comprar (nuevamente) el GTA V en versión digital para PlayStation 4. He de decir que jugué un ratillo online, porque a los suscriptores de Amazon Prime les regalaban —si no entendí mal— un apartamento en el nuevo casino de la ciudad, y conducir y hacer el gamba por las calles de Liberty City sigue siendo tan divertido como siempre, y mucho más (todo sea dicho) que los caballos de este Red Dead Redemption II.