¡Ah! La gente, siempre la gente…
Por estos azares de la vida me he encontrado en la tesitura de colaborar en la adaptación y adecuación de unos gráficos creados para ser utilizados en soportes modernos a una plataforma de 8 bits.
Las siguientes observaciones sirven para cualquier plataforma de 8 bits, si bien por ser el motivo que ha originado este texto me referiré mayormente a la versión de Commodore 64 y así de paso ya tendremos un documento sobre este tema.
Partimos de que ya tenemos hecho una videoaventura, en este caso el autor Dwalin acababa de publicar Las Aventuras de Rudolphine Rur en www.rudolphinerur.com cuando publicó un tweet algo alarmante :
El subrayado es mío.
Visto lo visto me invocaron para hacer una intervención de emergencia en calidad de grafista retrosado, acción que lleve a cabo dando lugar a una versión más acorde para con la máquina que lo iba a mostrar.
Antes de empezar tomemos como muestra una de las pantallas originales que sirvieron de plantilla para realizar la conversión a las diversas plataformas de 8 bits.
Evidentemente esta imagen no es soportada por ninguna máquina del siglo XX. Lo que nos lleva al primer punto:
Conoce a tu pareja de baile
O lo que es lo mismo es de vital importancia conocer las características tanto de la máquina como del programa o programas que vamos a utilizar para portar con ciertas garantías un juego del siglo XXI al siglo XX.
Maluva AKA SC2DAAD del maestro Uto es la herramienta de implementación utilizada para incluir de forma cómoda pantallas a los juegos creados con DAAD.
En mi desconocimiento y revisando las pantallas de las diferentes versiones del juego que nos atañe llegué a la conclusión (equivocada) de que los gráficos ocupan el 50 % de la pantalla en las máquinas de 8 bits.
Afortunadamente una consulta al maestro aclara la cosa:
“En realidad no es que reserve media pantalla. Mi herramienta permite hacer gráficos de los pixeles que quieras de alto, hasta pantalla completa. Y DAAD permite definir lo que es la zona de gráficos y de textos. Lo que pasa es que la proporción 50/50 suele quedar bastante bien, así que las imágenes suelen andar por los 96 pixeles de alto (dado que tienen que ser , por limitaciones técnicas, múltiplo de 8, asi que 100 no vale).”
Aclarado este punto cabe añadir alguna de las mejoras y peculiaridades de esta herramienta que nos aclara el propio autor:
“Ahora bien… en CPC y en C64 metí dos modos gráficos que no soportaba el DAAD original, lo cual requiere una parafernalia de interrupciones severa, por eso no me podía permitir que metiera la altura que le diera la gana al autor, así que… en CPC con gráficos en modo 0, y en C64 con gráficos en Multicolor, son de 96 pixeles de alto, a no ser que se usen (en C64) gráficos en HiColor (entonces sí que puedes poner la altura que te dé la gana).”
Aquí tenéis el enlace a esta herramienta http://ngpaws.com/downloads/DAAD/MALUVA/
El programa se ejecuta sin parámetros desde el símbolo de sistema y podemos invocar la ayuda desde la línea de comandos sobre una plataforma concreta escribiendo:
SC2DAAD CPC HELP, SC2DAAD C64 HELP, etc. para obtener más detalles.
Ahora bien, Maluva no admite la reubicación del texto como si lo hace el DAAD y siempre determina el ancho completo de la pantalla por la altura X que hayamos determinado
Además, por regla general, la paleta usada arriba afecta al texto de abajo, así que hay que intentar, en las máquinas que usan paleta (como CPC), que el 0 sea negro (o el fondo que sea de tu juego, y el 1 sea negro).
Y hasta aquí la intervención y aportaciones aclaratorias del maestro Uto.
¿Qué tiene esto que ver con mi huevo?
Ya voy…
Lo primero y antes de empezar a echar pestes de Dwalin he de darle las gracias, a él y al resto de autores que se toman la molestia, por versionar sus creación a las plataformas clásicas de 8 bits.
Dicho esto voy a arremangarme para empezar a daros de bofetadas. Pero por comodidad me voy a dirigir a ti, que al fin y al cabo eres el que se supone está leyendo esto.
He empezado este soliloquio con una premisa impepinable, hay que conocer las limitaciones de la máquina que vamos a abordar.
En este punto igual nos encontramos con un problema recurrente: la monogamia galopante de los amantes de cada sistema Retro. Lo que da como resultado que deberemos ir tocando puerta a puerta para informarnos de las peculiaridades de cada sistema.
Por de pronto la memoria es finita y en los 8 bits escasa. Esto hará que tengas que meter tijera en el juego, principalmente en la carga gráfica o recurrir a soportes que no existían en su día como el Dandanator…
Yo de eso no tengo ni idea. Me podría informar, pero estoy escribiendo por otro tema, por lo que ese problema te lo dejo a ti.
¿Entonces esto de que va?
Esto va de adaptar los gráficos creados en soportes actuales a plataformas de 8 bits, cosa que por lo general sirve no solo para este caso en concreto.
Pero venga, vamos a empezar que sino no acabo y tengo cosas que pixelar.
Hoy en día, al igual que Dwalin, puedes hacer esta pantalla:
Pero claro vamos a portar ese gráfico a una máquina de 8 bits:
Si tienes prisa puedes saltarte esto al punto “El tema empieza aquí” aunque te recomiendo que lo leas solo por respeto a la máquina a la que quieras portar tu obra.
ZX Spectrum
Una de las peculiaridades del ZX Spectrum es su sistema de vídeo, al ser capaz de mostrar una matriz de 256x192 pixeles, pero la resolución de color es únicamente de 32x24 chars, por lo que grupos de 8x8 píxeles comparten información de color.
Dicha información de color o atributos consiste en: Color de fondo o paper, color de tinta o ink, atributo de brillo, y un atributo flash.
El color de fondo se aplica a los pixels 0, y el color de tinta que se aplica a los pixels 1, pudiendo seleccionarse cada uno entre siete colores.
El atributo brillo aumenta el brillo de los colores (excepto el negro, que no varia), por lo que en pantalla muestra en total hasta 15 colores (siete por dos niveles de brillo, más el negro)
El atributo flash hace que los dos atributos de color fondo/tinta se intercambien varias veces por segundo, creando un efecto de parpadeo. Que nos da igual en este asunto que nos concierne.
Así, tenemos 256x192 = 49152 bits = 6144 bytes destinados al bitmap (2048 bytes para cada tercio de pantalla) y 32x24 = 768 bytes dedicados al color, brillo, y flash, totalizando un total de 6912 bytes.
El problema de tener distintas resoluciones para el bitmap y el color obliga a adoptar soluciones ingeniosas para minimizar las colisiones entre colores, fenómeno conocido como “attribute clash” en el mundo anglosajón y “color clash” por estos andurriales. El “attribute clash” permite reducir el tamaño necesario para vídeo a 6,75 kB y en las manos adecuadas no parece un impedimento (¿Eh, Mac?).
MSX Mode 2
El Modo 2 es el modo gráfico de alta resolución de 256x192 píxeles del MSX. Los chars de 8X8 cuentan de dos colores de una paleta fija de 16 colores (15 + transparente).
Como peculiaridad, los char de MSX tienen la propiedad de tener dos colores por cada línea de 8 píxeles, el color de fondo (Background Color) y el color de encima (Foreground Color), pudiendo mostrar 16 colores simultáneos en un solo Char.
Amstrad CPC Mode 0
El Amstrad CPC en su Mode 0 muestra 160 x 200 píxeles ladrillo con 16 colores simultáneos de una paleta de 27 (o 32) pero en el modo Full Screen (?) se muestran 192 x 272 píxeles ladrillo.
La paleta Amstrad CPC (antigua) consta de 27 colores, a pesar de que el sistema de video (Gate Array y CRTC) en realidad puede manejar 32 colores. A esto hay que sumar que que la paleta está pensada para ser utilizada con dithering, o lo que es lo mismo, con entramados que generan aparentemente colores intermedios.
Esto explica en gran medida la peculiar y colorista paleta del CPC..
Pero no explica el porqué del uso (al igual que el Commodore 64) del pixel ladrillo, que estira cada píxel en una relación de 1 x 2 en comparación con el del MSX o el Spectrum que son de 1 x 1.
.
Commodore64 Multicolor
Este modo muestra 160×200 píxeles ladrillo, 3 colores únicos más un color común en cada char de una paleta de 16. Criticada hasta la saciedad es una paleta pensada para la combinación de colores por dithering al igual que la del CPC con la diferencia de que está orientado a la creación de sprites (eso lo digo yo).
Ya pasó
El orden de presentación de los sistemas corresponde a mi criterio personal. Si nos ponemos tiquismiquis, por año de aparición el Commodore 64 sería el primero de la lista, seguido del Spectrum, del MSX y por último el Amstrad CPC. Todo esto lo comento para que tengas claro que no hay dos sistemas iguales.
Está claro que este guirigay de modos gráficos es un problema a la hora de adaptar las pantallas creadas en sistemas modernos.
¿O no?
Pues no. Afortunadamente los productivos aficionados de cada plataforma han desarrollado herramientas específicas para poder abordar el diseño gráfico desde máquinas actuales que incluyen la posibilidad de importar las imágenes a las particularidades de cada formato.
El tema empieza aquí
¿Te has quedado en cómo han quedado las pantallas?
Efectivamente, bien no.
Podrías pensar que es cosa del editor gráfico que he usado para hacer la conversión. Podría ser.
Cada máquina tiene su propio editor/conversor… en plural y hay algunos que hacen su trabajo mejor que otros, pero no te vuelvas loco.
Para empezar con Multipaint tienes más que suficiente.
Programa que te puedes descargar desde aquí: http://multipaint.kameli.net/
Es un solo programa que te permitirá abordar la tarea de convertir imágenes para diferentes plataformas con un editor más que decente.
Pero ya la he liado, he convertido la pantalla completa sin tener en cuenta que debería ocupar más o menos la mitad de la pantalla superior.
Y aquí es dónde empiezo a darle de guantazos a Dwarlin y al que se le ocurra esta brillantez:
Esto es una chapuza de muy señor mío. No tiene otra denominación… Bueno sí, puta mierda.
Veamos qué pasó cuando se convirtió a Commodore 64:
Ni tan mal. En esta ocasión la conversión automática de la pantalla ha funcionado de forma aceptable cosa que no sucede en otras ocasiones, creeme.
Pero no es tanto el problema de la conversión de la pantalla como la deformación de la misma lo que me ha hecho escribir esta parrafada.
Me recuerda a cuando adaptaron las películas de Cinemascope a los televisores de 4:3, pero a la inversa.
Y aquí viene el meollo del asunto.
Volvamos un rato a los televisores de 4:3 y el Cinemascope.
El Cinemascope fue la respuesta de Hollywood para que la gente fuese a los cines. Ante la pujante proliferación de cadenas televisivas y la emisión en TV de películas se sacaron un formato que en principio era imposible trasladar a la TV. Un formato tan especial que requería nuevos cines para poder ser proyectados, la pantalla equivalía a un 16:9 de la época.
Pasaron los años y las franquicias de esos films buscaron la forma de sacar rédito a las viejas glorias.
Encontraron caminos a cual más mejor peor para todos.
La primera era la obvia, cortar lo que no entraba…
La otra opción era hacer una suerte de travelling por la pantalla…
O mezclar ambos métodos…
También en ocasiones se optó por estrechar la pantalla con resultados estilizantes…
Pero reducirla en escala no, porque en aquellas TV no se apreciaba nada.
Todo maravilloso.
Por el camino del beneficio económico las obras acabaron mutiladas o deformes, perdiendo todo el sentido.
He de aclarar que esto sucedió en los U.S.A
Afortunadamente si se hicieron adaptaciones reducidas en escala para Europa que mantenían el “aspect ratio” que le llaman y resultan más fieles con la obra original.
Vale, poco te importa esto.
Pues si eres el autor debería importarte.
Ahora entenderás porque.
Intervención de emergencia
Paso 1
Una vez puesto en contacto con Dwarlin le pedí que me mandase todos los ficheros utilizados para la creación de la versión de Commodore 64.
Que sepas que todo esto empezó porque Josepzin (Zanni), uno de los guardianes del foro Commodoremania creía que ese comentario en el tweet no era nada halagüeño.
Una vez recibí el material me encontré con tres ficheros: Uno que contenía los gráficos originales que sirvieron de base para la conversión, otro con las pantallas generadas para Commodore 64 con extensión .kla y una última que contenía lo necesario para generar la pantalla de carga que, por lo visto, debía ser en alta resolución (Hires) que afortunadamente Multipaint soporta.
Paso2
Valorar el calado de la intervención.
Primero había que mirar si la intervención era realmente necesaria, una rápida revisión mostró graves problemas en algunas de las pantallas, que no daban ninguna pista de lo que querían representar. Otras mostraban distorsiones demasiado acentuadas y el resto si bien era aceptable mostraba discrepancias entre los marcos.
Había que intervenir.
¿Como arreglar este desaguisado?
Aplicando todas las trampas que he ido aprendiendo durante todos los años que llevo peleando con los píxeles, no queda otra.
Pongamos que en este punto son las 22:00.
En ese momento todavía no he contado cuántas pantallas hay, a ojo de buen cubero veo unas treinta.
De los Apeninos a los Andes
Lo primero fue determinar cuál eran los elementos que se repetían en las pantallas. En este punto he de decir que lo habitual es que haya escenarios que se repiten con algún añadido. Y lo sabes.
Pero el elemento que se repite sí o sí en todas las pantallas es el marco del juego.
Ya sé que tú lo sabías ;D
La tradición de las aventuras gráficas da gran relevancia al marco del juego. El motivos es sencillo de entender, es un elemento que va a estar ahí en todo momento desde el principio hasta el final.
El marco en este caso venía sustentado por el protagonista de la aventura.
Rudolphine Rur estaba en la parte inferior derecha en todas las escenas fuera de un recuadro bastante austero. Supongo que Dwalin ha hecho el marco así para destacar al bicho, bien pensado. O eso, o se le ha aparecido la virgen.
En las imágenes originales se muestra a Rudolphine Rur a una escala pequeña como la que se le supone debería tener. La resolución de la imagen original lo muestra en detalle.
Vale, ahora ya sabía que era esa mancha que veía en las pantallas de la versión de C64.
Lo primero es abrir el Gimp, Photoshop o algún otro programa que te permita cargar capas y abrir una pantalla de c64 (una de 320x200; teniendo en cuenta que en C64 los 160 píxeles, de la pantalla de 160x200, se multiplica por dos al ser pixel ladrillo) en formato PNG.
Sobre esa pantalla añades los elementos que van a conformar el marco y haces una composición que pueda quedar medio bien. Una vez lo tienes lo guardas en PNG.
Abres el Multipaint eliges el formato del sistema al que quieres importar la imágen, una vez transformada puedes guardarlo en el formato que necesites y et voila!
¿Ves que fácil?
Esta imagen servirá de marco para la creación del resto de pantallas en el editor con capas.
Tras cargarlo lo duplicas en una capa superior, vacías la ventana bajo la cual iremos añadiendo las imágenes originales correspondientes a cada pantalla y echas el candado para no liarla.
¿Me sigues? ¿Pillas la importancia de este paso?
Haciendo esto te aseguras que en los siguientes pasos el marco no sufra de conversiones forzadas a cada nueva pantalla y si las hay estas serán mínimas.
Son las 23:00
Ya tengo el marco. He quedado en avisarle a Dwarlin de mi opinión de si es viable la intervención. No hay prisa, una pequeña comprobación me sacara de dudas.
Una vez tengo la imagen base (el marco) inserto la pantalla original debajo.
Y aquí viene el motivo por el que te he contado lo del Cinemascope…
Esa es la escala de la pantalla.
Podría haberlo dejado así o podía intentarlo reducir para ser más acorde con la versión original online.Pero no.
Rudolphine Rur no puede ser más pequeño, es el narrador, el protagonista omnipresente de la aventura y sus rasgos se diluyen a una escala más pequeña bajo las limitaciones de las pantallas de 8 bits.
No queda otra que manipular los escenarios.
En este punto solo puedo aconsejarte que hagas caso al instinto. Tendrás que mover, escalar, reescalar y rehacer pantallas pero todo sea por un bien mayor: La adaptación de tu obra a uno de los ancestrales sistemas clásicos Retro.
Hay pantallas que como esta requieren de más modificaciones. A la 1:00 llevo 20 pantallas de 41.
A las 5:00 de la mañana faltan seis. A las 13:30 una vez revisado por última vez mando un correo con todo el material.
Doy por terminada la intervención de emergencia y aviso a Dwarlin mediante un Tweet..
Unas pocas horas más tarde ya teníamos disponible la versión intervenida.
Fin.
Epílogo y flexiones dos veces
No he querido ver como se han realizado el resto de conversiones. Requerirían más intervenciones de emergencia, seguro, Las aventuras conversacionales han evolucionado y los parsers de hoy hacen del DAAD una rareza, y lo sabes.
Tu trabajo, vuestro trabajo, el de difundir vuestra obra hasta las plataformas Retro es algo encomiable pero…
La cruda realidad es que las aventuras conversacionales son un género de nicho y si eso lo trasladamos al Retro es el género de nicho del nicho.
Luego hay que tener en cuenta que el perfil de muchos de los creadores es el de escritores (salvo honrosas excepciones) lo que redunda en pantallas prescindibles.
Viendo el poder de las herramientas actuales parece de rigor tratar de mostrar las obras de la mejor manera posible. Imaginarse una aventura para Spectrum con gráficos de Mac (el monstruo de las screens de Spectrum) es el sueño húmedo de los amantes del género. Una utopía a la que debemos aspirar, la edad de oro aún está por llegar.
Igor Errazkin, Errazking
Agradecimientos
Agradecimientos a las entradas de las diferentes wikis (en especial a cpcwiki.eu y a la Wikipedia) que he consultado para disponeros la información sobre las resoluciones de pantalla de cada sistema comentado. Eso sí, a ver si dejamos de hablar en pasado de sistemas que mantenemos con vida a día de hoy.
Mi agradecimiento a los que crecieron viviendo el surgimiento y la desaparición de las aventuras conversacionales en la mal llamada edad de oro y han mantenido esto al punto de mantener vivo el género en el mayor número de sistemas.
Pienso en Rockersucker, Miguelsky, Bieno… gente que además de mantenerlo vivo se esfuerzan en hacerlo en las plataformas que vieron nacer este género, unos grandes.
Mención especial a Uto, que en esta historia representa al mago de Oz que ha facilitado la herramienta que ha dado lugar a estas conversiones. Sin su aportación no hubiese tenido que intervenir, de eso estoy seguro.
Mal que me pese también he de agradecer a Josepzin su solicitud de intervención ;) Al fin y al cabo son los usuarios/jugadores quienes dan sentido a estas producciones y es a ellos a quienes van dirigidos estos esfuerzos.
Y a ti también Dwalin, mis dieses, olé tus cojones toreros, te has metido en una embajada así, tú solo, algún tirón de orejas te daría pero lo dejamos en un abrazo virtual que es lo que se estila.
Me vienen a la cabeza los ecos de las críticas de quienes lo hubiesen hecho mucho mejor, pero que por no hacerlo mal no hacen nada.
En fin.
¡Ah! Y que no se me olvide…
Mi agradecimiento a ti, por tomarte la molestia de leer esto, señal de que tienes alguna inquietud o interés en el tema, que no es poco…
#True
Postdata:
Sí, he dejado algunos aspectos del tema sin tocar por ser ajenos a la intervención