SPROGS: a slang word used to describe raw recruits to the British Armed Forces (circa 1950). An apt name for a system produced by a bunch of amateurs in the field of interactive computer animation. Alternatively it could stand for:-
S P R O G S D4020 and DP15 APID UTPUT OF RAPHICS YSTEM
In August 1970 a first attempt was made at defining this system. At that time we rather naively thought that the central part of the system could be made to reside in the PDP15. We now feel that, even with the additional core, it is unlikely that any part of the system will reside in the PDP15. Thus the PDP15 will look like any other input device except that it will have more sophisticated means of input and output of information. A basic aim of the system will be that both batch and interactive users will see the system in much the same way. This paper should therefore be read initially remembering that we are designing a batch system which can also be controlled by a set of orders or commands presented to the system as data. The major sections are those devoted to picture and film definition. It is likely that the final system proposed will differ considerably from this draft. However, I feel that a document of this kind is necessary to provide a basis for discussion.
The aim of this section is to give details of the basic routines associated with picture defining and output. Normally vector drawing routines etc will be called in the process of a picture definition. The result in this case will be that a parameter defining the type of routine together with the other parameters of the routine will be stored in the picture file. Later when the picture file is examined for output, the identical subroutine call will be reconstituted and executed. Different action in the two cases is achieved by the concept of a priority level. A global variable PICPRY always contains the current priority level. If the local priority level for a routine is less than PICPRY then the routine·is executed, otherwise the picture file storage is initiated. The basic picture defining routines are given a local priority level of 1. Thus if the routine is called with PICPRY then storage occurs while PICPRY = 0 will cause output to occur.
It is possible to define graphic routines of a still higher local priority level which themselves call these low level priority picture drawing routines. Thus which routine calls will be stored in the picture file will depend on the current priority level when the picture file definition is made.
Each routine has associated with it both a name and a number. The name is required to allow calls of the routine to be input as data. The names themselves are stored in a name table. This table has the name of the routine as key and contains the routine number and additional information concerning the routine as information.
Normally the arguments stored in the display file are the actual arguments of the routine. However, it is sometimes necessary to have a parameter stored in the display file instead of an actual argument. When the picture is output, the current value of the parameter will be inserted. Rather than allow an unlimited number of such parameters, a single array is available. The position of the variable in the array will be stored as the parameter.
It is possible that arguments of types other than real numbers will be in the argument list. For example it is possible that strings may also be arguments to picture routines. These must be stored and accessed in some hygienic way. We wish to be able to store away the complete definition of a film at any point in time. Thus in the same way that parameters are localised in an array, strings involved in picture drawing routines are stored in an array. The form of the string entry table is as follows:-
The array of parameters will be perhaps 100 elements in length. In order to make the program readable, a user can equivalence his own names to the parameters. In addition, it is possible that the parameters will be inserted in procedure calls defined on data cards. Consequently it is necessary to have a means of equivalencing names set up for the parameters with their positions in the array. Thus we have a second array as follows:-
The table holding the strings can be the same table that is defined for holding all strings.
If we use the name PICT as the generic name for all picture drawing routines then the general form of the subroutine heading will be
SUBROUTINE PICT (PRMINF, PARAM1, PARAM2, ... )
The parameters PARAM1 onwards will normally be an actual argument but they can also be replaced by the position of one of the global parameters. The initial parameter PRMINF defines the form of the succeeding variables. It has the form:-
PRMINF = 41*P1 + 42*P2 +43*P3 ...
where Pi = 0 if PARAMi is an actual value
Pi = 1 if PARAMi is the position of a global parameter
which is replacing the actual argument.
Pi = 2 if PARAMi defines the position of a global parameter
which points to the actual argument
Each picture routine must have a uniform prologue as follows:-
SUBROUTINE PICT (PRMINF,PARAM1,PARAM2,PARAM3)
COMMON/SC/
LCPRTY = 7
NMPICT = NAME ('PICT', 3, PICT, LCPRTY)
IF (PICPRY.LT.LCPRTY) GOTO 10
CALL STORE3 (NMPICT, PRMINF, PARAM1, PARAM2, PARAM3)
RETURN
10 CALL RCNCL3 (PRMINF, PARAM1, PARAM2, PARAM3)
(Picture Drawing commands etc defining PICT)
RETURN
END
The COMMON declaration is a global one belonging to all picture defining routines. It contains for example the global variable PICPRY and also the array of parameters. In this case we have defined the local priority level as 7. The routine NAME enters the name of the routine in the NAME TABLE if it is not there already. One argument indicates the number of real parameters. Also the routine entry point itself is passed into the table. The local Priority value is also stored in the table so that the user can access this information.
The routines STOREi enter the relevant information· into the current picture definition. These could be replaced by a single routine. However, variable numbers of arguments are not available on all dialects of FORTRAN. The reconciliation routines RCNCLi examine the arguments and replace the parameterised ones by their current values.
The system will itself provide a number of basic routines and these will be available automatically. A user can augment this basic set by ones of his own choosing.
The four low level routines on priority level 1 are as follows: SEPT, TODXDY, PLOT, UPDXDY.
SETPT (P,X,Y)
This sets the current position of the plotting to be at (X,Y). The current position will in future be denoted by (XPOS, YPOS). Thus this routine sets XPOS=X and YPOS=Y. The parameter is described above.
TODXDY (P,DX,DY)
This causes a line to be defined from (XPOS, YPOS) to (XPOS+DX,YPOS+DY).
UPDXDY(P,DX,DY)
causes current (XPOS, YPOS) to be incremented by DX,DY.
PLOT(P,N)
This causes a plotting symbol numbered N to be output at the current plotting position (XPOS,YPOS).
All graphical output will be defined in terms of these lowest level graphical routines.
Once the picture definition has been made, it is necessary to provide some means of causing that graphical output to be displayed. The basic routine of this type is the routine called DRAW. This will cause a defined picture to be output. Details of picture drawing routines themselves will be given later. It is sufficient at this stage to say that the form of the picture drawing routine DRAW will be the same as the routines TODXDY, PLOT and SETPT. The important difference is that DRAW has a local priority level of 2 rather than 1.
Let us examine how picture defining takes place in terms of these routines. If we assume that a picture is defined initially containing calls to the priority level 1 routines then this can be output using DRAW. Suppose now a second picture is defined containing calls of the priority level 1 routines and also calls of the routine DRAW invoking the first picture called. If the global priority level is set to 1 when the picture is defined then this new picture definition will only consist of calls to priority level 1 routines. The calls of procedure DRAW will be expanded out until its constituent parts eventually cause calls of the low level routines. However, by defining the picture at a priority level of 2, the DRAW calls will not be expanded out and the new picture definition will contain in the DRAW entries accesses to sub-pictures. The DRAW routine thus provides the means for defining a picture hierarchy where a picture can be made up of a number of sub-pictures and so on.
There is at this stage a point which may be worthy of consideration. In most routines it seems natural to have a static priority level associated with it. In the case of the DRAW routine there may be a case for having a variable priority level. This could, for example, be input as a parameter to the routine. Consider the case for example where a picture item consists of calls to picture drawing routines on a variety of priority levels. At the moment a picture definition including this DRAW call will either point to the sub-picture or alternatively break it right down into its lowest level constituents. No intermediate action is possible. This could however be obtained if DRAW was allowed a variable local priority value.
On top of these lowest level routines will be a number of useful routines that the user can load into his particular system if he so desires. This is similar to the CAMP philosophy. However, we have much more power in two ways. Firstly, we have more freedom in what gets stored in the picture files and also our set of routines is open ended. The user may define a complete library of his own specialist routines. Details of additional routines will not be given at this point. However, some examples of possible routines are:- VECTOR, BOX, TRIANGLE, CIRCLE, ARROW, CONIC, ARC, CLOCK, METER etc. These will have to be grouped into realistic priority levels.
So far we have considered the orders that define the individual lines and plots that as a whole make up a picture. This picture has to be identified in some way. The suggested method here is analogous to the GROATS naming scheme. However, it differs in that it gets around a number of shortcomings in the earlier system. In GROATS a picture was identified by a name which consisted of a set of alphanumeric characters. One disadvantage was that it was difficult to input strings from a data stream and, in an interactive situation, it was difficult to define a set of related pictures. In SPROGS the picture will be defined by both a name and a number. Thus it is possible to define a film where all pictures have the same name and different numbers. Alternatively it is possible to define a film having all names different and each having the same number (this is equivalent to GROATS). There will be an assumed number of 1 associated with a picture if none is given.
One further advantage of numbering which could become apparent later is that for different instances in time the same picture could be differentiated by a sequence of numbers. Thus HAND 1, HAND 2 etc. might define different positions of a HAND at different time intervals.
The aim in SPROGS will be to make no differentiation between characters and other pictures stored in the system. The only concession to characters having some special significance will be that the single character identifiers will be used to represent the characters themselves. Thus the picture having name A will, in general, represent the character A. We have already seen the need for defining a variety of character fonts. This will be achieved in SPROGS by using the number associated with the character to define the relevant font. Thus A1 defines the letter A in character font 1 and so on.
The most general method of defining a picture will be to execute the two routines STDPCG and FNDPCG (start definition picture general and finish definition picture general) and call plotting orders in between. The format of these routines is as follows.
SUBROUTINE STDPCG (NAME, NUMBER, PRTYLV, MODE)
SUBROUTINE FINPCG (NAME, NUMBER)
The NAME argument consists of a string defining the picture name while NUMBER is the associated number. The parameter PRTYLV defines the global priority level in use while the definition is being made. For example:
CALL STDPCG ('SQUARE',1,1)
CALL SETPTP(0,0,0)
CALL TODXDYP(0,1,0)
CALL TODXDYP(0,0,1)
CALL TODXDYP(0,-1,0)
CALL TODXDYP(0,0,-1)
CALL FNDPCG ('SQUARE',1)
One important difference between GROATS and SPROGS is that a number of picture definitions can be proceeding in parallel. As each FNDPCG clearly defines the STDPCG it is associated with, there is no problem in making the correct match between the two. Not more than some arbitrary number (say 6) definitions can be proceeding together.
Although these two routines are the basic ones, some simpler routines having an assumed priority level and numbering will also be provided. For example STDPC and FNDPC will have a single string argument which defines the name. Both the number of the picture and priority level will be assumed as taking the value 1.
We do not need to go into too much detail on how picture names are kept. It will almost certainly be a fixed length Hash table capable of holding perhaps 256 picture names. The picture name and number define a unique picture and point to the picture file. This is the only pointer into the picture file. Alterations to the layout of the picture file only require the hash table, let us call it PICTURE NAME TABLE to be altered.
Earlier we considered the basic set of picture drawing routines SETPT, TODXDY, PLOT and UPDXDY. In addition to these routines there are a set of elementary routines which are special in as far as they do not make any additions to the picture itself. All they do is to alter the current plotting position XPOS, YPOS. The four basic routines in this class are UP, DOWN, LEFT, RIGHT. They have the same basic form as the other drawing routines except they require no arguments. For example:-
SUBROUTINE UP
COMMON/SC/
LCPRTY =
NMPICT = NAME ('UP',0,UP,LCPRTY)
IF(PICPRY .LT .LCPRTY ) GOTO 10
CALL STORE0 (NMPICT)
RETURN
10 YPOS = IMAX
RETURN
END
As can be seen the only action of this routine is to set the current value of YPOS to the top of the selected region. These routines are particularly useful to aid the definition of non-printing carriage control characters such as Newline and Pagethrow. Some decision will have to be made on the priority level of these routines. It almost certainly must be priority level 1.
It is quite likely that higher level drawing routines may require to define special pictures which have some temporary meaning. These may be defined in much the same way as user defined pictures except that system names must be differentiated from user names. This will be achieved by stating that user defined names are alphanumeric while system defined temporary names must start with a special symbol such as a '.' (full stop).
Summarising what has been decided so far:-
Basically the picture file will contain a number of distinct pictures. Each picture, if it is connected to another in some way, will do this via the PICTURE NAME TABLE. Individual items in the picture definition will consist of
NMPICT, PRMINF, PARAM1, PARAM2, PARAM3
where NMPICT defines the picture drawing routine this is associated with and PRMINF gives the relevant information about the parameters following. It is possible that the item will also require the number of arguments to be stored.
So far we have not considered how this information will be stored. It is likely that the picture file will contain pictures in a variety of modes. The mode of storage for a particular picture will be defined by a MODE entry in the PICTURE NAME TABLE.
MODE NORMAL
Assuming the most general form for all the arguments, this mode will consist of NMPICT and PRMINF stored as integers on the computer followed by PARAMi as real numbers. The 19O6A implementation will have NMPICT and PRMINF stored in 24 bits each while PARAMi will be 48 bit floating point numbers.
ATTRIBUTE VALUE
A likely situation will be that all arguments are values rather than pointers to parameters. Thus in this case PRMINF=0 and there is no need to store this piece of information. It will depend on a particular implementation whether the attribute VALUE associated with a picture causes any reduction in storage requirements. On the 1906A it may be that no saving can occur.
ATTRIBUTE INTEGER
If all arguments can be defined as integer quantities then it will be possible to define a storage system where the PARAMi are stored as integers rather than real quantities.
ATTRIBUTE COMPACT
If all arguments can be expressed as short integers then it will be possible to define a storage system where several parameters are loaded into a single word.
ATTRIBUTE BASIC
If only the most basic drawing functions are allowed then the value of NMPICT could be less than some small integer value in which case the number of bits required for this word is much less than the size required for a full integer.
ATTRIBUTE FEW
If the routine has only a few parameters then again, the second word stored PRMINF could be less than some small integer.
It is likely that a number of different storage structures will be defined depending on some of the above attributes. We shall require to evaluate the possible configurations to see which are likely to be used and how storage will be saved.
Basically as the picture is being defined there will be a parameter defining the type of storage required for the picture. This MODE number will be stored in the PICTURE NAME TABLE entry associated with it. A variable MDPCDF will contain the current MODE value for the picture being defined. This will be kept with other information set up when the start of the picture definition was initiated. The MODE argument given in the routine STDPCG is as above.
The two routines STORE and DRAW will require the picture MODE values to define how the information is to be stored.
For example it is likely that a very compact method for character fonts will be required. These will only have calls of the routines TODXDY, UPDXDY and UP, DOWN; LEFT, RIGHT. The attributes VALUE, COMPACT and BASIC all apply. None of the functions require more than two arguments which can be stored as compact integers.
Thus each item can be stored as a single 24 bit integer as follows:-
It is possible that an even more compact storage mode might be used:-
This would mean that the maximum X change is -8 to +7 while the Y change is -16 to +15. This could be rather restrictive but is worth investigating.
Apart from considering how individual items are stored in the picture file, it will also be necessary to consider how a set of items are to be stored and how a set of pictures are to be stored. I feel that the amount of structure in graphic pictures is not great. The structure can be organised by the DRAW method of accessing sub-pictures. Consequently it seems reasonable to expect consecutive items to be stored in one continuous vector with no pointer connections between items. This means that a single picture will take up a single block of storage. Deletion of pictures will cause space to be made available in the middle of the picture file. This can be retrieved by garbage collecting when all space has been used. One problem that occurs with this simple storage system is that it is not easy to define two different items at the same time. It may be that with this simple storage structure, only one item will be defined at any one time.
A more complex storage structure would be to link items with pointers which define the position of the next item. This is more flexible. The only penalty would be that of the additional storage for pointers. It is likely that a large storage area will be required for picture items. It is unlikely that sufficient storage space will ever be available in core and an automatic paging system for moving pictures to and from disc storage will have to be organised. Whether a picture is currently resident in the core store or disc will depend on the PICTURE NAME TABLE. The contents of each entry in this table will be:-
The pointer to the picture file will be positive for an entry in core while a negative value will give information defining where the item appears on the backing storage. The ALTERED entry is set to zero when the picture item is loaded into core initially. Whenever a change is made to a file, this entry is changed to 1 indicating that the version on disc must be updated.
It may be that there will be a need for equivalencing picture names so that it is possible to have two entries in the PICTURE NAME TABLE pointing to the same entry in the picture file. If this were allowed the current proposed structure would not be ideal. An alteration to one picture would mean that all entries in the PICTURE NAME TABLE would have to be searched in order to find all equivalenced pictures that need to be marked as altered. If equivalencing is allowed then it would probably be best to have a table within the picture file which defines where individual pictures reside. The PICTURE NAME TABLE would then point to the PICTURE FILE TABLE. This may have other advantages which will show up later. It may be a more elegant interface than using the PICTURE NAME TABLE.
So far we have designed a set of lines which together make up a picture. No indication has been given of the units we have been using and none is necessary. The picture defined so far can be thought of as an abstract object which can have a concrete realisation once certain parameters have been associated with it. This is similar to the way pictures were defined in GROATS. Lines making up pictures were defined with respect to a particular region whose position and size could be varied thus changing the position and size of the picture item. Unfortunately these attributes I feel should be associated more with the picture than the region. Consequently a different approach will be adopted in SPROGS. It is interesting to note that CAMP has an entirely different approach. Two copies of the same picture item require two copies to reside in store.
The parameters associated with a picture will be stored as a parameter file. Access to the parameter files will be via the PARAMETER NAME TABLE. Thus there is an analogous structure and table set up for parameters as there is for pictures. It may be that the PICTURE and PARAMETER NAME TABLES will be the same table with an information entry defining the type of object the entry refers to. Alternatively the table may be separate. Similarly the PARAMETER FILE and PICTURE FILE are likely to be the same entity. The amount of storage used by the parameter file is likely to be much less than the amount required by the picture file. Thus a concrete realisation of a picture consists of specifying both a picture and a parameter.
The parameter file will contain such information necessary to allow several concrete examples of the same abstract picture to be used at the same time. What variations of the same abstract picture are likely to be necessary. In this connection it is worth thinking both in terms of characters and normal picture objects. The suggested entries in the parameter file are:-
Summarising what has been decided so far:-
It is therefore necessary to associate with each picture both a picture name and a parameter name. The two together define a concrete picture. Just as pictures and parameters are given names and numbers, so are concrete pictures. Similarly CONCRETE PICTURES have their names stored in a CONCRETE NAME TABLE. The information part of the table entry contains pointers to the relevant entry in the PICTURE NAME TABLE and PARAMETER NAME TABLE. Thus for example a concrete picture might be called LGSQ and have number 1 while it might be made up of a picture name called SQ with number 2 and a parameter name LARGE with number 4 say. The various table entries would therefore look like this:-
Although this rather impressive structure may look over-elaborate, it does have several advantages. For example a number of pictures can have the same parameters and they can then all point to the same parameter entry. This could be the case, for example, when we consider a string of characters. Similarly several concrete examples of the same picture could be defined using different parameters but the same picture entry.
It is now clear that the argument of the DRAW subroutine must be an entry in the CONCRETE NAME TABLE. If this call is made inside a picture definition then it is the concrete name stored in the picture file.
The expansion factor E may have an origin (EX,EY) associated with it. It depends on whether any absolute drawing occurs in the picture. These parameters are only associated with calls of the routines SETPT, TODXDY, UPDXDY. The routines TODXDY and UPDXDY have arguments DX and DY which are changed to E*DX and E*DY before the routine is executed in the normal way. In the case of SETPT, which has arguments X and Y, these are changed to X=EX + (X-EX)*E and Y=EY + (Y-EY)*E. If the file consists of orders involving only TODXDY and UPDXDY (no calls of SETPT) then there is no need to define an origin. The expansion is relative to the base of the subpicture.
Similarly rotation defines parameters R, RX, and RY. The arguments DX and DY are changed in this case to
DX= DY cos(R) + DY sin (R) DY= DX sin(R) - DY cos (R) similarly X and Y are changed to:- X = (X-XR) cos(R) + (Y-IR) sin(R) + XR Y = (X-XR) sin(R) - (Y-YR) cos(R) + YR
When a picture involving several subpictures each with their own subpictures is drawn then each level has its own parameter file. At any stage a particular parameter file is relevant. When a subpicture is drawn, this parameter file must be stacked and the relevant one for the subpicture taken as the current one. On completion of the subpicture, the original parameter file becomes the current one again. Therefore during the DRAW execution a stack is required which contains pointers to all the active parameters.
The definition of the parameter file could be done similar to that of the picture file. That is a set of executable·statements could be stored in the file ready to be executed when the appropriate picture is drawn. This has a number of drawbacks. Firstly it is very easy in this case to miss out some of the parameters. What happens in this case. Consider for example picture A which calls two subpictures B and C. When A is drawn then the relevant parameter settings for A are set up before the picture file is interpreted. When the subpicture B is started then the parameter settings for A are stacked and then the parameter file for B could be executed. This would change only those parameters that had been defined. The rest would be left at the settings for A or alternatively set at some standard value. Either way it is very easy to miss a parameter setting. This has caused trouble in GROATS with users not getting the output they expected.
Therefore it seems sensible to make the user set all parameters for every picture or subpicture. Thus the standard routine for defining parameters will be:-
SUBROUTINE DFPMG (PRMINF,PRNAME,PRNUMB,REGION,DARK,THICK,BROKEN,
EXPN,EXPNX,EXPNY,ROTN,ROTNX,ROTNY)
The first parameter defines whether the following parameters are actual values or alternatively the position of a global parameter which is replacing the actual argument. The argument PRNAME is the name of the parameter file while PRNUMB is its number.
Once parameters and pictures have been defined, it is possible to define a concrete picture by calling the routine
SUBROUTINE DFPCCN (PCCNNM,PCCNNU,PCNM,PCNU,PRNM,PRNU)
This defines the concrete picture having name and number PCCNNM and PCCNNU. This consists of the picture defined by PCNM and PCNU and the parameter defined by PRNM and PRNU.
The large amount of names and numbers presented so far give the most general format that a user may have. However, the average user will not require this flexibility. For example, equivalent routines will be provided where the number is assumed to be 1 and only the name is given, Similarly it will be possible to define both parameter and picture having the same name. A concrete picture will then be assumed to have both picture and parameter names and numbers the same as itself. Thus the six variables needed to define the concrete picture can be reduced to one if desired.
So far we have described how pictures are defined. The quantities stored in the picture file are basically pseudo calls of procedures which, if called, are capable of generating graphical output. Whether output is generated or not will depend on the value of PICPRY. To produce a picture defined in terms of the basic vector drawing commands, the picture is defined when the priority level PICPRY = 1. Thus for example STDPCG will set PICPRY to the value of the argument PRTYLV on entering the definition sequence. This is assuming that only a single priority can be operative at any one time. If multiple definitions are allowed then this becomes more complex. For the amount this is likely to be used it is probably not worth allowing in order to keep the format of the drawing routines simple.
A picture is output when the value of PICPRY = 0. In this case the current global values of the picture parameters modify the output produced. Thus we can define PM as the set of variables:-
REG current region DARK THICK BROKEN EXPN EXPNX EXPNY ROTN ROTNX ROTNY
which are associated with any output routine. Picture output will normally be produced therefore by setting PICPRY = 0 and calling the relevant picture drawing routine, This Will first set PM to the values defined for this particular picture and then execute the picture.
We have in the past allowed direct output, that is procedures such as TODXDY could be called to produce output immediately. Although this tends to be a rather inflexible method and one that should be used sparingly, there may be places where it is advantageous. The format of routines described so far is quite capable of producing the output in this way. It is only necessary to have some way of defining the parameters globally. Thus we require at a minimum a procedure of the form:-
SUBROUTINE PARAM(REGION,DARK,THICK,BROKEN,EXPN,EXPNX,EXPYN,ROTN,ROTNX,ROTNY)
Normally other routines will be produced for changing individual items in the parameter list PM.
The values of PM can be stacked so that basically we have a global current setting of PM which is stacked on entering a DRAW command and reset when the DRAW is concluded.
At this stage we will not go into details of how the picture itself is to be output. There will have to be a switch of some kind allowing output to go to either the PDP15 or SC4020 with possibly other alternatives. In the case of a subroutine it is likely that the output file will be remembered so that if the picture is not changed since the last output then rather than recalculating the output file it is recovered from the previous compilation. This is probably a more sensible arrangement than the GROATS situation where the user has to specifically remember that the output has already been calculated. The interface between picture drawing and the output devices can be localised in a very few routines that this part can be self contained. In a simple-minded approach where no attempt to stop recalculation is made, the only routines involved are SETPT, TODXDY, UPDXDY, PLOT and UP, DOWN, LEFT,RIGHT.
In addition to these routines the global variables involved are the current parameter settings and region definitions. If optimisation is considered then an attempt to draw a subpicture must cause some kind of saving to take place. This will be considered in more detail when we consider the film defining procedures of which DRAW is the most simple minded.
There will be a need to define some editing facilities for pictures stored in the picture file. This will also apply to the parameters as well. The simplest form of editing required will be the complete replacement of one picture by another. This has· already been covered. Redefinition will automatically cause the previous definition to be cancelled. Space will be reclaimed as one of the functions of the garbage collector associated with the picture file.
It is unlikely that general replacement of one output command by another will be allowed. This can be achieved to some extent if not completely by parameterising the stored procedure calls and then changing the value of the global parameter. Operations which will be catered for are as follows:-
The definition of regions in SPROGS is rather different from that provided in GROATS as the inter-relation between regions is more important. In GROATS basically all regions were defined in terms of the SC4O2O plotting area even though they appeared to be defined in terms of other regions.
Basically the problem is to output to the plotting device a line between X1Y1 and X2Y2 with respect to the parameters associated with region R. Normally line darkness, thickness, and expansion, will already have been dealt with by converting (X,Y)'s to their equivalent values or expanding a single line drawing command into several.
Each REGION is defined by the following set of parameters:-
R Region number
XMIN Left hand limit of X values
YMIN Bottom 1imit of Y values
XMAX Right hand limit or X values
YMAX Top limit of Y values
C Type of conversion to be applied
B Basic shape of region
P Region in terms of which R is defined
XPMIN Equivalent value of XMIN in units of region P
YPMIN Equivalent value of YMIN in units of region P
XPMAX Equivalent value of XMAX in units of region P
YPMAX Equivalent value of YMAX in units of region P
MI,MO The type of region R is defined by these two variables
S A value associated with the region. If S is the same
as the output switch value U, then region conversion is
completed and we have X and Y values associated with the
output device.
Given an (X,Y) value in region R it will be necessary to decide whether (X,Y) is visible or not. Given two points (X1,Y1) and (X2,Y2) it will be necessary to define the part of the line which is visible or invisible. Using the symbols I and V to define invisible or visible and IV to represent one or other then the conversion produced by a region definition will be:-
POINT (R,X,Y,IV) → POINT(P,X',Y',IV')
LINE (R,X1,Y1,X2,Y2) → LINE (P,X'1,Y'1,X'2,Y'2,IV')
LINE (P,X"1.Y"1,X"2,Y"2,IV")
.....................
The value of S will determine whether a further conversion is required at each stage.
The type of region R depends on the value assigned to MI and MO. Basically we can differentiate between points or parts of lines inside and outside the region. The information outside the region is controlled by MO and that inside by MI. The four possibilities in each case can be represented as follows using M to represent either MI or MO.
M = 0 IV' = I M = 1 IV' = IV M = 2 IV' = ¬V M = 3 IV' = V
Thus for each region there are basically 16 different modes of operation. The GROATS system had basically only 4 of these alternatives:-
CW contained window MO = 0 MI = 1 EW extended window MO = 1 MI = 1 CS contained shield MO = 0 MI = 0 ES extended shield MO = 1 MI = 0
It is unlikely that values of MO or MI=3 will be used very much. However, MO or MI=2 will be used and gives us the inversion capabilities of Polygraphics. A line which is defined as hidden by one region can be forced into view by a region in terms of which it is defined.
The complete algorithm can then be written as follows:-
Given LINE(R,X1,Y1,X2,Y2)
(1) The routine SEEVEC (X1,Y1,X2,Y2,XMIN,YMIN,XMAX,YMAX) splits the line up into several parts
LINE (R,X11,Y11,X21,Y21,IV) IO1
LINE (R,X12,Y12,X22,Y22,IV) IO2
...............................
The parameter IO associated with each part of the line defines whether the line segment is inside or outside. With rectangular regions the only possible cases that can arise are O, I, OI, IO, OIO. Thus a maximum of 3 lines is generated from any one line
(2) For each sub line LINE (R,X1i,Y1i,X2i,Y2i,IV) the value of IOi and either MI or MO will define the value of IVi'. The sub-lines are now:
LINE (R,X1i',Y1i',X2i',Y2i',IVi')
Conversion now takes place depending on the value C such that (X,Y) gets converted into (X',Y') depending on the values of XMIN,YMIN,XMAX,YMAX and XPMIN,YPMIN,XPMAX,YPMAX. Details of the types of C possible will be given later. Conversion therefore gives us several sub-lines of form
LINE(P,X1i',Y1i',X2i'Y2i'.IVi')
(3) If S is equal to the output switch value then P,X1i',Y1i',X2i',Y2i',IVi' are passed to the output routine. Otherwise the process is repeated for the LINE (P,X1i',Y1i',X2i',Y2i',IVi')
Thus the process is recursive and does not end until a region is reached having the terminating value of S. There is no limit to the level of recursion except that at each stage there is a possibility of a line being split into 3 parts so that the stack must be as large as 3L where L is the level of recursion allowed.
The algorithm for POINT (R,X,Y,IV) is similar except that in place of SEEVEC a procedure INVIEW is called which determines the value of IO for the point (X,Y). IV' is then determined from either MI or MO depending on the value of IO. Conversion takes place as before.
The basic method of conversion, C0O, will be linear conversion from region R to P. That is
X' = XPMIN + (X-XMIN) (XPMAX-XPMIN) / (XMAX-XMIN) Y' = YPMIN + (Y-IMIN) (YPMAX-YPMIN) / (YMAX-IMIN)
Initially this will be the only type of conversion allowed, However, there is no reason why this should not be extended in the future. In particular special case conversions such as inverting YMIN and YMAX may well be provided in order to speed up the conversion from SC4020 to PDP15 raster positions. Similarly log scales could also be introduced by this device.
One problem associated with non-linear conversions is defining line thickness which is done at the user co-ordinate level and also broken lines. In the past we have used a routine RASTERLENGTH to pass back to the user the units in the X and Y direction associated with a one raster unit change. The X and Y are given in the units of the region. With non-linear regions, such a routine is not able to define a result in general but only at a particular point. Similarly dividing a broken line into equal sections would when converted using a non-linear conversion produce unequal length lines.
My feeling is that this point is not too important although we should consider whether thickness is defined by the low level output routine. It could be said that thickness and darkness together with broken lines are display parameters and therefore should be done at a low level. Thus these actions may take place once the final region conversion has taken place. Against this argument is the fact that the result is shown as a film so that the relationship between frames is important. For example breaking a line into its broken segments at a low level will almost certainly look incorrect when the line is being varied in some way at a high level. The answer is possibly to allow this option to be done at either level under the users control.
Again this whole system could be considered over elaborate. However, sufficient of the options have been required in the past to make the current system more elegant than allowing a subset. The syntactic sugar could reduce the options actually provided to the casual user considerably.
It is possible that we will eventually require non-rectangular regions. In this case all that is required is a non-standard SEEVEC and INVIEW routine. The parameter B=O could therefore be defined as the rectangular case while other non-standard values of B could define unusual region shapes. Notice that conversion and line visibility are two different procedures and can be treated separately. It would be possible for example to define a region which had no unit system other than passing on the existing one but did have a complex shape. Similarly a change of units can be defined with no change being made to the visibility of the picture.
It is essential that the final output produced by the region conversion will be within the bounds of the device available. For this reason some check my need to be made on the coordinates of the terminal region. Alternatively crude scissoring could occur at the output level, It is essential that the minimum number of calls to SEEVEC can be programmed where possible for efficiency reasons.
Basically all that is required for region definition is:-
SUBROUTINE DEFREG(PRMINF, XMIN, YMIN, XMAX, YMAX, R, C, B,
XPMIN,YPMIN,XPMAX,YPMAX, MI, MO, S)
It is probably desirable to have additional routines defining individual parameters. However, this is just syntactic sugar, I feel that it is important to dissociate region definition from region selection. Many faults in GROATS can be attributed to users not realising that their region definitions are in terms of those currently selected. They tend to think in terms of a particular region and frequently make errors especially when loops are involved, not realising that the selected region on the second time through is identical with the one selected at the end of the previous iteration, I feel the user must be forced to name the region in terms of which the current region is defined explicitly.
The output-parameter switch may not be the only required for defining output. Currently S defines that the region conversion is complete and that the output can now be passed to the output routine. We may require an additional parameter which defines what should be done with the output. For example this parameter could differentiate between normal output and that going to the light button area of the display. The parameter could push the output through some sink if it is unrequired for this particular output device.
The area set aside for region definitions should be capable of handling 10 or more regions. Polygraphics allows regions to have any numbering. I cannot see any reason why forcing the user to define regions as 1 to 10 is restrictive.
One difference from GROATS is that redefining a region in terms of itself is no longer possible as it will get us into a definition loop. This case must be recognised therefore and translated into a definition in terms of the original region that this region was defined in terms of.
When we have defined a picture, the resulting file is basically a set of graphical orders which can be executed at some later date. The routine DRAW can either be thought of as executing the file or alternatively interpreting it. We have indicated that it is possible to output graphical orders directly rather than first storing them in a file. The situation in the case of deciding which files to be output on which frames of the film is similar to the case of picture definitions. We have two possibilities. The first is that we can define an output order which takes place immediately on the next frame of film. Alternatively we can define a file of pictures to be output on certain frames and store this information away in a sequence definition file. Given some means of defining the origin of a film sequence then the sequence file will indicate pictures to be output starting from this point onwards. The similarity between the definition of a picture file and a sequence file can be further extended by stating that associated with each picture file is the understanding that there is a current plotting position (XPOS,YPOS). Similarly with each sequence file there is the idea of the current value of the FRAME count. It is possible to define that a sequence is output starting at a particular frame or alternatively that the sequence is output as a subsequence of another sequence.
A film is eventually defined as consisting of a number of sequences and specifying certain conditions about which part of the sequences should be output. In the same way that the picture file has a set of basic orders such as TODXDY, etc. so the sequence file has a set of basic orders. These are as follows:-
DRAW(PRMINF,NAME,NUMBER)
The argument PRMINF serves the same purpose as before. It defines whether or not the succeeding parameters have an absolute value or alternatively represent the position of some parameter to be set to the value of the argument when the sequence is executed.
ADVFLM
This defines that the current frame is concluded as far as this sequence is concerned. Information following is associated with the next frame in the sequence.
LABEL (PRMINF,NUMBER)
This routine defines a number to be associated with some statement in the sequence.
GOTO (PRMINF,NUMBER)
This routine causes control within the sequence to revert back to the statement immediately following the LABEL defined.
LOAD (PRMINF,VAR,VAL)
The second argument defines the position in the array of parameters. This parameter will be set to the value VAL. If PRMINF has the 42 value set to 1, then VAL is the position of the global parameter which contains the required value.
OP (PRMINF,TYPE,VAR,VAL)
The second argument defines the type of operator involved. Basically the global parameter VAR is replaced by VAR OP VAL with the usual conditions or the various arguments.
IFF(PRMINF,VAR,TYPE,VAL,NUMBER)
If the relation VAR TYPE VAL is true the goto the label NUMBER. These routines are sufficient to define most of the facilities required for the sequence file.
The relations TYPE allowed will be .EQ., .LT., etc as defined in Fortran.
The crude language defined so far is capable of defining quite complex sequencing. These primitives are the ones that will appear in the sequence file. Thus the sequence file consists of a set of these basic instructions. At any time during the evaluation of the sequence there will be a current instruction which is being obeyed, The variable FRAME already considered is the name of the first global parameter. It is initialised to 1 by the system but can be reset by any of the sequences. The routine ADVFLM automatically increments its value.
A sequence-definition looks much the same as a picture definition in as far as it is entered by calling:
SUBROUTINE STDSQG (NAME,NUMBER )
and is concluded by calling:-
SUBROUTINE FNDSQG (NAME,NUMBER)
Thus for example:-
CALL STDSQG ('BLINK',1)
CALL LOAD(0,FRAME,1)
CALL LABEL(0,7)
CALL DRAW(0,'BACKGD',1)
CALL ADVFLM
CALL DRAW(0,'BACKGD',1)
CALL DRAW(0,'FOREGD',1)
CALL ADVFLM
CALL IFF(0,FRAME,LT,50,7)
CALL FNDSQG ('BLINK,1)
This will define a sequence consisting of a standard background 'BACKGD' with a 'FOREGD' scene blinking every other frame.
Normally the user will not program in terms of these low level routines but will instead use more sophisticated routines provided as part of the basic system. Thus for example:-
SUBROUTINE DRAWFR (NAME,NUMBER,FRCNT)
CALL LOAD(0,LCFR,0)
I = 10
CALL LABEL(0,I)
CALL DRAW(0,NAME,NUMBER)
CALL ADVFLM
CALL OP(0,ADD,LCFR,1)
CALL IFF(0,LCFR,NE,FRONT,I)
RETURN
END
might be the routine for defining a number of frames of a particular picture to be output. As it stands it would probably not be general enough due to the absolute label value being defined. This could be solved perhaps by having one global parameter set to next free label. The statement:-
I= 10 could then be replaced by:
I = NXFRLB
NXFRLB = NXFRLB + 1
A number of routines of this form will be provided. It may be that additional primitive functions operating on files will be required. For example the GROATS routines DRAWFROMTO and CHANGE DISPLAY require manipulations on display files immediately before the actual execution of the drawing routines. However, this can usually be achieved as part of the picture file definition.
Consider for example the routine:-
SUBROUTINE DRAWFT(NAME1,NUMBER1,NAME2,NUMBER2,FRMS)
CALL STDPCG('.DRFT',1,100,1)
CALL DRPCFT(PRMINF,NAME1,NUMBER1,NAME2,NUMBER,FRMS,LCFR)
CALL FNDPCG('.DRFP',1)
CALL LOAD (0,LCFR,1)
I = NXFRLB
NXFRLB = NXFRLB + 1
CALL LABEL(0,I)
CALL DRAWW(0,'.DRFT',1)
CALL ADVFLM
CALL OP(0,ADD,LCFR,1)
CALL IFF(0,LCFR,LT,FRMS,I)
RETURN
END
Obviously we would need to have some method of defining uniqueness for the local names used. This could probably be done by examining the current name table. Thus although this routine is not complete it can be seen that it is possible to produce a routine where the intermediate drawing positions are obtained from the DRPCFT routine. This is a high level drawing routine which interpolates from the two picture files given. The priority level of 100 is used in the definition to ensure that the procedure call itself is stored as part of .DRFT. The general strategy is all these high level drawing routines will be to break it down into a drawing routine producing information in a single frame only and compile the advance films separately in the sequence file.
So far we have shown that we can produce a sequence file which only differs from the GROATS output orders in that the file is not executed immediately and, in addition, some explicit loops can be programmed, These would have to be defined as for loops in GROATS. The notation is certainly no simpler than that of GROATS. The sequence file is very similar in form to the picture file and could be stored in the same place. The editing facilities available to picture files should also be available to sequence files. Copying and appending are certainly required. In addition it is quite likely that insertion, deletion and replacement may be required. Unlike the picture file, sequence files will have handles (the labels) to enable us to get at individual statements. Also as no subroutine facility is provided, it is more likely that changes to individual statements will be required. Details of these will be given once a fuller treatment of sequence files is made.
The major difference between GROATS and SPROGS is that the user is not limited to a single sequence file. A large number of problems arise in GROATS due to the difficulty in defining the result of two independent or dependent movements. Basically GROATS has a single sequence concept and any film more complex than this will have difficulties.
In SPROGS the user, once he has defined his picture and sequence files, will state which sequences he wishes to show and, in addition, he may be able to indicate some restrictions on the sequence. The latter may not be necessary. It is quite likely that a film will consist of a number of consecutive scenes where each scene will be made up of a number of sequences taking place in parallel.
The definition of a scene will be similar to that for sequence and picture,
SUBROUTINE STDSNG (NAME,NUMBER)
SUBROUTINE FNDSNG (NAME,NUMBER)
The only statements allowed in the definition will be
SUBROUTINE SEQN (NAME,NUMBER)
Thus for example
CALL STDSNG('FIRST',1)
CALL SEQN ('BLINK',1)
CALL SEQN('ANOTHER',1)
CALL FNDSNG('FIRST',1)
defines a scene consisting of the two sequences BLINK and ANOTHER.
A command to output the scene 'FIRST' will proceed as follows:-
The introduction of several sequences being executed concurrently greatly increases the flexibility of the system. Sequences which change independently are now easy to program. In addition the global variables can be accessed from each of the sequences. Consequently one sequence can control the execution of another sequence by setting parameters. This is particularly useful when imposing constraints on the film output.
Let us consider for example the following scene:-
'A square, stationary on the left of the screen initially, moves to the right at constant speed coming to rest at the right of the screen. At the same time a circle moving across the screen from the right stops and stays still in the centre of the screen until the scene ends.'
This could be defined as two sequences:-
CALL STDSQG('SQUSQ' ,1)
CALL LOAD(0,FRAME, 1)
CALL DRAWFR('SQUARE',1,50)
CALL DRAWFT('SQUARE',1,'SQUARE',2,100)
CALL DRAWFR('SQUARE',2,50)
CALL FNDSQG('SQUSQ',1)
CALL STDSQG('CIRSQ',1)
CALL DRAWFT('CIRCLE',1,'CIRCLE',2,80)
CALL DRAWFR( 'CIRCLE',2,120)
CALL FNDSQG('CIRSQ',1)
CALL STDSNG('CRSQ',1)
CALL SEQN('SQUSQ' ,1)
CALL SEQN('CIRSQ',1)
CALL FNDSNG('CRSQ',1)
'CRSQ' is then the desired scene. It would be impossible to define such a scene at all elegantly in GROATS.
Interactions between sequences can be achieved using the global parameters. For example:-
_
CALL STDSQG('A',1) |
CALL LOAD(0,PRM1,0) |
---------- |
---------- |
---------- | ---- A
CALL LOAD(0,PRM1,1) |
---------- |
---------- |
---------- |
CALL FNDSQG('A',1) |
_
_
CALL STDSQG('B',1) |
CALL LABEL(0,5) |
CALL IFF(0.PRM1,EQ,1,10) |
CALL ADVFLM |
CALL GOTO(5) |---- B
CALL LABEL(0,10) |
---------- |
---------- |
---------- |
CALL FNDSQG('B',1) |
_
Here sequence B does not start until sequence A has completed its first part, and PRM1 has been set to 1.
So far no mention has been made of camera movements. It has been assumed that all regions are stationary while the scene is being displayed, However, there is no reason why the camera should not itself be making complex movements involving pan and zoom as the sequence is taking place. Thus it must be possible to define changes of region position in the sequence associated with camera movements. This should be the first sequence defined in the scene and it should initialise its limits and region positions initially. The most general routine would be
SUBROUTINE REGDEF (R,XMIN,YMIN,XMAX,YMAX,C,B,S,MI,MO,
XPMIN,YPMIN,XPMAX,YPMAX, P)
Thus for example we might have:
CALL STDSQG ('CAMERA',1)
CALL DEFREG(0,1,0,0,1,1,1,1,1,1,0,0,1023,1023,0,0)
CALL LABEL(0,5)
CALL IFF(0,FRAME,GE,100,10)
CALL ADVFLM
CALL GOTO(0,5)
CALL LABEL(0, 10)
CALL DEFREG(Z,1,0,0,1+(FRAME-100)/100,1,1,1,1,1,0,0,1023,1023,0,0)
CALL ADVFLM
CALL GOTO (0,10)
CALL FNDSQG('CAMERA',1)
Then if this was added to the 'CRSQ' scene defined earlier we would have the camera stationary initially and then gradually moving back over the second half of the scene. Again we have written the routine out in full although in practice special purpose routines would be provided for compiling the code equivalent to the initial WAIT and the ZOOM. No doubt also routines would be provided which change a subset of the total set of region parameters. Note that the expression involving FRAME in the call of DEFRE would not be allowed in this form as the variable argument specified by Z must be a simple call-by-name parameter. In an interactive system it will be necessary to modify parts of a sequence and then rerun it. There is therefore a need to define the complete state of the film at the start of each sequence. By insisting on region definitions in the sequence, it should only be necessary to store the current values of the global parameters at the start of each sequence for us to be able to restart a display at any sequence start.
The ideal situation of defining picture drawing in a separate sequence from camera movement may not always be possible, The WIPE for example requires part of the scene to be output with one set of region commands while another set is required-for the rest of the scene. The WIPE is therefore achieved by replacing the final region by a new one defined in terms of region X say. The commands for one frame then look like:-
DEFINE POSITION REGION X
DRAW PICTURE 1
DEFINE POSITION REGION X
DRAW PICTURE 2
ADVANCE FILM
Repeating this sequence produces the desired result. Once completed the original definition for the region is replaced.
Finally it should be possible to remove a sequence from the set defined in a frame. This could be for example a routine STOP which halts the current sequence for ever or alternatively, if a name is given, it could stop another sequence. Eventually when all sequences have stopped the end of the scene has been obtained.
The main control routine will work in basically two distinct modes. The first will assume that commands are defined as part of the program while in the other mode, commands will be defined as input to the program. It is important that each routine has an equivalent way of calling it via a data card.
The routine
CALL DATA(I)
will cause further commands to be input as data from stream I. The program will continue executing at the next instruction when a data card containing
DATA -1
is encountered. Thus data streams 0 upwards are actual data streams while stream -1 is equivalent to the program stream. A batch user may either define his program as a set of data cards or alternatively as a program. The interactive user will tend to input commands as data. The data originates at the display and gets transferred to the 1906A program for execution.
The data stream is likely to be free format with initial command names defining the statement and followed by arguments separated with commas, spaces, etc. Virtually every routine discussed so far must have this equivalent data format. Thus
CALL TODXDY(0,7,15)
is equivalent to
TODXDY 0 7 15
on the data stream. Exact details of command formats on the data stream are not yet available. Some restrictions on the argument values will however be made. Basically arguments must be either constants or strings. A constant argument can either indicate an actual parameter value or, depending on the initial variable, a global parameter position. A string argument should be preceded by an equivalence statement which equivalences the name to a position in the global parameter list. The aim here is to aid readability. For example EQUIV SSTR 1 would equivalence the string name SSTR with the global parameter 1. This could also be done in the program by calling:
CALL EQUIV('SSTR',1)
The decoding of the input string will be a special purpose recogniser. This is a special area which has not as yet been fully investigated. It is closely linked with the pre-processor to be discussed later. A guideline will be that program entered to the pre-processor should be identical in form to the data input: Thus the preprocessor and input decoder are basically the same program. One converts data into actual calls of procedures while the other causes the card image equivalent to the CALL to be generated.
If the system is not self extending there are no major problems. The control routine will be similar to CAMP:-
The routine NAME given earlier will add a name to the relevant table and, in the case of drawing routines, will indicate its priority level and number of arguments.
In a self extending system the user must at least force the relevant name in the table and in addition will probably have to add a pseudo call to the COMPUTED GOTO list. However, if the routine is defined at the machine code level then it may well be possible to do away with the pseudo CALL.
This could be prefabricated from the information in the NAME call. There appears to be no reason why a program initially entered as data on cards should not at a later date be defined as a program and compiled via the preprocessor. It is likely that the rather unfortunate limitations imposed on names and the impossible syntax of Fortran will hot be carried over in the pre-processing language.
There will be no difference between characters and pictures in the system. The picture file will contain characters initially. The name of the character will be its actual name while its number will define its font. Thus A 1 represents the character A in font 1.
As in GROATS it will probably be necessary to define some means of accessing characters which cannot be defined on the input device. This is probably a minor problem. There is no reason, for example, why a set of characters should not be defined as C1, C2, C3, etc. so that the accessing can be from number rather than name. There will be a need for a flexible method of loading characters into store. This is however no different from the general problem of loading pictures as required. It is likely that internal names will be required for system defined pictures and it has been suggested that names starting with . (full stop) should represent system names. Similarly, it may be that a string of characters preceded by %, say, should represent the individual characters; Thus %ABC would be picture A followed by pictures B and C.
The data input mode will be the normal one in use when input is being accepted from the PDP15. We have already shown the type of command that can be input from the display. Thus already it is easily seen how picture definition could occur and also how commands to view particular sequences could be issued from the PDP15. We shall not go into details at the moment of how the interaction will occur on the PDP15 but will consider what will be transmitted to the 1906A. Thus for example a light pen hit might be the means of issuing a command to display the next sequence. Alternatively it could be caused by a line of typing.
One of the major assets of the D-MAC, light pen and tablet are that they give us the ability to define specific values to variables or alternatively an array of variables. Thus we can define a set of X and Y values representing a picture object. A vector of values might indicate the size of a particular variable on a sequence of frames, How do we fit this into our current structure?
The only problem with picture definition is to ensure that the size of the object is correct. The input stream is basically in terms of raster positions and this must be related to a particular region. Once this has been given, the drawing can be translated back into the units of the required region. If the region is uniform in both directions, this could be achieved by just redefining the value of the expansion factor. It may be desirable to have two expansion factors Ex and Ey rather than a single E to facilitate input of information in this way.
It should be possible to interrogate and change the values of any of the global parameters. Printing or displaying of values could be initiated by a PRINT command while some kind of RESET command could be used to update a global parameter.
In order to use an array of information it should be possible to associate an array with a global parameter and have a second parameter indicating which element of the vector to choose. Thus consider a routine such as DEFREG. We have already indicated that individual arguments either represent a value or a global parameter or a pointer to a string. A fourth possibility could be the position of a global parameter pair as described above. Alternatively it could be an indirection indication so that, instead of the argument indicating a global parameter containing the value required, it would contain a pointer to an element containing the desired value. A set of values would then be loaded into an array and accessed by assigning initially a pointer to the first element of the array and storing this in a global parameter. Updating the value of the parameter then moves us on to the next array element. A zoom depending on a set of data values is then achieved by associating DEFREG's parameter with the global parameter pointing to this vector. Facilities could be provided for scaling vectors defined in this way by fixed amounts.
Again we may wish to change such parameters as the origin of an object as it varies in time. The origin could be linked to a global parameter in this way and it would then only be necessary to insert an array of values to be associated with this global parameter.
Thus the major extension to the system already described is the idea of an array of entries to be associated with some parameter. I do not feel that this method has entirely been worked out and a more elegant approach involving the naming of the array could be possible. Arrays will probably be stored in the same area as the picture file and updated in a similar manner.
Is there any intrinsic difference between arrays and pictures. Basically a picture defines a set of X and Y's associated with some object. It could be the drawing instructions for producing the object. Alternatively it could be a set of SETPT orders defining the position of the centre of the object at different intervals of time. The usual case when defining a parameter with respect to time is that for each time interval only a single value is required. This could be achieved by introducing a further SETX order which unlike SETPT changes only the position of XPOS when considered as a picture drawing order. Alternatively a picture defined by a set of SETX orders could be linked in time to some parameter value.
Let us consider the GENESYS idea of a discrete time function when a picture change is to be made (that is a sequence of frame numbers at which a different picture is to be displayed). This can be input into a picture file as a one function item and then used in the sequence definition to change the picture being output. In this case it may be helpful to have the picture name staying the same and having the time function indicating the number associated with the picture.
In conclusion therefore it appears that all interaction can be in terms of picture defining and commands. It is likely that a number of high level functions are provided in the PDP15 which will be translated into the low level forms already described. However, the basis described looks as though it could support such a system.
There may well be a case for having a special purpose graphical language for SPROGS. It is evident from what has gone before that we really need a BASIC type language where it is possible to obey a command or store it away to be executed later. In addition we require data or program to be input to the system and executed. These have to reside on top of a general purpose scientific language. The reason for writing the package in Fortran is mainly a matter of portability. To some extent we are generating a compiler in FORTRAN for this SPROGS language. I hope that the approach adopted will allow us to get started fairly quickly and, in addition, I hope we shall eventually have a worthwhile language even though it will have inefficiencies due to the interpretation. Most of the time spent in graphics programs of this type will be in the vector drawing routine and, to a large extent, this will be programmed efficiently. There is therefore no real reason why this form should vastly decrease the running speed of the whole system.
The pre-processor may be quite simple initially. As far as decoding the input is concerned, it could be just recognising a reserved word and evaluating arguments separated by commas. At the pre-processor level it could, in addition, allow genuine Fortran statements to pass through unchanged. Eventually it will have to be more sophisticated so that the statement of the form PARAM=1 could be treated either as a FORTRAN statement or alternatively to be stored in a picture file.
At any point in the program it should be possible to dump the current state of the system to backing storage. Basically the picture file and associated name tables together with the global parameters should define all sequences currently defined. It is important that the system should be dumped in this way. This then gives us the possibility to restart the program at a later date. Alternatively we can explore different representations etc and gradually change the information available. If the path under consideration does not seem to be going anywhere, the dumped program will be reloaded and the system started again.
It may be that information associated with a particular sequence should be kept. In this case the picture file should be searched and only the relevant information stored away. It is important that individual sequences can be processed in this way independent of those surrounding it.
It should be possible to either print or display each picture and sequence file. These will obviously give information and also provide a record of the film produced. Data should be collected on the frames output (it should be possible to get a listing of the pictures output on each frame together with any relevant parameter information). As the system is basically interpretive at the sequence production level, it should be possible to include good diagnostic capabilities in all drawing routines and sequence functions.
It is necessary for ease of dumping and restarting to have all names defined and used in the system stored in one central place. The accessing of strings will be as follows
In the example three strings DE, ABC, and F are defined in the STRING TABLE and they are accessed as strings 1, 2, and 3 respectively. All strings used in the program and input as data will be stored in this table and accessing is via the String Number Table. Strings can be deleted or replaced. In this case the entry in the String Table may change its position but the relevant String Number Table position remains the same. The types of strings accessed in this way will consist of text. Normally only, one occurrence of each text will be present in the program. The other strings likely to appear in the program are names of files etc and names equivalenced to global variables. These will also appear in the String Table but will not be accessed via the String Number Table.
The Name Table will contain entries to all names defined in the sequence. It is basically an accessing mechanism. The entries may represent the following objects:-
In the first five categories the Key consists of the NAME and NUMBER associated with the object.
The NAME is a pointer to the String Table where the actual name is stored.
In the last category the routine NAME is the Key with an assumed number of 1.
Thus name table consists of entries as follows:
The information part of the table consists of a set of parameters preceded by a count giving the length of the information string and a parameter defining the packing adopted. Alternatively the packing could be defined by the TYPE.
The individual information entries are as follows:-
These information entries are all stored in the picture file. Thus the picture file consists of a set of entries. Each entry is a vector of storage with the length. in the first half word.
This is a hash table containing equivalences between string names and global parameters.
Each entry has the form:-
The NAME entry is a pointer to the String Table.
The String Table contains Strings generated in a number of different ways. It is quite possible that it may have more than one copy of the same string if it is used in more than one different way.
The general format of the· basic routines is as follows:-
SUBROUTINE PICT (PRMINF,PARAM1 ,PARAM2,...PARAMi)
COMMON /SC/...
LCPRTY = 7
NMPICT = NAME('PICT',i,PICT,LCPRTY)
IF(PICPRY.LT.LCPRTY) GOTO 10
CALL STOREi (NMPICT,PRMINF,PARAM1,PARAM2,...PARAMi)
RETURN
10 CALL RCNCLi (PRMINF,PARAM1,PARAM2,...PARAMi)
(Picture drawing commands)
RETURN
END
STOREi stores the routine call in the picture file
RCNCLi modifies parameter values depending on PRMINF
PRMINF = P1*41 + P2*42 + P3*42 ... where
Pi= 0 if PARAMi is an actual value
Pi= 1 if PARAMi is the position of a global parameter which is replacing the actual argument.
Pi= 2 if PARAMi defines the position of a global parameter which points to the actual argument.
The possibility of replacing the actual value by references to global parameters is only possible in procedure calls if the actual argument is real or integer. There is much more freedom in the case of data input as it depends on the sophistication of the INPUT DECODER.
The set of routines is as follows:
PRIORITY LEVEL 1
SETPT(PRMINF,X,Y)
TODXDY (PRMINF,DX,DY)
UPDXDY (PRMINF,DX,DY)
PLOT (PRMINF,N)
DRCTN(PRMINF,DIR) moves plotting position to an edge
Alternative forms of these routines exist with the first
parameter zero.
SET(X,Y)
TODXY(DX,DY)
UPDXY (DX,DY)
PLT (N)
DRTN(DIR)
Higher level routines are:-
UP
DOWN
LEFT
RIGHT
VECTRP(PRMINF,X1,Y1,X2,Y2)
BOXP(PRMINF,X1,Y1,X2,Y2)
TRNGLP(PRMINF,X1,Y1,X2,Y2,X3,Y3)
CRCLP(PRMINF,X1,Y1,RADIUS)
ARROWP (PRMINF,X1,Y1,X2,Y2,SIZE,TYPE)
CONICP(PRMINF,X1,Y1,A,B)
ARCP(PRMINF,X1,Y1,A,B,THETA1,THETA2)
DRAWP(PRMINF,NAME,NUMBER)
DRAW1P (PRMINF,NAME)
Most of these routines will have an alternative form with first argument zero and the P dropped from the name.
Each routine has an equivalent name which could be used in the case of data input or pre-processing. The two types of routines with and without the first argument will probably be combined into a single routine call with the argument forms defining which of the two routines the data will be associated with.
PARAMETER DEFINING ROUTINES
DFPMG (PRNAME,PRNUMB,REGION,DARK,THICK,BROKEN,EXPX,EXPY,EXPOX,EXPOY,
ROTX,ROTY,ROTOX,ROTOY)
DFPMGP (PRMINF,PRNAME, ...
DFPMG1 (PRNAME, REGION, ...
DARK (PRNAME, PRNUMB,DRK)
THICK (PRNAME,PRNUMB,THCK)
BROKEN (PRNAME,PRNUMB,BRKN)
EXPN (PRNAME,PRNUMB,EXPX,EXPY)
EXPNO (PRNAME,PRNUMB,EXPOX,EXPOY,EXPX,EXPY)
ROTN (PRNAME,PRNUMB,ROTX,ROTY)
ROTNO (PRNAME,PRNUMB,ROTOX,ROTOY,ROTX,ROTY)
PMREG (PRNAME,PRNUMB,REGION)
Each of these routines alters some subset if the parameters associated with a particular parameter file. The first call associated with a particular definition will set all undefined parameters to standard settings. For example rotation is assumed zero; expansion 1 in each direction and both darkness and thickness of lines set to 1.
DEFINING ROUTINES
(1) STDPCG (NAME,NUMBER,PRTYLV,MOD)
(2) FNDPCG (NAME,NUMBER)
(3) STDPC (NAME)
(4) FNDPC (NAME)
These routines assume NUMBER = 1
PRTYLV = 1
MODE= normal
(5) DFPCCN (PCCNNM,PCCNNU,PCNM,PCNU,PRNM,PRNU)
This routine defines a concrete picture.
The use of a concrete picture before a definition
will cause a definition of the following form
to take place:-
DFPCCN (PCCNNM,PCCNNU,PCCNMM,PCCNNU,PCCINM,PCCNNU)
(6) DEFREG (PRMINF,XMIN,YMIN,XMAX,YMAX,R,C,B,XPMIN,YPMIN,XPMAXMYPMAX, MI,MO,S)
(7) LIMITS (PRMINF,R,MIN,YMIN,XMAX,YMAX)
(8) REGION (PRMINF,R,XPMIN,YPMIN,XPMAX,YPMAX,P)
(9) REGOUT ( PRMINF,R,S )
(10) REGCNV (PRMINF,R,C)
(11) REGSHP (PRMINF,R,B)
(12) REGMD (PRMINF,R,MI,MO)
(13) TDSQG (NAME,NUMBER) Sequence definition
(14) FNDSQG (NAME,NUMBER)
(15) STDSNG (NAME,NUMBER) Scene definition
(16) FNDSNG (NAME,NUMBER)
SEQUENCE COMMANDS
DRAWW (PRMINF,NAME,NUMBER)
ADVFLM
LABEL (PRMINF,NUMBER)
GOTO (PRMINF,NUMBER)
LOAD (PRMINF,VAR,VAL)
OP (PRMINF,TYPE,VAR,VAL)
IFF (PRMINF,VAR,TYPE,VAL,NUMBER)
WHILE (PRMINF,VAR,TYPE,VAL)
The WHILE command will skip to the command following the next ADVFLM if condition is true. If false the commands up to the ADVFLM will be executed. Control then returns to the WHILE statement.
DRAWFR (NAME,NUMBER,FRCNT)
DRAWFT (NAME1,NUMB1,NAME2,NUMBq,FRMS)
DISOLV (NAME1,NUMB1,NAME2,NUMB2,FRMS)