GRASS (lenguaje de programación)

GRASS ( GRAphics Symbiosis System ) es un lenguaje de programación creado para crear animaciones de gráficos vectoriales en 2D . GRASS era similar a BASIC en sintaxis, pero añadía numerosas instrucciones para especificar la animación de objetos en 2D, incluyendo escala, traslación y rotación en el tiempo. Estas funciones eran directamente compatibles con el terminal de gráficos 3D Vector General para el que se escribió GRASS. Rápidamente se convirtió en un éxito entre la comunidad artística que estaba experimentando con el nuevo medio de los gráficos por ordenador , y es más famoso por su uso por parte de Larry Cuba para crear la animación original "atacar la Estrella de la Muerte no será fácil" en La guerra de las galaxias (1977).

Como parte de una asociación posterior con Midway Games , el lenguaje se adaptó a la Z Box basada en Z80 de Midway. Esta máquina usaba gráficos rasterizados y una forma de sprites , que requerían cambios extensos para ser compatibles, junto con cambios de color animados. Esta versión se conocía como ZGRASS .

La versión original de GRASS fue desarrollada por Tom DeFanti para su tesis doctoral de 1974 en la Universidad Estatal de Ohio . ^[1] Fue desarrollada en una PDP-11 /45 que controlaba una pantalla Vector General 3DR . ^[1] Como su nombre lo indica, se trataba de una máquina de gráficos puramente vectoriales . GRASS incluía una serie de comandos de dibujo vectorial y podía organizar colecciones de ellos en una jerarquía, aplicando los diversos efectos de animación a "árboles" completos de la imagen a la vez (almacenados en matrices). ^[1]

Después de graduarse, DeFanti se trasladó a la Universidad de Illinois, Chicago Circle . Allí se unió a Dan Sandin y juntos formaron el Circle Graphics Habitat (hoy conocido como el Laboratorio de Visualización Electrónica o EVL). Sandin se había unido a la universidad en 1971 y había construido el Sandin Image Processor o IP. El IP era una computadora analógica que tomaba dos entradas de vídeo, las mezclaba, coloreaba los resultados y luego recreaba la salida de TV. Lo describió como la versión en vídeo de un sintetizador Moog . ^[1]

DeFanti añadió el sistema GRASS existente como entrada al IP, creando el GRASS/Image Processor , que se utilizó a mediados de los años 70. Para hacer que el sistema fuera más útil, DeFanti y Sandin añadieron todo tipo de comandos "únicos" al sistema GRASS existente, pero estos cambios también hicieron que el lenguaje fuera considerablemente más idiosincrásico. En 1977, otro miembro de Habitat, Nola Donato, rediseñó muchas de las estructuras de control de GRASS en formas más generales, lo que dio como resultado GRASS3, un lenguaje considerablemente más limpio . [ ^1]

El trabajo de Larry Cuba en Star Wars se basa en la filmación semiautomática de un sistema GRASS que se ejecuta en una terminal Vector General 3D . El VG3D tenía un hardware interno que realizaba transformaciones básicas (escalado, rotación, etc.) en tiempo real sin interactuar con la computadora. Solo durante los momentos en que se presenta un nuevo escenario se produce la comunicación mucho más lenta con el lenguaje GRASS. Esto se puede ver en la secuencia, ya que las secciones iniciales de la película muestran la Estrella de la Muerte rotando y escalando muy rápidamente, mientras que las secciones posteriores que simulan el vuelo por la trinchera requieren que se muestren nuevos escenarios desde los "árboles" de GRASS. Se puede ver que aparecen en grupos.

En 1977, DeFanti conoció a Jeff Frederiksen, un diseñador de chips que trabajaba en Dave Nutting Associates . Nutting había sido contratado por Midway, la división de videojuegos de Bally, para crear un chip controlador de gráficos estandarizado . Tenían la intención de usarlo en la mayoría de sus futuros juegos de arcade, así como en una consola de videojuegos en la que estaban trabajando y que más tarde se convertiría en Astrocade . Midway estaba bastante interesado en ver el lenguaje GRASS ejecutándose en su sistema y contrató a DeFanti para que lo trasladara a la plataforma. Varias personas de Habitat, así como algunas de Nutting, trabajaron en el proyecto, al que se refirieron como Z Box . GRASS3 ejecutándose en él se convirtió en ZGRASS . ^[1]

La Z-Box era una máquina de gráficos rasterizados , a diferencia de los sistemas GRASS originales, por lo que, si bien la mayor parte del estilo GRASS3 se mantuvo en ZGRASS, agregó una serie de comandos dedicados a las imágenes rasterizadas. Esto incluía un amplio conjunto de comandos de transferencia de bloques de bits para simular sprites , algo que el hardware no incluía. ^[1] La obra nunca sería lanzada por Midway, pero Circle produciría máquinas basadas en ella como Datamax UV-1 .

