Del código máquina virtual a tu pantalla

En sus pantallas gracias a la letra "G"

En sus pantallas gracias a la letra "G"

Glk

Hay una tremenda cantidad de lenguajes para ACs, cada uno con su propia máquina virtual, y aún más están siendo creados. Hay también un buen montón de plataformas ahí afuera, y nuevo hardware y nuevos sistemas operativos están apareciendo también a un ritmo nada desdeñable. Esto ha traido un problema que debería sonar bastante familiar si has leído los apartados previos. Cada vez que un nuevo sistema para ACs aparece, es necesario escribir un intérprete para cada una de las plataformas en las que se quieran jugar los juegos creados con ese sistema: Windows, DOS, Mac, Acorn, Amiga, BeOS, Unix, y muchos muchos más. Y cada vez que una nueva plataforma en la que podrían jugarse ACs aparece -digamos que la gente quiere jugarlas desde dentro de un MUD, o a través de un teléfono móvil conectado a Internet- la nueva plataforma necesita un intérprete Z, y un íntérprete TADS, y un intérprete Hugo, y un intérprete ALAN, y así seguiríamos. Más aún, una buena parte del trabajo necesario para escribir un intérprete, es esfuerzo malgastado. Mira, un intérprete tiene que hacer dos cosas más o menos independientes: procesar datos - parsear, mantener el estado de los objetos del juego, cosas así - y entrada/salida (abreviado como E/S, o en inglés I/O), que se ocupa de cómo debe mostrarse el texto que el programa ordena imprimir. Y salvo pocas excepciones (de las que nos ocuparemos en breve), la parte de proceso de datos no se preocupa de la parte de E/S. Simplemente la dirá a la parte de E/S "eh, imprime estas tres frases" (bueno, se lo dirá en código máquina), pero a la parte que procesa datos no le importa si esas frases aparecen con un tipo de letra caprichoso en una ventana gráfica con barras de scroll. De igual forma, la parte que se ocupa de la E/S sólo debe preocuparse de mostrar el material que le han ordenado mostrar. No le interesan los algoritmos por los que la parte de proceso de datos ha llegado a su decisión de qué imprimir. Sólo se interesa de imprimirlo realmente. Esto significa que, mientras que la parte de proceso de datos de todos los intérpretes de máquina Z será prácticamente idéntica, la parte de E/S variará drásticamente: el Frotz de DOS, diseñado para ser usado en un entorno en el que no hay posibilidad de varios tipos de letra, requiere unas rutinas para imprimir texto muy diferentes de las de WinFrotz. Y de forma similar, mientras que la parte de proceso de datos de diferentes intérpretes para Mac será bastante diferente - TADS e Inform y AGT y otros, simplemente no manejan los datos de la misma forma - en cambio la parte del intérprete que maneja el "look and feel", es decir la E/S, será muy similar, con independencia de qué máquina virtual esté siendo usada. Pero ya que hay que crear cada posible par, el trabajo acaba siendo repetido muchas veces. Permitanme presentarles Glk. Glk es un intento de hacer todo este trabajo más eficiente, separando las dos funciones del intérprete de ACs tradicional. Lo hace definiendo unas cuantas rutinas, escritas en el lenguaje C de programación, y recopiladas en la librería Glk. Los programadores familiarizados con el C pueden escribir aplicaciones Glk, que hagan sus cálculos y proceso de datos, y generen sus resultados en una forma que Glk pueda comprender, y librerías Glk (también llamadas "implementaciones de Glk") que adapten las funciones Glk para una plataforma concreta: WinGlk, XGkl, MacGlk, etc. El escritor de intérpretes ve reducido su trabajo a juntar las aplicaciones con las librerías. Si no está aún clara la utilidad de todo esto, miralo de esta otra forma. Digamos que en lugar de intentar llevar los lenguajes de ACs a las diferentes plataformas, lo que estamos intentando construir es un sistema ferroviario para llevar gente desde varios lugares de la costa oeste de los Estados Unidos - Seattle, Portland, San Francisco, Los Angeles, etc. - a ciudades en la costa este: Boston, Nueva York, Filadelfia, Washington, etc. El método anterior a Glk de líneas directas significaría construir vías desde Seattle a Boston, de Seattle a Nueva York, de Seattle a Filadelfia, etc. y después de Portland a Boston, de Portland a Nueva York, etc. Si quisieramos añadir una nueva ciudad de partida, sería necesario construir un conjunto nuevo de vias: San Diego a Boston, San Diego a Nueva York, etc. Y lo mismo ocurriría si añadimos un destino nuevo: tendríamos que construir de Seattle a Miami, de Portland a Miami, de San Francisco a Miami, etc. Lo que hace Glk es crear un centro. En nuestro ejemplo, digamos que es Omaha (Nebraska). Así, en lugar de construir vías directamente desde cada origen a cada destino, construimos de Seattle a Omaha, Portland a Omaha, San Franciso a Omaha, etc. y después de Omaha a Boston, Omaha a Nueva York, etc. Esto reduce drásticamente el número de vías que tenemos que construir. Y si aparece una nueva ciudad de origen, sólo tenemos que construir una vía: San Diego a Omaha. ¿Un nuevo destino? Una vía: Omaha a Miami. Y la gente que venga desde San Diego, hará transbordo en Omaha y llegará a cualquier destino, y la gente que venga desde cualquier origen en la costa oeste, puede hacer transbordo en Omaha y llegar a Miami. Así que pongamos que alguien escribe un nuevo lenguaje para hacer ACs, llamado ABC. No se necesita escribir intérpretes para ABC-Windows, ABC-Mac, ABC-Palm; en lugar de esto, simplemente escribe un intérprete ABC-Glk y todo el mundo en todas las plataformas para las que existan librerías Glk, podrán jugar juegos ABC. De forma análoga, si Toaster Technologias construyera el Cybertoaster, basta escribir una librería Glk-para-Cybertoaster, y ya tenemos instantáneamente al Cybertoaster preparado para jugar juegos Inform, TADS, Hugo o juegos de cualquier otro sistema para el cual exista un intérprete basado en Glk. Todo lo que los usuarios de Cybertoaster necesitan hacer es enlazar esos intérpretes con las librerías Glk para Cybertoaster. Puede que te preguntes: los intérpretes basados en Glk, toman la salida de las máquinas virtuales y la conviertene en algo que Glk pueda comprender. ¿Hay alguna máquina virtual cuya salida ya esté preparada para Glk sin requerir conversiones? La respuesta: puedes apostar que sí. Eso es Glulx.

