I PRELIMINARY DESIGN AIMS
II PIGS
A Screen layout
B Menu structure
C Commands
D Arguments
E PIGS LOG
F PIGS MACROS
G Changing states
H Graphic I/0
I Errors and messages
III SOOP
A Menu skeleton
B Handling playback
C Link formats
IV CONCLUSION
We want a powerful, natural-to-use facility for making movies using SPROGS. In designing such a system for the PDP15, a central problem has been that SPROGS itself is a very rich language. There are many ways, in general, to describe a given animated sequence. This is not a problem but an asset to the expert user. It is the novice film-maker we are concerned about - he may have difficulty making a start.
Eventually, we would like to present a limited system capable of making simple movies to the animator who is just beginning - and allow him to discard it if it becomes restrictive. We will offer him a more or less rigid data structure for cels and movements descriptions and a set of SPROGS routines for combining these into film sequences. Indeed, many users will not need the full flexibility of SPROGS.
In order to pick a good, limited data structure for movies, we propose to implement a basic facility on the PDP for experimenting with SPROGS. This system SOOP (SPROGS On the PDP15), is discussed in more detail in Part III of this paper. It is hoped that early film-making attempts with SOOP will suggest good data structures for cels, movements and sequences and provide SPROGS routines to combine the structures into movies.
When basic SOOP is completed it will exist as a set of programs called from an interactive command system, PIGS (PDP INTERACTIVE GRAPHICS). PIGS will handle menuing, command and argument specification, and diagnostics. It will also maintain a log, help files, and recovery facilities. Finally, PIGS will provide a standardized graphic I/O package.
Considering interactive graphic systems, PIGS is an attempt to separate command specification and graphic input-output from computational and data base maintaining code. A limited amount of control is, however, allowed the latter over PIGS.
This separation provides the principal reason for implementing SOOP in PIGS. It is inevitable that the order, number and structuring of commands in SOOP will change over a period of time because it is so difficult to predict how interaction will occur. PIGS will minimise the editing and debugging necessary because the meaning of a command (the program associated with it) remains unaffected by such changes. Thus, building PIGS first will speed the implementation of SOOP.
But there are several important advantages in implementing an interaction controller such as PIGS. Firstly, it allows each user to personalize his version of SOOP by altering the command structure. Furthermore, interactive systems other than SOOP may be easily implemented. Finally, a library of programs defining commands in PIGS subsystems will have similar parameter-passing techniques.
Below are details of some preliminary design ideas for PIGS.
As can be seen from the sketch below. PIGS uses a fixed screen layout including light-buttons, typed input area, and message area. Note that there are several sorts of light buttons, located in different areas.
One of the principal services of PIGS is, in fact, to manage groups of light-buttons. The buttons are grouped into states, called menus. Activating a light button may cause a new menu to appear, or may leave the current display unaltered.
The user controls interaction by providing PIGS with a text description called a MENU SOURCE (MNS) file. The description contains information about the grooping of commands into menus. The following information is given for each command:
1. Command name 2. Number of arguments 3. Name of associated program 4. Name of next menu 5. Initial message adjacent to button.
Some of these items are optional. The syntax for the MNS file is not yet fully specified, but a skeleton illustrating menu grouping is given in Part III below.
At any time after entering PIGS, the user has the option of re-structuring interaction by editing the MNS file, He must then produce a MENU BINARY (MNB) file by invoking an assembler built into PIGS. The MNB object is put out to the disc as a direct access binary file containing one block per menu. Since the MNB file controls menu organisation in sub-systems like SOOP, each user can keep his own version oi a system by providing the desired MNB file in his disc area.
Each menu is composed of 24 commands or less. Issuing a command causes PIGS to look first for arguments. When these are completed, the program associated with the command name in the MNS file is entered via a pre-compiled jump table. The first two entries in this table are reserved for routines which affect linkage to SPROGS files and PIGS MACROS (PMACROS, below). It is possible that FOCAL routines may also be linked in this manner.
There are several other ways to activate commands other than hitting light-buttons. The first six commands in every menu are related to the push-buttons at the bottom of the screen. Of course, the command names associated with the buttons are displayed above them, but these may or may not be sensitive, depending upon how reliable they continue to be. (The main value of push-buttons will be under user program control when real time interaction prohibits detecting stylus bits on light-buttons).
The final method of issuing a command in PIGS is to type the command name on the currently-active teletype. All of these methods may be mixed freely according to which is most convenient at the moment.
Suppose a user issues the command "SETXY" by pointing at a 1ight-button. How will he specify its two arguments, XCOORD and YCOORD? At times he might wish to type XCOORD and point with the stylus at the Y-axis co-ordinate, YCOORD. PIGS allows arguments to be explicitly typed or provided by a set of routines called ARGUMENT GETTERS (ARGET's).
In the "SETXY" situation above, PIGS would save the currently active menu and display the ARGET commands. Among these would be found the command TYPE which allows any number of arguments to be entered, free format, on the active teletype device. Another command, YPOS, enters the Y-co-ordinate of the stylus as the next argument when a push-button is depressed. The ARGET menu is not exited until either all arguments are filled, or an EXIT button is touched. Many such ARGETS will be provided as standard PIGS commands but the user will probably add his own (possibly only temporarily in SPROGS or FOCAL).
If the user had initially typed in the command SETXY, PIGS free-format input would allow him to indicate arguments to be filled (using ARGET) by typing the character, * . On ending typed input with a carriage return or altmode, the ARGET menu would appear so that the remaining values could be specified. Note that there is no reason for an ARGET to retrieve one value only - XYPT could retrieve both of SETXYs' arguments as an (X,Y) tablet co-ordinate.
Argument values, which are either double precision numbers or 5/7 ASCII strings, are stored away in FORTRAN common blocks. Each argument is classified as string, number, or omitted (to be assigned some default value by the command program) . Since variable argument list lengths are allowed, the number of arguments specified by the user is also given.
FORTRAN, MACRO 15 and FOCAL programs which define the action of a command will get their arguments from the common blocks using a set of FORTRAN ARGUMENT PUTTER routines (you've guessed it, ARGPUTS) . These functions also issue mode mismatch (string arguments that were supposed to be numbers and vice versa) diagnostics and assign program-specified default values to omitted arguments).
Before the program associated with a command is actually entered, a log entry for the command is prepared and output to the PICS LOG. The LOG is a direct access, fixed size, 5/7 ASCII disc file. If during a session the file becomes full, PIGS asks the user to provide a DECTAPE for dumping. The LOG must be fixed length to allow it to survive a system crash without a .CLOSE being issued.
The LOG provides a record of commands, diagnostics and messages issued during a session. Entries will be identified as one of the above three types. The LOG should help in debugging PIGS and sub-systems such as SOOP. It may be feasible to use the LOG as data for programs to locate common trouble spots and to suggest more efficient MNS menu structures.
PIGS uses the LOG for a purpose other than debugging. A RECOUP command will be provided which will attempt to execute the commands in specified portions of the LOG as a PIGS program. We hope this will aid recovery after system crashes.
During a session, a user may find that he uses the same set of commands continuously, varying only one or two arguments. A PIGS MACRO facility is provided which operates internally somewhat like the RECOUP command. All PMACROs exist as distinct 5/7 ASCII disc files. Each macro is merely a series of typed commands for PIGS. Arguments may be specified by the ARGETs. Thus a PMACRO can be defined before or during a PIGS session using any available text editor. On executing a PMACRO, the ARGET menu will appear whenever arguments left unspecified by the macro are encountered. Execution then continues until the PMACRO file is exhausted, at which time new commands may be issued by the user. PMACROs will not be particularly fast, a fact which may encourage users to rewrite them in FORTRAN or FOCAL as soon as they prove valuable.
Within a particular menu, each command has information concerning the next PIGS state to retrieve from the disc. After each command has been executed, PIGS examines the new menu name to see if it is the one currently on display. If not, it writes out the current menu, pulls in the new menu data block from the MNB file on the disc, and computes the new light-button display file. Subsequent command names are searched for first in the current menu and then in a list of global commands resident in core. Some of these globals are displayed but most are not. One of those not displayed is the menu-changing program itself, MNC. Command programs and users may execute this routine to jump states immediately. Programs to save and restore the current menu state will also be provided.
PIGS attempts to standardize graphic I/O in sub-systems by providing flexible routines for graphic output and display on the PDP display. The STYLII package for sketched drawings makes co-ordinate input from tablet, lightpen, DMAC, paper tape, teletype, merely a switch setting. The user may structure the data as he desires and use it point by point. Light-button "pointing" with tablet or lightpen is interchangeable provided the user follows a fixed button display format.
PIGS will be able to output graphics using not only SPROGS but to a more usable version of VTPRIM.
Error messages are output to the display and LOG by a single PIGS utility routine. Messages are stored by number as part of the HELP file on disc. Any number of messages may be added within a PIGS session, The program written must choose what course of action to take after issuing a diagnostic. Various utilities will be provided to cause PIGS to change menus, execute the last instruction again, or end the session.
Messages other than those pertaining to errors, such as prompting, will appear either in a different format or on a different portion of the screen. A utility for displaying a text string or value adjacent to each light-button is planned.
Since SOOP will be implemented as a sub-system (PIGLET ?) of PIGS, a reasonable way of illustrating its structure is to give its MNS description. In an actual MENU SOURCE file, the five items of information listed in IIB would be given for each command. In the example below, however, only command names and comments have been given for brevity. Global command and push-button information has also been omitted. The number preceding each item groups it into a menu. A command name numbered N is also a menu name if there are any items numbered N+1 directly beneath it. Distinct menus may not have the same name. Slashes set off comments.
In this section on SOOP we also outline some ideas about the playback of sequences and the kind of information that will be sent across the computer link.
0 PIGS
1 COMMAND BUILDER
1 TEXT EDITOR
1 NEW VTPRIM /ALL VTPRIM COMMANDS INCLUDED
1 LOGIN 19O6A
1 SPROGS /ALL SPROGS COMMANDS INCLUDED
/BUT NOT LISTED HERE
1 FOCAL
1 HELP
1 RECOUP
1 SOOP
2 PIGS /Returns to PIGS level 0 menu
2 SPROGS
2 FOCAL
2 NULL FILES
3 SOOP
3 SKETCH
4 NULL FILES /Closes open file, if any
4 DRAW
4 ERASE
4 CLEAR FILE
4 VISIBILITY
4 LINE TYPE /DXDY,SETPOINT DXDY,VEC etc
4 MOVE LINE
4 MOVE VERTEX
4 DISPLAY ALSO
4 OPEN FILE /Closes current file, starts new one
3 SELECTION DESCRIPTION
4 NULL FILES
4 QUANTIZE /draw cell class description
4 DELETE NODE
4 INSERT NODE
4 DISPLAY ALSO /displays another cell for reference
4 CLEAR FILE
4 OPEN FILE
3 PCURVE
4 NULL FILES
4 X PATH
4 Y PATH
4 TIMED /SET sampling rate
4 STROBE /Play back PCURVE
4 DISPLAY ALSO
4 DELETE NODE
4 MOVE NODE
4 MOVE CHAIN / move n points together
5 SET CHAIN
5 MOVE
4 OPEN FILE
3 RHYTHM DESCRIPTION
4 NULL FILES
4 METRONOME SPEED /TIMING AID
4 FREQUENCY FILE /ONES AT FIXED RATE
4 MUSICAL SCORE /Translate sheet music
4 WITH STROBE /RHYTIM DESCRIPTION WITH MOTION
4 OPEN FILE
2 VIEW MAGTAPE
2 PLAYBACK SPROGS
3 NULL FILES
3 USE LIBRARY /FOR SKELETON DISPLAY OF CELLS
3 STRAW MODE /QUICK DRAWS
3 COLOURS DISPLAYED
3 COMPUTED SPEED /VS. PRECOMPUTED BY SPROGS
3 DYNAMIC SPEED / CONTROLLED BY THERMOMETER
3 FIXED RATE
3 FROM - TO FRAME
3 ONE FRAME
END OF FILE
A distinguishing feature about the computation and display of a movie sequence is the strain it places on our physical resources. The resources in question are chiefly :-
- computation time on the 1906A - the computer link - the size and speed of the PDP15 disc,
(1) Relevant figures
The current computing speed of SPROGS is 700 lines/second. If we suppose that a frame contains 2K lines and, optimistically, that SPROGS eventually doubles in speed, we will compute 1 frame in 1½ seconds.
The theoretical link speed is 1.2 Mbaud. However, varying loading conditions in the 1906A give rise to widely differing measured speeds. We must therefore consider ways of reducing the information sent across.
We will quite likely use the PDP15 disc to hold sequences temporarily while they are being displayed. The amount of disc available for use as temporary storage could be 1/4M words. If a frame contains 2K lines, this space represents 50-100 frames. (These disc figures can, of course, only illustrate an order of magnitude,) Timing experiments on the disc using FORTRAN give us a measured speed of 5000 words/sec.
The theoretical speed is 10 times this figure, and we believe (but have not proved) that we could approach the theoretical speed if we abandoned FORTRAN disc I/0.
(2) General principles
We put forward here a few suggestions and they have this much in common:-
(i) they will benefit the batch user of SPROGS and so ought to be part of the package used in batch mode;
(ii) they require the user to state that at certain stages in the debugging he does not want the full processing complexity that may be necessary in the final product.
(3) Specific suggestions
(i) The routine STRAW is analogous to the routine DRAW (derivation Special DRAW or SDRAW, hence by corruption' in conversation, STRAW) . It may typically be used as follows in a file which draws 5 circles to make up an Olympic symbol.
STDF ('OLYMPIC')
........
........
SETXY('X1','Y1')
STRAW('CIRCLE')
SETXY('X2','Y2')
STRAW('CIRCLE')
........
........
FIDF
By including STRAW, the user states that the visibility of each line in the file as it is drawn is determined only by the visibility of the starting point, in this case ('X1','Y1') etc. The effect is that the processing of the region chain is performed once for each call to 'CIRCLE' instead of once for each line.
Application of picture features (thickness, rotation, and so on) will be performed for each line; however, at the stage in the usual algorithm where regions are considered, a visibility test is made (simply the testing of a variable) and a single conversion performed (being the resultant effect of the conversions of all regions in the selected chain).
If our Olympic symbol moves across a region, it will disappear ring by ring instead of line by line.
To ensure sensible results, STRAW will only execute a file in this fashion, when it consists entirely of line drawing commands (type 1 or type 2 in the SPROGS manual, chapter 9). STRAW could process LOCAL index variable declarations, but SPKOGS does not recognise this as a file type. On finding an illegal file, STRAW would execute exactly like DRAW.
One problem is that there would be no check for lines falling outside the total plotting area. A simple check could be made; any line with one or more end points outside the hardware plotting area would not be plotted.
In producing the final sequence, all STRAWs must act like DRAWs. A global variable could control this.
(ii) The routine DFBACK is analogous to the routine STDF. It would cause a file to be defined in hardware form for a particular device.
A previously suggested scheme is to use STDF with a special priority level (possibly -!).
The header for the file would include a number indicating what graphical output device the file was defined in terms of. If the device was the PDP15, the file would be sent there at the end of definition and saved by the PDP15.
When called repeatedly by DRAW, the file would act as a static background for a scene. DRAW could check that the device at definition time matches the device set at execution time. If the device is PDP15, a command to execute the previously-saved file would be sent across the link. For this purpose we require another code number for the routine OUTPUT with the additional arguments name (in some numerical form) and number.
An alternative method is to make the saved file independent of output device, A consequence is that the file is sent to the PDP15 either when it is first called with current device set to PDP15, or at definition time whether or not it is destined for the PDP15.
(iii) Skeletons. In debugging movie sequences, a user may only be concerned with the motion, not the rich texture of a particular frame. Therefore, we recall here an earlier suggestion that a user should define alternative skeletal forms of certain of his picture files. For instance, a single line version of the character fonts would be a useful alternative to the Helvetica; crude versions of curves would be more efficient than a smooth version.
Various mechanisms can aid the user. He can give the different versions different file numbers. This would make alternative character fonts easy but would interfere with the numbering of eels in a class. What we suggest here is that detailed and skeletal forms be stored in different libraries. When the user wishes his film to become detailed, he simply switches libraries. Syntactic sugar could be added for the person who does not want to be aware of the library mechanism. But the person would need to be aware of when he needs to update his "Detailed copy" or "Skeletal copy" due to a change to a file definition in core.
This section departs from the broad outline format which characterizes the rest of the paper. It is included here chiefly to aid the production of low level software for the computer link going on at present.
(i) Characters: textual information. The SOOP user will be able to extract information from SPROGS and will receive error messages. ICL characters will become 5/7 ASCII in the PDPI5. (GAE is already covering this.)
(ii) 18-bit numbers: display file information. Display files will be sent to the PDPI15 in their final or almost-final form. A program in the 1906A will produce the 18-bit numbers. If they are packed up before transmission, less information needs to be sent. Treatment of the sign bit will depend on how the numbers are generated.
The information in this direction will normally be picture definitions or SPROGS commands in character form.
(i) Characters: SPROGS commands in character form. 5/7 ASCII characters in the PDP 15 will become ICL characters. (GAE is already covering this.)
(ii) Binary integers: picture definition from tablet. The writing tablet generates a list of points where each point is a pair of binary integers. We suggest that the numbers be sent across the link in this form, unpacked in the 1906A and finally floated. This will minimize the information sent and the number of character conversions performed.
Data mode could include a command to read a succeeding list of binary integers and treat them as NULL commands.
Some of the ideas for the design of these systems were inspired by G A Butlin's paper, "A FORTRAN Package for Interactive Graphics". We visited Dr Butlin on 27 November and may alter some of the design of PIGS later.