La última versión de GRASS fue RT/1 , un port de GRASS a otras plataformas que divorciaba el lenguaje del modelo de visualización y permitía su porte a otras plataformas. Existieron versiones para MS-DOS , Microsoft Windows , plataforma SGI usando OpenGL , HP-UX , AIX , Macintosh y Amiga . El lenguaje sigue siendo similar a las versiones anteriores, por lo que no está claro el motivo del cambio de nombre.

Esta descripción se basa en los manuales originales de Bally así como en la descripción de ACM. ^[2]

Zgrass se basaba en un conjunto estándar de comandos BASIC y utilizaba la mayor parte de su sintaxis. En lo que Zgrass se diferenciaba de BASIC era en que todos los comandos eran, de hecho, funciones y valores devueltos, de forma similar al lenguaje de programación C. Si no había un valor de retorno obvio, se esperaba que una función devolviera 1 si tenía éxito y 0 si fallaba. Por ejemplo, el comando PRINT PRINT 10sería ilegal en BASIC, pero en Zgrass imprimiría 10 1, siendo el 1 el valor devuelto por second PRINT, lo que significa "He generado correctamente la cadena '10'".

Los programas en Zgrass se denominaban "macros" y se almacenaban como cadenas. Ambas rarezas eran deliberadas, ya que Zgrass permitía que cualquier cadena se convirtiera en un programa. Por ejemplo, MYBOX="BOX 0,0,100,100,2"define una cadena (sin necesidad de un $ en la variable como en Microsoft BASIC ) que contiene un fragmento de código de Zgrass. Simplemente escribiendo MYBOXa partir de ese punto se ejecutarían los comandos dentro. Esta característica se puede utilizar en lugar del GOSUBcomando más tradicional de BASIC, pero tiene la ventaja adicional de tener un nombre bien definido en lugar de un número de línea opaco. Además, el comando permanece en forma de cadena en la memoria y se puede manipular en tiempo de ejecución con operaciones de cadena estándar.

La mayoría de los intérpretes BASIC de la época convertían el texto de entrada en una versión tokenizada en la que cada uno de los comandos se reemplazaba por un único número (normalmente de un byte de longitud). Esto hacía que el programa se ejecutara más rápido porque no tenía que decodificar continuamente los comandos de las cadenas cada vez. El uso de macros basadas en cadenas por parte de Zgrass dificultaba esto, por lo que no se molestaron en tokenizarlo. En su lugar, incluyeron un compilador que podía utilizarse en cualquier macro en particular, lo que lo aceleraba muchas veces. Los programas solían consistir en una mezcla de macros compiladas y no compiladas.

Los números de línea eran opcionales en Zgrass y, por lo general, solo aparecían en las líneas que eran el destino de un GOTO. La mayoría de los intérpretes de BASIC requerían números de línea para cada línea de código, pero esto se debía a su uso en el "editor de línea": si necesitabas editar una línea en particular, la única forma de hacer referencia a ella era por número. Zgrass usaba un editor de pantalla completa más avanzado que eliminaba esta necesidad. Zgrass permitía que cualquier cadena actuara como un "número de línea", GOTO 10y GOTO MARKERambos eran válidos.

Zgrass también incluyó ramas sin nombre, utilizando la SKIPinstrucción , que se movería hacia adelante o hacia atrás un número determinado de líneas. Esto es importante en Zgrass ya que los números de línea eran opcionales y diferentes macros podían hacer uso de las mismas etiquetas. Por ejemplo, LOOPSTARTes probable que se encuentre alguna variación en muchos fragmentos de código y, por lo tanto, GOTO LOOPSTARTpodría resultar en un conflicto de nombres. El uso de SKIPevitó esta posibilidad.

En consonancia con su propósito original como lenguaje gráfico, Zgrass incluía numerosos comandos para realizar dibujos de forma sencilla. El sistema de coordenadas de Zgrass tenía un punto por cada píxel en el modo de alta resolución del chip gráfico de Nutting, lo que daba como resultado una cuadrícula de 320×202 píxeles. El Astrocade, por diseño, solo podía utilizar el modo de baja resolución de ese chip, una pantalla de 160×101 píxeles. Para evitar posibles problemas de mapeo, el punto cero del espacio de coordenadas se colocaba en el centro de la pantalla. De −160 a 160 eran posiciones X válidas, y de -101 a 101 posiciones Y válidas. Para su uso en el Astrocade, solo se utilizaban las posiciones positivas, mientras que en el UV-1 estaba disponible todo el espacio.

