IMAGE(ID:4135/ima001)language for the interactive graphics Related languages
References: The major piece of work going on at Simon Fraser is the input and animation of Labanotation, a dance language widely used in the USA. The aim is to produce a system which will allow choreographers to input and see dance notation being performed while they are composing. A secondary aim is to produce films of existing dance and ballet scores. The work is similar to that proposed by the Royal College of Art using Benesh notation. The Department has a GT40 with a floppy disc attached to a 370/155 in the Computer Centre over a 300 baud link. The Centre's machine appears to be lightly loaded. A 3-minute job has a turn-round of less than 5 minutes. It is, therefore, quite viable to do interaction using the 370/155. The original work has been done by two dancers, Zella Wolofsky and Iris Garland. This was a batch system with the original dance notation being coded to allow input to a FORTRAN program. Output was initially by frames to a CALCOMP plotter. The centre has a spooling system which allows the CALCOMP output to be directed to a Tektronix. The GT40 was purchased from DEC and the floppy disc drive from another manufacturer. They are currently trying to obtain DEC DOS software and manuals privately so that they can run it on their floppy disc. Handlers have been written to allow Tektronix input and output to be simulated on the GT40. The system at the moment can take the coded Labanotation, run the program on the 370/155, and then display the results on the GT40 in real time. The dancers are currently simple stick figures and the display is changed 12 frames per second. The time from input of data to animation display on the GT40 is about 4 minutes or less. The next stage of the work is to provide means of inputting the Labanotation symbols directly using a menu of symbols and a lightpen. The last few time periods of the score being generated is available to the artist. He has the ability to scroll backwards and forwards through the score, displaying the actual dance figure at any point if he requires it. The long term aim is to move all the software to the PDP11 so that a low-cost viable system is produced which could be made available as a commercial system. Extract: IMAGE O'Brien: another attempt like Ira Cotton's at defining a graphics operating system. Not a lot here that is not in PIGS. It has its own language which is preprocessed by a STAGE2 program into Fortran. External link: Online copy at Chilton THE 'IMAGE' LANGUAGE 'IMAGE' has been designed in order to provide a language in which a relatively untrained person can program interactive graphic application programs. The language is designed for 'application programmers'; that is, persons who have some knowlege of programming but have most of their expertise in the field of their application. The language provides a basic set of graphical drawing commands and augments this with a powerful set of display modifiers. The language is procedure oriented and procedures may be easily defined within a program. An easy method has been provided to communicate with external programs written in other languages, so that an applications programmer can write sections of his program package in languages more suited to other tasks such as data manipulation or complex calculations. This feature has the virtue of easily allowing the programmer to add a graphics capability to an already existing applications package written in some other language. This permits the major emphasis of the syntax of this language to be for picture description and interaction control. The form of the execution flow control statements borrows from the format of the 'IFTRAN' FORTRAN preprocessor in order to provide a structured programming capability. The adoption of a simple data formatting scheme and the use of character string variables has allowed for the design of a language structure which uses no labels at all. This language has been designed so that it addresses the graphical problem directly in a hardware independent manner. A program written in this language should onerate regardless of which I/O devices are available. Device independence has been designed into the language so that particular device technologies have a minimum effect on the programs written in the language. For example, a program which uses a light-pen as an identifier on one system should operate just as well using a trackball and a cursor on another. The language treats all displays as identical and allows similar operations to occur on them. The programmer introduces device dependency only when he depends on the speed of a particular implementation. The myriad of input devices have been broken into six classes. Three of these classes are particularly concerned with interaction with the display. The other classes of interaction are general in nature and could be associated with a non-graphical program. Interaction control commands allow these graphical devices to be assigned to particular input functions. Each device behaves as a virtual device so that it is possible to use software techniques to allow one real device to perform the function of another. For example a positioning device such as a track-ball can be used to identify light-buttons, even though the concept of a light-button was derived from light-pen usage. GENERAL PROGRAM FORMAT The structure of an 'IMAGE' program consists of a number of independent blocks of executable code. There are four types of blocks: OBJECT, ACTION, ENTRY and PROCEDURE definition blocks. OBJECT blocks define graphical material to be displayed and ACTION blocks delimit code to be executed upon an identifier strike on that displayed material. ACTION blocks must follow their associated OBJECT blocks, thereby indicating that association. One ENTRY block may appear to allow initialization and it is usually the first block of executable code. The procedure blocks provide a local subroutine capability, necessary to prevent the duplication of code. Transformation operators may be applied to a PROCEDURE block to modify the displayed appearance of any graphical instructions discribed within the block. Statements within an OBJECT block are executed when the object is displayed by invoking the language statement DISPLAY. Any display code generated is marked (TAGged) so that an ACTION routine may be executed upon the stimulus of the displayed OBJECT. OBJECT blocks therefore define what is commonly refered to as a 'light-button'. An ACTION block defines the action to occur upon the stimulus of the preceeding OBJECT block. An ACTION block is basically a high-level interrupt handler routine. The identifier interrupt structure is disabled upon the execution of an ACTION block and is re-enabled by the use of a SEEK command. Execution is suspended at the end of an ACTION block by the use of a WAIT command. The program then reads as a series of OBJECT / ACTION pairs whose execution is interactively controlled. Extract: Introduction INTRODUCTION An interactive computer graphic system is a system which permits a 'conversation' to occur between the user and the computer, where the communications medium is a computer driven display. The complexities of the interactive dialogue, which result from the use of an interactive computer graphics system create complex programming problems. Conventional programming languages are executed serially, instruction by instruction, with the execution flow controlled by conditional statements. Although it is possible to write a graphics application program in this serial fashion it can be quite awkward to do so. The highly interactive nature of a graphics program lends itself to programming in an action oriented language. In this paper the design of a new interactive graphics language 'IMAGE' is presented. This language places particular emphasis on providing a graphics applications programmer the ability to easily program graphical interaction. From an examination of programs written in a variety of languages it was concluded that the writing of interactive graphical application programs is greatly aided when the following five facilities are available. a) Graphical input response facilities b) Graphical drawing facilities c) Structured programming constructs d) Data manipulation facilities e) Easy access to external software Graphical Input Response FacilitiesOne of the main requirements of any interactive process is to define the response of the system to each input. One approach which has been suggested by Newman is that this system should be considered as a finite state automaton where an 'action' is simply an input to the system and the corresponding 'reaction' is determined by the state of the system at the time. This approach to defining a program control sequence can be implemented such that the programmer is required to be specifically aware of all the states of his system in order to specify the action-reaction sequences, or the system can be designed such that these state transitions are transparent to the programmer. DIAL is an example of the former system, whereas ICPL is an example of the latter. Because it puts less of a burden on the programmer, it is felt that the latter method is superior. Most languages provide only highly device dependent information about particular inputs. This device dependence can be removed by providing suitable language constructs referencing a small number of idealized devices. Graphical Drawing FacilitiesThere are two common ways of providing graphical drawing facilities needed in a general purpose interactive graphical programming system. The first involves the notion of function or subroutine calls and does not require any modification to the base language from which they are called. Many graphic systems available today (especially those supplied by manufacturers) are of this type. Specific examples are GINO and GRAF. Graphical drawing facilities may also be provided by specific instructions within the language. This provides the capability of defining display procedures. This method , however, requires modification of the syntax of the base language or the creation of a complete new language. Display procedures provide distinct items on which to apply transformations, and therefore provide a compact, high-level method of defining pictures. EULER/G and GRAPPLE are examples of language systems providing this display procedure capability. Structured Programming ConstructsIt is very important that the base language provide good facilities for defining the overall structure of the program. Examples of languages exhibiting excellent program structure facilities are ALGOL and to a lesser extent, IFTRAN. Both these languages provide good constructs for iterative and conditional operations such as IF, WHILE and ELSE. A local subroutine capability is desirable, and provides a convienent method of implementing a display procedure capability. Data Manipulation FacilitiesA computer graphics program describes pictures in a numerical form and textual information in terms of character strings and it is therefore useful to have both numerical and character data types. In certain applications it is essential that a representation of a picture be stored in a dynamic data structure, thus providing the capability of manipulating and regenerating it. It may overburden the syntax of a graphics language to provide a generalized data structure capability, so, as a minimum, access to external facilities written in other languages should be provided. Easy Access to External SoftwareAny good programming'system should provide an easy and convenient access to external software packages. Very often an application program will require access to some external routines that are already provided in the computer system library or that already exist written in some other language like FORTRAN or ALGOL. The communication of data to external software should be in a simple manner, such as direct narameter references. We do not feel that these requirements are adequately met in any existing language. The 'IMAGE' language was designed to specifically satisfy the above criteria. A unique interaction control structure, along with a display procedure based picture description grammar and device independent interaction input facilities were combined to form 'IMAGE'. The remainder of this paper will present a brief description of the syntax of 'IMAGE'. Abstract: This paper addresses itself to the problems involved in programming an interactive computer graphics display. A list of graphical programming facilities considered necessary for an interactive graphic programming language is presented. An examination of several application programs, written in a variety of existing languages, revealed that many of these facilities are usually lacking. This paper presents the design of a new interactive graphics language 'IMAGE', developed specifically to satisfy the above criteria. The language places particular emphasis on providing a graphics application programmer the ability to program graphical interaction. The 'IMAGE' language utilizes the better features of several current graphic languages and combines these features with a unique interaction control structure. This OBJECT / ACTION control structure, the display picture description syntax and the hardware independent handling of input devices are the main features of the language, providing excellent graphical input response and drawing facilities. The device independent input / output structure permits the implementation of a portable language syntax, since there are no references to display hardware devices. All display references are performed through a virtual terminal. This paper contains a detailed description of the main features of the language and these features are illustrated in an example 'IMAGE' program. Extract: Introduction Introduction An interactive computer graphic system is a system which permits a 'conversation' to occur between the user and the computer, where the communications medium is a computer driven display. The complexities of the interactive dialogue, which result from the use of an interactive computer graphics system create complex programming problems. Conventional programming languages are executed serially, instruction by instruction, with the execution flow controlled by conditional statements. Although it is possible to write a graphics application program in this serial fashion it can be quite awkward to do so. The highly interactive nature of a graphics program lends itself to programming in an action oriented language. In this paper the design of a new interactive graphics language 'IMAGE' is presented. This language places particular emphasis on providing a graphics applications programmer the ability to easily program graphical interaction. From an examination of programs written in a variety of languages [1] it was concluded that the writing of interactive graphical application programs is greatly aided when the following five facilities are available. a) Graphical input response facilities b) Graphical drawing facilities c) Structured programming constructs d) Data manipulation facilities e) Easy access to external software a) Graphical Input Response Facilities: One of the main requirements of any interactive process is to define the response of the system to each input. One approach which has been suggested by Newman [2] is that this system should be considered as a finite state automaton where an 'action' is simply an input to the system and the corresponding 'reaction' is determined by the state of the system at the time. This approach to defining a program control sequence can be implemented such that the programmer is required to be specifically aware of all the states of his system in order to specify the action-reaction sequences, or the system can be designed such that these state transitions are transparent to the programmer. DIAL [41 is an example of the former system, whereas ICPL [3] is an example of the latter. Because it puts less of a burden on the programmer, it is felt that the latter method is superior. Most languages provide only highly device dependent information about particular inputs. This device dependence can be removed by providing suitable language constructs referencing a small number of idealized devices [5]. b) Graphical Drawing Facilities: There are two common ways of providing graphical drawing facilities needed in a general purpose interactive graphical programming system. The first involves the notion of function or subroutine calls and does not require any modification to the base language from which they are called. Many graphic systems available today (especially those supplied by manufacturers) are of this type. Specific examples are GINO [6] and GRAF [7]. Graphical drawing facilities may also be provided by specific instructions within the language. This provides the capability of defining display procedures [8]. This method , however, requires modification of the syntax of the base language or the creation of a complete new language. Display procedures provide distinct items on which to apply transformations, and therefore provide a compact, high-level method of defining pictures. EULER/G [9] and GRAPPLE [101 are examples of language systems providing this display procedure capability. c) Structured Programming Constructs: It is very important that the base language provide good facilities for defining the overall structure of the program. Examples of languages exhibiting excellent program structure facilities are ALGOL [11] and to a lesser extent, IFTRAN [12,13]. Both these languages provide good constructs for iterative and conditional operations such as IF, WHILE and ELSE. A local subroutine capability is desirable, and provides a convienent method of implementing a display procedure capability. d) Data Manipulation Facilities: A computer graphics program describes pictures in a numerical form and textual information in terms of character strings and it is therefore useful to have both numerical and character data types. In certain applications it is essential that a representation of a picture be stored in a dynamic data structure, thus providing the capability of manipulating and regenerating it. It may overburden the syntax of a graphics language to provide a generalized data structure capability, so, as a minimum, access to external facilities written in other languages should be provided. e) Easy Access to External Software: Any good programming'system should provide an easy and convenient access to external software packages. Very often an application program will require access to some external routines that are already provided in the computer system library or that already exist written in some other language like FORTRAN or ALGOL. The communication of data to external software should be in a simple manner, such as direct narameter references. We do not feel that these requirements are adequately met in any existing language. The 'IMAGE' language was designed to specifically satisfy the above criteria. A unique interaction control structure, along with a display procedure based picture description grammar and device independent interaction input facilities were combined to form 'IMAGE'. The remainder of this paper will present a brief description of the syntax of 'IMAGE'. Extract: The 'IMAGE' Language The 'IMAGE' Language 'IMAGE' has been designed in order to provide a language in which a relatively untrained person can program interactive graphic application programs. The language is designed for 'application programmers'; that is, persons who have some knowlege of programming but have most of their expertise in the field of their application. The language provides a basic set of graphical drawing commands and augments this with a powerful set of display modifiers. The language is procedure oriented and procedures may be easily defined within a program. An easy method has been provided to communicate with external programs written in other languages, so that an applications programmer can write sections of his program package in languages more suited to other tasks such as data manipulation or complex calculations. This feature has the virtue of easily allowing the programmer to add a graphics capability to an already existing applications package written in some other language. This permits the major emphasis of the syntax of this language to be for picture description and interaction control. The form of the execution flow control statements borrows from the format of the 'IFTRAN' FORTRAN preprocessor (Bezanson [13], Miller [12,14]) in order to provide a structured programming capability. The adoption of a simple data formatting scheme and the use of character string variables has allowed for the design of a language structure which uses no labels at all. This language has been designed so that it addresses the graphical problem directly in a hardware independent manner. A program written in this language should onerate regardless of which I/O devices are available. Device independence has been designed into the language so that particular device technologies have a minimum effect on the programs written in the language. For example, a program which uses a light-pen as an identifier on one system should operate just as well using a trackball and a cursor on another. The language treats all displays as identical and allows similar operations to occur on them. The programmer introduces device dependency only when he depends on the speed of a particular implementation. The myriad of input devices have been broken into six classes. Three of these classes are particularly concerned with interaction with the display. The other classes of interaction are general in nature and could be associated with a non-graphical program. Interaction control commands allow these graphical devices to be assigned to particular input functions. Each device behaves as a virtual device so that it is possible to use software techniques to allow one real device to perform the function of another. For example a positioning device such as a track-ball can be used to identify light-buttons, even though the concept of a light-button was derived from light-pen usage. in Computer Graphics 9(1) Spring, 1975 - includes Proceedings of the 2nd International Conference on Computer Graphics and Interactive Techniques, 1975, Bowling Green, Ohio view details Historically SKETCHPAD (Sutherland) was the first widely recognized general purpose graphics system. The SKETCHPAD system consists of a collection of subroutines called interactively through a menu selection process. The system allows pictures to be constructed hierarchically from other pictures and is noted for its use of a ring data structure to store picture descriptions. Kulsrud, Williams, and Giloi presented models for the definition of a general purpose graphics language, Kulsrud suggested that the first version of the proposed language have written commands and that it later be adjusted to accept input from graphics devices such as light pens and trackballs. The language she described was capable of picture description, manipulation, and analysis. Although it could be used with interactive applications programs, it was not an interactive language. Williams described a language that provided (i) data types with related operations particularly suited to graphical applications, and (2) the ability to add new data types and operations. For example, a "point,' could be a data type, and a specially defined addition operator would operate on that data type. The language was thus highly extensible, but it was not interactive. Giloi proposed a model to be used in constructing either subroutine packages for graphic display applications or graphical extensions to existing languages. In this model, pictures were described as a hierarchy of subpictures and picture primitives. Primitives were defined as anything for which there was a hardware generator in the display processor, placing limits on the device independence of a language developed from his model. An interactive version of the model was developed by extending APL to include graphics capabilities, and a non-interactive version was developed as a FORTRAN subroutine package. The general purpose graphics systems presented in recent years can be classified as (i) subroutine packages for graphics applications, (2) graphics extensions to existing languages, and (3) new languages possessing graphics capabilities. Graphics subroutine packages are most widely distributed particularly by manufacturers of graphics display hardware. Some example packages are GINO-F, GPGS, GRAF, DISSPLA, and EXPLOR. Most packages are limited to the manipulation of picture displays with few programming control or storage capabilities. Where such abilities are available they often serve specialized purposes as in WAVE, a package for waveform analysis. One exception is the VIP system where the user is able to combine the available system function subroutines into special purpose functions which can then be used in the same way that the original system functions were used. Extensions of an existing language such as Euler-G, IMAGE, APLBAGS, APLG, and PENCIL, provide a programmer with graphics capabilities as well as general programming features. Euler-G has excellent data structure definition facilities. IMAGE, an extension of FORTRAN, cannot provide the data structure description capabilities that are available in Euler-G, but it has the advantage of being based on the most widely distributed host language available. APLBAGS, APLG, and PENCIL, an extension of the MULTILANG on-line programming system, are truly conversational languages. GRASP, a PL/I extension, is a compiled language but it allows dynamic interaction. GRASP also allows the definition of models from which complex pictures can be created hierarchically. ESP3, an extension of SNOBOL4, is a non-interactive language from which many of the high-level concepts found in PIGLI are drawn. Language extensions are found mainly in experimental installations. Two complete graphics languages are METAVISU and GLIDE. Both take characteristics from a base language (PL/I and ALGOL, respectively) and add capabilities for defining, displaying, and manipulating pictures. Full languages are less widely distributed than subroutine packages or language extensions. in Proceedings of the 1978 annual conference 1978, Washington, D.C., United States view details |