GRASS (lenguaje de programación) , la enciclopedia libre

GRASS (Sistema de Simbiosis del Gráfico) fue un lenguaje de programación creado para grabar animaciones de gráficos vectoriales 2D. GRASS era similar a BASIC en sintaxis, pero agregó numerosas instrucciones para especificar la animación de objetos 2D, incluyendo escalamiento, traducción, rotación y cambios de color con el tiempo.Rápidamente se convirtió en un éxito con la comunidad artística que estaba experimentando con el nuevo medio de gráficos por computadora, y seguirá siendo más famoso por su uso por Larry Cuba para crear la original "attacking the death star will not be easy" animación en Star Wars.Una versión posterior que fue adaptada para soportar gráficos raster se conocía como ZGrass.

La versión original de GRASS fue desarrollada por Tom DeFanti para su doctorado en la Universidad Estatal de Ohio en 1974. Fue desarrollado en un PDP-11/45 que conduce una exhibición de Vector General 3DR, y como el nombre implica, esta era puramente una máquina de vector gráfico. 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" enteros de la imagen a la vez (almacenados en arrays). Fue esta versión que se utilizó para la animación de Star Wars, si vuelves a mirar esta parte de la película se pueden ver los árboles de objetos apareciendo en la imagen en varias ocasiones.

Después de la graduación, DeFanti se trasladó a la Universidad de Illinois, Chicago Circle. Allí se unió con 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 se dedicó a construir lo que consideraba la versión en vídeo de un sintetizador Moog, conocido como Sandin Image Processor, o IP. El IP era un ordenador analógico que tomaba dos entradas de vídeo, las mezclaba, coloreaba los resultados y luego volvía a crear la salida de TV.

DeFanti agregó el sistema existente de GRASS como entrada al IP, creando el GRASS / Image Processor, que fue utilizado a mediados de los años setenta. Para hacer el sistema más útil, DeFanti y Sandin agregaron todo tipo de comandos "únicos" al sistema GRASS existente, pero estos cambios también hicieron que el lenguaje fuera mucho más idiosincrático. En 1977 otro miembro del Hábitat, Nola Donato, re-diseñó muchas de las estructuras de control de GRASS en formas más generales, resultando en el GRASS3 considerablemente más limpio.

El trabajo de Star Wars de Larry Cuba se basa en una proyección trasera de un sistema GRASS que se ejecuta en una terminal vectorial. A medida que el terminal contiene los vectores (y puntos) en la memoria interna, el sistema es capaz de realizar transformaciones básicas - escalado, rotación, etc. - en tiempo real sin interactuar con el ordenador o el lenguaje. Es sólo durante los tiempos cuando se presenta un nuevo escenario que las comunicaciones mucho más lentas con el lenguaje GRASS tiene lugar. Esto se puede ver en la secuencia, ya que las secciones iniciales de la película muestran que la Estrella de la Muerte es girada y escalada muy rápidamente, mientras que las secciones posteriores que simulan el vuelo hacia abajo de la trinchera requieren nuevos paisajes para ser buscados en GRASS "árboles", que es fácilmente visibles.

En 1977 DeFanti fue presentado 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 de controlador de gráficos estandarizado. Tenían la intención de utilizarlo en la mayoría de sus futuros juegos de arcade, así como una consola de videojuegos en la que estaban trabajando, que más tarde se convertiría en la Astrocade. Midway estaba muy interesado en ver el lenguaje de GRASS funcionando en su sistema, y contrató a DeFanti para portarlo a la plataforma. Un número de personas en el Hábitat, así como algunos de Nutting, trabajó en el proyecto, que se conoce como el Z Box. GRASS3 corriendo en él se convirtió en Zgrass.

La Z-Box era una máquina gráfica raster, a diferencia de los sistemas GRASS originales, por lo que mientras que la mayor parte del estilo GRASS3 se mantuvo en Zgrass, agregó una serie de comandos dedicados a las imágenes ráster. Esto incluía un extenso conjunto de comandos de transferencia de bloques de bits para simular sprites, algo que el hardware no incluía. El trabajo nunca sería lanzado por Midway, pero el Círculo produciría máquinas basadas en él como el Datamax UV-1.

La última versión de GRASS fue RT / 1, un puerto de GRASS para otras plataformas que divorciaron el lenguaje del modelo de pantalla y le permitió ser portado a otras plataformas. Existían versiones para DOS, Windows, plataforma SGI usando OpenGL, HP-UX, AIX, Macintosh y Amiga. El idioma sigue siendo similar a las versiones anteriores, por lo que la razón para el cambio de nombre no está claro.

Esta descripción se basa en los manuales originales de Bally así como.

Zgrass se basó en un conjunto estándar de comandos BASIC y utilizó la mayor parte de su sintaxis. Donde Zgrass difería de BASIC era que todos los comandos eran de hecho funciones y valores devueltos, 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 10 sería ilegal en BASIC, pero en Zgrass esto imprimirá 10 1, siendo el 1 el valor devuelto por la segunda PRINT, que significa que "exito en la salida del string '10'".

Los programas en Zgrass se denominaron "macros" y se almacenan como cadenas. Ambas singularidades 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 $ como en BASIC) que contiene un fragmento de código Zgrass. Simplemente escribiendo MYBOX a partir de ese momento, ejecutaría el comando (s) dentro. Esta característica se puede utilizar en lugar del comando GOSUB más tradicional de BASIC, pero tiene la ventaja añadida de tener un nombre bien definido en lugar de un número de línea opaco. Además, el comando sigue siendo una cadena 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 era convirtieron el texto de entrada en una versión "tokenized" en la que cada uno de los comandos fue reemplazado por un solo número (normalmente un byte largo). Esto hizo que el programa funcionara más rápido porque no tenía que decodificar continuamente los comandos de las cadenas cada vez. El uso de macros basados en string de Zgrass hizo esto difícil, así que no se molestaron con la tokenización. En su lugar, incluyeron un compilador que podría utilizarse en cualquier macro en particular, acelerándolo muchas veces. Los programas a menudo consisten en una mezcla de macros compiladas y no compiladas.