Zgrass agregó un conjunto bastante completo de funciones de matriz, ya que las matrices se usan ampliamente en gráficos. Esto incluía la capacidad de "capturar" partes de la pantalla en una matriz como un mapa de bits , que luego podría manipularse como cualquier otro elemento gráfico. Esto le permitió a Zgrass incluir una funcionalidad similar a la de los sprites en el lenguaje, algo que el hardware Nutting no incluía directamente. Otra característica que Astrocade no incluía era la capacidad de procesar matrices con una velocidad razonable, por lo que el UV-1 incluía una FPU suministrada por Zilog para un rendimiento adicional.

Zgrass incluyó tres prioridades (llamadas niveles ) que permitían que las macros se ejecutaran normalmente, o en niveles de "primer plano" o "segundo plano". Esto agregó una forma simple de multitarea que fue tremendamente útil en un lenguaje orientado a la animación. Los autores de juegos podían colocar rutinas de lectura de joystick en una macro configurada para ejecutarse en segundo plano, y luego el joystick se leería automáticamente cada vez que se completara la macro de dibujo actual. Las funciones colocadas en primer plano se ejecutaban antes que cualquiera de las dos, y a menudo se usaban para temporizadores y otras necesidades de "baja latencia". Zgrass incluyó una TIMEOUTfunción que llamaría a las macros en forma temporizada, lo que hizo que la implementación de temporizadores fuera muy fácil.

Zgrass también incluía una serie de comandos que "cubrían" CP/M, lo que permitía acceder al disco sin salir al símbolo del sistema. Podías guardar fácilmente las macros en archivos con nombre y cargarlas de la misma forma, lo que te permitía construir programas cargando varias macros desde el disco en un programa grande. Los comandos también hacían automáticamente una copia de seguridad de cada partida guardada. Se admitían características similares para el almacenamiento Compact Cassette , pero curiosamente la sintaxis no era paralela: los comandos de disco eran D-algo, como DPUT, pero los comandos de cinta no eran T-algo, como TPUT, sino algo-TAPE, como PUTTAPE.

Con programas construidos a partir de módulos seleccionados arbitrariamente, Zgrass necesitaba tener un mejor control sobre sus variables que BASIC. En BASIC todas las variables son "globales", por lo que si dos subrutinas usan la variable I, que se usa muy comúnmente como una variable de índice de bucle, entonces podrían establecer los valores de cada una, lo que conduce a problemas difíciles de depurar. Con Zgrass, un programador que cargara dos módulos podría encontrar fácilmente que ambos se usaban Icomo un contador de bucle, lo que podría causar problemas. Para abordar este problema, Zgrass consideró que las variables nombradas con letras minúsculas eran locales solo para esa macro, por lo que Iy ieran variables diferentes, globales y locales respectivamente. Curiosamente, los ejemplos proporcionados con el lenguaje no hacen un uso generalizado de esta característica, lo que puede confundir a los nuevos programadores que podrían no saber que existe la característica.

 SINCURVA = [ PROMPT "¿CUÁL ES EL DESPLAZAMIENTO?" DESPLAZAMIENTO DE ENTRADA x = -160 ángulo = 0 DESPLAZAMIENTO DE PUNTO + x , SIN ( ángulo ) * 80 , 3 ángulo = ángulo + 2 SI ( x = x + 1 ) < 159 , SALTAR -2 ] 
  
 
 
  
 
   

Este texto crea una nueva macro llamada SINCURVEque se puede llamar simplemente escribiendo SINCURVEen el símbolo del sistema o desde otras macros o programas. SINCURVE utiliza dos variables locales, x y angle , así como una variable global, OFFSET .

El PROMPT/ INPUTes una modificación del BASIC original INPUTque no solicitará la entrada si el usuario la escribe en la línea de comandos al llamar a la macro. En este caso, al escribir, SINCURVEaparecerá el mensaje y el programa esperará la entrada, mientras que al escribir SINCURVE 30se omitirá el mensaje y a OFFSET se le asignará automáticamente 30. Esto permite utilizar una sola macro tanto de forma interactiva como dentro de un programa como función.

POINTes un ejemplo de uno de los muchos comandos gráficos incluidos en el lenguaje Zgrass. POINTrequiere una ubicación X e Y, así como un color. En este ejemplo, el usuario proporciona OFFSETla posición x de la curva en la pantalla, mientras que la posición Y es proporcionada por la función trigonométrica , adecuadamente ampliada para su visualización (en este caso, 80 veces). El color se proporciona en la última entrada y, en este caso, es 3. El UV-1 utilizaba registros de color, por lo que 3 no implicaba un color en particular, sino un color seleccionado de la paleta actual.

El IFtambién es notable. Coloca un incremento, (x=x+1), delante de la prueba, una característica que normalmente no está disponible en BASIC. En este caso, se le indica a IF que llame SKIP -2si es verdadero, lo que retrocederá dos líneas y se puede usar en lugar de un GOTO, ya que no hay un objetivo de número de línea.