6.2 VIEW Table & VIEW Test Commands

by Lance Ewing
Last updated: 31 August 1997
Retrived from the Internet Archive

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)

03-04

x position

05-06

y position

current view

08-09

pointer to start of view data.

current loop

number of loops

0C-0D

pointer to start of loop data

current cel

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

step size

1F-20

cycle time (stored twice)

direction (heading)
0 = stationary
1 = north
2 = north/east
3 = east
4 = south/east
5 = south
6 = south/west
7 = west
8 = north/west

0 = normal.motion
1 = wander
2 = follow.ego
3 = move.obj

0 = normal.cycle
1 = end.of.loop
2 = reverse.loop
3 = reverse.cycle

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	??

?? 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)

You can help keep The Sierra Help Pages and its affiliates alive by helping to defray some of the costs of hosting this site. If it has been of help to you, please consider contributing to help keep it online.
Thank you.

Top