6.2 VIEW table and VIEW test commands by Lance Ewing <be@ihug.co.nz> Last updated: 31 August 1997 Firstly we should note that there is a difference between a VIEW and a VIEW object. A VIEW is a collection of animated sequences that are stored in a VOL file. When a view is loaded into memory, it is then connected to one or more VIEW table entries (see below) that store information on what the interpreter calls objects (don't confuse this with inventory items). An object is an animated sprite that is currently being controlled by the interpreter. With each interpretation cycle, the state of each object in the VIEW table is updated and, if required, updated on the screen. It is therefore possible to have five or more hungry crocodiles swimming in a moat each which have there own VIEW table entries, all of which point to the same VIEW data. View objects appear to have the following properties: x position: y position: current view: current loop: current cel: priority: cycle time: 1/n gives the fraction of the maximum speed. step time: 1/n gives the fraction of the maximum speed. x size: in pixels y size: in pixels step size: direction: number of loops: number of cels: There are probably other properties that aren't listed here which they also possess. In an object oriented environment such as SCI, these properties are stored as instance variables (or selectors) as part of the object. Since AGI isn't object oriented, we would expect to find some sort of VIEW table stored in memory which holds theses properties within it. In SQ2 this VIEW table consisted of 43 byte entries. Most commands that deal with VIEW objects will make adjustments to the data in the entry for the relevant object. VIEW TABLE ENTRY Offset Function 00-01 step.time (stored twice) 02 ?? 03-04 x position 05-06 y position 07 current view 08-09 pointer to start of view data. 0A current loop 0B number of loops 0C-0D pointer to start of loop data 0E current cel 0F number of cels 10-11 pointer to start of cel data 12-13 pointer to start of cel data (same as above) 14-15 ?? 16-17 copy of x position 18-19 copy of y position 1A-1B x size 1C-1D y size 1E step size 1F-20 cycle time (stored twice) 21 direction (heading) 0 = stationary 1 = north 2 = north/east 3 = east 4 = south/east 5 = south 6 = south/west 7 = west 8 = north/west 22 0 = normal.motion 1 = wander 2 = follow.ego 3 = move.obj 23 0 = normal.cycle 1 = end.of.loop 2 = reverse.loop 3 = reverse.cycle 24 priority 25-26 View Flags Bit Function 0 ?? 1 0= observe blocks, 1 = ignore blocks 2 0 = priority released, 1 = fixed priority 3 0 = observe horizon, 1 = ignore horizon 4 ?? 5 0 = stop cycling, 1 = cycling. 6 ?? 7 ?? 8 1 = view on water 9 0 = observe objects, 1 = ignore objects 10 ?? 11 1 = view on land 12 ?? 13 0 = loop released, 1 = loop fixed 14 ?? 15 ?? 27 ?? Storage for some view related command parameters. 28 ?? Storage for some view related command parameters. 29 ?? Storage for some view related command parameters. 2A ?? Storage for some view related command parameters. Note: The above format structure is simply the way in which Sierras AGI interpreter stores information about VIEW objects. In attempting to write an AGI interpreter, you would not have to restrict yourself to this format, just as long as you store this information in some manner that the interpreter can have access to. TEST COMMANDS AND VIEWS There are four test commands that are to do with VIEWS. These are: obj.in.box posn right.posn centre.posn All of these commands are for testing whether a VIEW object is within a given rectangle on the screen. All of them take the same parameters and apart from a slight change in each case, they do exactly the same thing and even share about 95% of their code. The general form is the following: command(VIEW object num, left, top, right, bottom) A VIEW has a position stored in its VIEW table entry that says where abouts on the screen the view object is at the present time. The problem with this position is saying which pixel is the position pixel for an object that takes up usually over a hundred pixels. Okay, you might say that most views are actors or props that sit on the ground and therefore the bottom row of pixels will give you a y position. This is a good argument, but now you need to say which of these pixels in the bottom row is the actual position. Sierra must have faced this problem or they wouldn't have provided four commands for achieving essentially the same thing. By default the position hot spot in a VIEW is the bottom left pixel. ......... ......... ......... ......... X = position hot spot. ......... ......... X........ This is the location that gets stored in the VIEW object table. The difference between the test commands given above is how they adjust the x position before testing it against the rectangle border lines. posn Leaves the x position as it is (left side). right.posn Adds the x size - 1 to the x position giving the right side. center.posn Adds (xsize/2) to the x position giving the centre. obj.in.box Tests both the left and right sides which essentially tests whether the whole bottom row of pixels is in the 'box'. posn Leaves the x position as it is (left side). right.posn Adds the x size - 1 to the x position giving the right side. center.posn Adds (xsize/2) to the x position giving the centre. obj.in.box Tests both the left and right sides which essentially tests whether the whole bottom row of pixels is in the 'box'.   Command X1 X2 Y posn x x y right.posn x + xsize - 1 x + xsize - 1 y center.posn x + (xsize/2) x + (xsize/2) y obj.in.box x x + xsize - 1 y Test is TRUE if: (X1 >= left) && (y >= top) && (X2 <= right) && (y <= bottom)