Los números de línea eran opcionales en Zgrass, y típicamente sólo aparecieron en líneas que eran el objetivo de un GOTO. La mayoría de los intérpretes BASIC necesitaban 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 se necesitaba editar esa línea, la única forma de referirse a ella era por número. Zgrass utilizó un editor de pantalla completa más avanzado que eliminó esta necesidad. Zgrass permitió que cualquier cadena actuara como un "número de línea", GOTO 10 y GOTO MARKER eran válidos. Zgrass también incluía ramas sin nombre, usando la instrucción SKIP, que avanzaría o retrocedería un número dado de líneas.

De acuerdo con su propósito original como lenguaje de gráficos, Zgrass incluyó numerosos comandos para el dibujo simple. 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, dando una cuadrícula de 320 × 202. El Astrocade, por diseño, sólo podía usar el modo de baja resolución de ese chip, una pantalla de 160 × 101. Para evitar posibles problemas de mapeo, el punto cero del espacio de coordenadas se colocó en el centro de la pantalla. -160 a 160 eran ubicaciones X válidas y -101 a 101 ubicaciones Y válidas. Para el uso en el Astrocade usted utilizó los lugares positivos solamente, mientras que en el UV-1 el espacio entero estaba disponible.

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

Zgrass incluía tres prioridades (llamadas niveles) que permitían que las macros funcionaran normalmente, o en niveles de "primer plano" o "de fondo". Esto agregó una forma simple de multitarea que era tremendamente útil en un lenguaje orientado a la animación. Los autores de juegos podrían colocar rutinas de lectura de joystick en un conjunto de macros para ejecutar en segundo plano y, a continuación, el joystick se leería automáticamente cada vez que terminara la macro de dibujo actual. Las funciones colocadas en primer plano se ejecutaban antes, y se usaban a menudo para temporizadores y otras necesidades de "baja latencia". Zgrass incluyó una función TIMEOUT que llamaría a las macros en una base cronometrada, haciendo la implementación de temporizadores muy fácil.

Zgrass también incluyó una serie de comandos que "cubrieron" CP / M, lo que permitió acceder al disco sin salir al prompt de comandos. Podrías guardar fácilmente macros en archivos con nombre y cargarlos de la misma manera, lo que te permitirá construir programas cargando varias macros del disco en un programa grande. Los comandos también hicieron automáticamente una copia de seguridad de cada guardar. Las funciones similares fueron soportadas para el almacenamiento de cintas de casete, pero extrañamente 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 algo-TAPE, como PUTTAPE.

Con programas construidos a partir de módulos seleccionados al azar, 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 (muy común) entonces podrían establecer los valores de cada uno, lo que conduce a problemas difíciles de depurar. Bajo Zgrass un programador de carga de dos módulos podría encontrar fácilmente que tanto i utilizado como 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 sólo para esa macro. Curiosamente, los ejemplos proporcionados con el lenguaje no hacen un uso generalizado de esta característica, lo que potencialmente confunde a los nuevos programadores que podrían no ser conscientes de que la característica existe.

SINCURVE=[PUNTUAL "QUÉ ES EL OFFSET ?" OFFSET de ENTRADA x=-160 ángulo=0 OFFSET de PUNTO+x,PECADO(ángulo)80,3 ángulo=de ángulo+2 SI (x=x+1)<159,SKIP -2] 

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

El PROMPT / INPUT es una modificación de la entrada de base original que no pedirá la entrada si el usuario la escribe en la línea de comandos al llamar a la macro. En este caso, teclear SINCURVE dará lugar a que aparezca el mensaje y el programa esté esperando la entrada, mientras que escribir SINCURVE 30 omitirá el mensaje y OFFSET se asignará automáticamente 30. Esto permite que una sola macro se use interactivamente y dentro de un programa como Una función.

POINT es un ejemplo de uno de los muchos comandos gráficos incluidos en el lenguaje Zgrass. PUNTO requiere una ubicación X e Y, así como un color. En este ejemplo, el usuario suministrado OFFSET mueve la posición x de la curva en la pantalla, mientras que la posición Y es suministrada por la función trig, ampliada adecuadamente para su visualización (en este caso, 80 veces). El color se suministra en la última entrada, y en este caso es 3. Los registros de color UV-1 utilizados, por lo que 3 no implica un color en particular, sino un color seleccionado de la paleta actual.

El IF es igualmente 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 dice a la IF que llame a SKIP -2 si es true, lo que hará retroceder dos líneas y se puede usar en lugar de un GOTO.

Bibliografía

• Thomas DeFanti, Jay Fenton and Nola Donato, "BASIC Zgrass—a sophisticated graphics language for the Bally Home Library Computer", Proceedings of the 5th annual conference on Computer graphics and interactive techniques, ACM SIGGRAPH Computer Graphics, Volume 12 Issue 3 (August 1978), pp. 33–37
• Thomas DeFanti, "Language Control Structures for Easy Electronic Visualization", BYTE, November 1980

Otras lecturas

Bally Alley Miscellaneous Documentation - includes PDF versions of scans of the UV-1 Zgrass manual

• Haciendo del Gráfico de Ordenador para Guerras de Estrella, explicación de 10 minutos del trabajo de Larry Cuba.