Glulx e Inform Glulx

Hay, como se ha dicho en los apartados previos, muchas máquinas virtuales diseñadas para ACs. Algunas de ellas - la máquina virtual TADS y la máquina virtual Hugo, por ejemplo - pueden hacer cosas que la máquina Z no puede. Pueden manejar juegos grandes (más de 512k), por ejemplo, y hacer que muestren dibujos o que toquen sonidos, es mucho más simple que lograr lo mismo en la máquina Z. Sin embargo, para usar una de ellas, tienes que aprenderte el lenguaje asociado: TADS o Hugo. Muchos programadores Infrm han invertido mucho tiempo y energía para aprender Inform, y preferirían no tener que empezar a aprender un nuevo lenguaje desde cero. Glulx fue diseñado para resolver este problema. Glulx es una máquina virtual de 32 bits nota2.html cuyos compiladores están diseñados para tomar código fuente Inform y convertirlo en código máquina Glulx. Así que los programadores Inform pueden liberarse de las limitaciones de la máquina Z, y aprovecharse de la nuevas capacidades de la máquina Glulx, sin tener que aprender un lenguaje nuevo. Al menos en su mayor parte. Recordarás de la sección sobre Glk que había una excepción notable a la regla de que el proceso de datos y la entrada/salida son cosas separadas en la programación de ACs. La excepción ocurre cuando los programadores insertan opcodes en sus programas. Un opcode es una instrucción que se salta algunos de los pasos habituales en el proceso de programación. Imagina este proceso como una torre de robots, cada uno sobre los hombros de otro. Cada robot, sólo habla con el que tiene debajo. Así, un robot de la parte alta, le dice al robot que tiene debajo "Eh, imprime esta frase". Y este robot le dice al siguiente robot de debajo (el robot de E/S), "Vale, imprime la letra A en esta posición de la pantalla, en este color, y después imprime la letra B en esta otra posición, en este color..." Y ese robot lo traduce en "Pon puntos blancos aqui, y aqui, y aqui, y aqui..." Al final, verás unos puntitos blancos en tu pantalla, que parecen formar letras, que forman palabras que lees como parte de una historia. Pero ¿y si no quieres dejar a los robots la decisión de dónde deben ir las letras y qué aspecto deben tener? ¿y si quieres quitar de enmedio uno de los robots y hablar directamente con el robot de E/S y decirle "Vale, quiero la letra Q, en negrita en la posición (1,5) de la pantalla, y en color verde brillante"? Aquí es donde aparecen los opcodes. Normalmente, si tu juego está en Inform, tu escribirás todas tus instrucciones en Inform, y después dejarás al compilador que las convierta en código máquina. Pero a veces, cuando quieres un control más preciso - como cuando estás tratando de personalizar tu línea de estado, o si quieres algunos efectos especiales, como letras bailando en la pantalla de presentación- necesitas ponerlo en opcodes. Si estás compilando para la máquina Z, estos opcodes estarán escritos en ensamblador de la máquina Z, y tendrán un aspecto como @set_colour 2 4; (que significa "imprime a partir de ahora con texto negro sobre fondo verde") o @read_char 1 8 dummy i; (que significa "Espera hasta que se haya pulsado una tecla, o hasta que hayan transcurrido 8 décimas de segundo, lo que ocurra antes"). Los opcodes del ensamblador-Z están explicados en el "Inform Designer's Manual" y durante mucho tiempo se les consideró simplemente otra parte de Inform. Sin embargo, la llegada de Glulx cambió las cosas. Mira, el compilador clásico de Inform sabía cómo convertir el código fuente Inform en código máquina-Z y como cambiar los opcodes del ensamblador-Z en código máquina-Z. Pero mientras que el compilador de Glulx Inform sabe convertir el código fuente Inform en código máquina-Glulx, en cambio el ensamblador-Z le suena a chino. El compilador de Inform Glulx necesita que los opcodes estén escritos para Glk (en ensamblador de la máquina Glulx, en realidad). La librería estándar InformATE (la versión 6/7) incluye opcodes en ensamblador-Z, así que no compilará con Inform Glulx: necesitarás usar la librería InformATE biplataforma (versión 6/10), que está diseñada para que pueda usarse con juegos para la máquina Glulx o para la máquina Z (incluye opcodes para ambas, y elige unos u otros según cuál sea la máquina elegida como destino). Esto quiere decir que todos los truquitos que los autores de Inform habían aprendido relacionados con opcodes de máquina-Z, son inútiles para crear juegos Glulx. Si quieren que su juego compile para Glulx, necesitarán aprender todo un nuevo sistema para especificar el estilo del texto, crear efectos especiales, mostrar imágenes, tocar música, etc. Y de esto trata el capítulo dos.

En sus pantallas gracias a la letra "G"