GRASS ( GRAphics Symbiosis System ) es un lenguaje de programación creado para crear secuencias de comandos de animaciones de gráficos vectoriales 2D . GRASS era similar a BASIC en sintaxis, pero agregaba numerosas instrucciones para especificar la animación de objetos 2D, incluida la escala, la traducción y la rotación en el tiempo. Estas funciones fueron admitidas directamente por 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 gráficos por computadora , 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 Star Wars (1977). ).
Como parte de una asociación posterior con Midway Games , el lenguaje fue portado a la Z Box basada en Z80 de Midway. Esta máquina utilizaba gráficos rasterizados y una especie de sprites , cuya compatibilidad requería grandes cambios, además de animar cambios de color. Esta versión se conoció como ZGRASS .
La versión original de GRASS fue desarrollada por Tom DeFanti para su doctorado en 1974 en la Universidad Estatal de Ohio . tesis. [1] Fue desarrollado en un PDP-11 /45 con 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 mudó a la Universidad de Illinois, Chicago Circle . Allí se unió a Dan Sandin y juntos formaron el Circle Graphics Habitat (hoy conocido como Laboratorio de Visualización Electrónica , o EVL). Sandin se unió a la universidad en 1971 y construyó el procesador de imágenes Sandin , o IP. La IP era una computadora analógica que tomaba dos entradas de video, 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 agregó el sistema GRASS existente como entrada al IP, creando el procesador de imágenes/GRASS , que se utilizó a mediados de la década de 1970. Para hacer que el sistema sea 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 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, dando como resultado GRASS3 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 hardware interno que realizaba transformaciones básicas (escalado, rotación, etc.) en tiempo real sin interactuar con la computadora. Sólo durante los momentos en que se presentan nuevos escenarios se producen comunicaciones mucho más lentas 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 girando y escalando muy rápidamente, mientras que las secciones posteriores que simulan el vuelo por la trinchera requieren la visualización de nuevos escenarios desde los "árboles" de GRASS. Estos se pueden ver apareciendo 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 luego se convertiría en Astrocade . Midway estaba muy interesado en ver el lenguaje GRASS ejecutándose en su sistema y contrató a DeFanti para migrarlo a la plataforma. Varias personas de Habitat, así como algunas de Nutting, trabajaron en el proyecto, al que denominaron Z Box . GRASS3 ejecutándose en él se convirtió en ZGRASS . [1]
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 imágenes rasterizadas. Esto incluía un extenso conjunto de comandos de transferencia de bloques de bits para simular sprites , algo que el hardware no incluía. [1] El trabajo nunca sería publicado 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 , una adaptación de GRASS a otras plataformas que separó el lenguaje del modelo de visualización y permitió su adaptación a otras plataformas. Existían versiones para MS-DOS , Microsoft Windows , plataforma SGI usando OpenGL , HP-UX , AIX , Macintosh y Amiga . El lenguaje sigue siendo similar al de las versiones anteriores, por lo que el motivo del cambio de nombre no está claro.
Zgrass se basó en un conjunto estándar de comandos BÁSICOS y utilizó la mayor parte de su sintaxis. En lo que Zgrass se diferenciaba de BASIC era en que todos los comandos eran en realidad 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 10sería ilegal en BASIC, pero en Zgrass esto imprimiría 10 1, siendo 1 el valor devuelto por second PRINT, lo que significa "Generé con éxito la cadena '10'".
Los programas en Zgrass se denominaban "macros" y se almacenaban como cadenas. Ambas rarezas fueron deliberadas, ya que Zgrass permitió que cualquier cadena se convirtiera en un programa. Por ejemplo, MYBOX="BOX 0,0,100,100,2"define una cadena (no es necesario $ en la variable como en Microsoft BASIC ) que contiene un fragmento de código Zgrass. Simplemente escribir MYBOXa partir de ese momento ejecutaría los comandos internos. 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 puede manipularse en tiempo de ejecución con operaciones de cadena estándar.
La mayoría de los intérpretes BÁSICOS de la época convertían el texto de entrada en una versión tokenizada en la que cada uno de los comandos era reemplazado por un único número (normalmente de un byte de longitud). Esto hizo 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 hizo que esto fuera difícil, por lo que no se molestaron con la tokenización. En cambio, incluyeron un compilador que podía usarse en cualquier macro en particular, acelerándolo muchas veces. Los programas a menudo consistirían en una combinación 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 objetivo de un archivo 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íneas": si necesitaba editar una línea en particular, 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 permitía que cualquier cadena actuara como "número de línea" GOTO 10y GOTO MARKERambas eran válidas.
Zgrass también incluyó ramas sin nombre, usando la SKIPinstrucción, que avanzaría o retrocedería 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 utilizar las mismas etiquetas. Por ejemplo, es probable que se encuentre alguna variación LOOPSTARTen muchos fragmentos de código y, por lo tanto, GOTO LOOPSTARTpodría provocar un conflicto de nombres. El uso SKIPevitó esta posibilidad.
De acuerdo con su propósito original como lenguaje gráfico, Zgrass incluía numerosos comandos para dibujar 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, dando una cuadrícula de 320×202. El Astrocade, por diseño, sólo podía utilizar 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 fueron ubicaciones X válidas y -101 a 101 ubicaciones Y válidas. Para su uso en Astrocade, se utilizaron solo las ubicaciones positivas, mientras que en UV-1 todo el espacio estaba disponible.
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 permitió a Zgrass incluir una funcionalidad similar a un sprite 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 a una velocidad razonable, por lo que el UV-1 incluía una FPU suministrada por Zilog para mayor rendimiento.
Zgrass incluía tres prioridades (llamadas niveles ) que permitían que las macros se ejecutaran normalmente, o en niveles de "primer plano" o "de fondo". Esto agregó una forma simple de multitarea que fue tremendamente útil en un lenguaje orientado a la animación. Los autores de juegos podrían colocar rutinas de lectura del 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 ellas y, a menudo, se utilizaban para temporizadores y otras necesidades de "baja latencia". Zgrass incluyó una TIMEOUTfunción que llamaría macros de forma cronometrada, lo que facilitaba mucho la implementación de temporizadores.
Zgrass también incluyó una serie de comandos que "cubrían" CP/M, lo que permitía acceder al disco sin salir del símbolo del sistema. Puede guardar fácilmente macros en archivos con nombre y cargarlos de la misma manera, lo que le permite crear programas cargando varias macros desde el disco en un programa grande. Los comandos también hicieron automáticamente una copia de seguridad de cada guardado. Se admitían funciones similares para el almacenamiento en casete compacto , 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 más bien 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, que se usa muy comúnmente como variable de índice de bucle, entonces podrían establecer los valores de cada una, lo que conduce a problemas difíciles de depurar. En Zgrass, un programador que carga dos módulos podría encontrar fácilmente que ambos se utilizan Icomo contador de bucles, 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 Ieran ivariables 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 tal vez no sepan que existe la característica.
SINCURVA = [ PREGUNTA "¿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 ángulo , 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 comando 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 se asignará automáticamente 30 a OFFSET. Esto permite usar una sola macro tanto de forma interactiva como dentro de un programa como una 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 proporcionado OFFSETmueve la 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 usó registros de color, por lo que 3 no implicaba un color en particular, sino un color seleccionado de la paleta actual.
Esto 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 dice al IF que llame SKIP -2si es verdadero, lo que retrocederá dos líneas y se puede usar en lugar de a GOTO, ya que no hay un número de línea objetivo.