Difference between revisions of "AGI/Specifications/View"

There are four LOGIC test commands that are to do with VIEWS. These are:

There are four LOGIC test commands that are to do with VIEWS. These are:

     obj.in.box()

     obj.in.box()

     posn()

     posn()

     right.posn()

     right.posn()

     centre.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:

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)

     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.

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.

By default the position hot spot in a VIEW is the bottom left pixel.

     .........

     .........

     .........

     .........

     .........

     .........

     X........

     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 (xsize-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".

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 (xsize-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".

The test is TRUE if

The test is TRUE if

     (X1 >= left) && (y >= top) && (X2 <= right) && (y <= bottom).

     (X1 >= left) && (y >= top) && (X2 <= right) && (y <= bottom).

<span id="Sample"></span>

<span id="Sample"></span>

==Sample code==

==Sample code==