Part 8 By PAUL JONES
SO far we have used GCOL0 to choose our graphics colours. In
fact, we've treated GCOL as if it always had a 0 after it. This
isn't always so — we can follow GCOL directly with any numbers
in the range 0 to 4.
When we use GCOL0, the colour specified by the following logical
colour number is "forcibly painted" onto the micro's
screen, completely overpainting whatever was below.
However, the other options, such as GCOL1, while still allowing
you to specify a logical colour number, blend that colour with
the colour already on the screen at the position you're plotting.
The micro doesn't work on the old "blue + yellow = green"
rule we learnt at school. Instead, the colour the computer "mixes"
depends on how the two logical colour numbers involved (the one
already on the screen, and that specified in the GCOL) combine
logically.
The various GCOL options either OR, AND, EOR or NOT the numbers
involved.
GCOL1 specifies OR GCOL2 specifies AND GCOL3 specifies EOR GCOL4
quite simply NOTs, or inverts, the colour at present on the screen,
the logical colours you specify after the comma being a dummy.
Try Program I.
10 REM *** PROGRAM I ***
20 MODE 5
30 VDU 19,3,4,0,0,0
40 GCOL0,1
50 PROCbox(200)
60 A$=GET$
70 GCOLl,2
80 PROCbox(200)
90 END
100 DEF PROCbox(offset%)
110 MOVE 800+offset%,200
120 MOVE offset%,200
130 PLOT 85,800+offset%,800
140 PLOT 85,offset%,800
150 ENDPROC
Line 30 simply changes logical colour 3 to blue. Line 40 selects
logical colour 1, in this case red, as foreground, while line
50 prints a red rectangle.
Line 60 holds the program until you press a key, then line 70
selects a new logical colour to reprint the box in.
Now it may look as if you're redrawing the box in logical colour
2, but notice you're using GCOL1,2 not GCOL0,2. The GCOL1 means
that the
BBC Micro will logically OR the present foreground colour with
2, and use the result as the foreground colour.
(If you're not sure what logically ORing something means, see
this month's Bit and Bytes on Page 67.)
As the previous logical colour number was 1, 1 OR 2 gives
3 or, in the rather clearer binary, %01 OR %10 gives %11
So, the second time it is called, PROCbox draws the rectangle
with logical colour 3, in this case blue.
You're probably wondering what all the fuss is about. It seems
a longwinded way of printing a blue rectangle. Why didn't I just
use a GCOLO,3 followed by PROCbox?
Well, the point is that, by doing things cleverly, you can overprint
one colour with another in such a way that the micro "remembers"
the colour that was there first!
Try Program II.
10 REM *** PROBRAM II ***
20 MODE 5
30 VDU 19,3,4,0,0,0
40 GCOL0,1
50 PROCbox(0)
60 GCOLl,2
70 PROCbox(400)
80 END
90 DEF PROCbox(offset%)
100 MOVE 800+offset%,200
110 MOVE offset%,200
120 PLOT 85,800+offset%,800
130 PLOT 85,offset%,800
140 ENDPROC
Here we omit the pause before the second rectangle is drawn,
and the two rectangles, though overlapping, are offset from each
other.
Amazingly, three rectangles appear on the screen. Figure I should
help to make this clearer.
| |
%01
|
%00
|
| |
OR
|
OR
|
|
%01
|
%10
|
%10
|
| |
gives
|
gives
|
| |
%11
|
%10
|
|
(red)
|
(blue)
|
(yellow)
|
Figure I: The rectangles composing Program I underneath where it
happens to be plotting.
What happens is that the first rectangle is drawn normally in
red (GCOL0,1). The second rectangle is drawn with GCOL 1,2. This
ORs logical colour 2 with the logical colour numbers
In this case, the second rectangle is spread over two colours
- the red of the first rectangle (%01) and the black of the background
(%00). . This gives two different rectangles since %01 OR %10
gives %11 (blue) and %00 OR %10 gives %10 (yellow)
Program III is a variant of Program II.
10 REM *** PROGRAM III ***
20 MODE 5
30 VDU 19,3,1,0,0,0
40 GCOL1,1
50 PROCbox(0)
60 GCOL1,2
70 PROCbox(400)
80 END
90 DEF PROCbox(offset%)
100 MOVE 800+offset%,200
110 MOVE offset%,200
120 PLOT 85,800+offset%,800
130 PLOT 85,offset%,800
140 ENDPROC
What we've done here is to use line 30 to redefine logical colour
3 to be actual colour 1 (red).
This means that there are now two logical colour numbers for
red (%01 and %11).
Also, we're ORing the first rectangle onto the screen — line
40 uses a GCOL1,1. As it is going on the background (%00) this
doesn't make any effective difference. For the rest of this article
we're going to be ORing on rather than using GCOL0.
If you've run Program III you'll have noticed that we get two
rectangles, red and yellow. The red actually comprises the old
red and blue rectangles combined.
This is because the old blue rectangle is in colour %11 since
we've ORed %01 with %10. As we've redefined that as red in line
30, the two rectangles merge into one red rectangle (actually
I consisting of two logical colour numbers).
One way to think about this arrangement is to imagine that the
colour red is somehow "in front" of the colour yellow,
so our original red rectangle blocks out or obscures the yellow
rectangle where they overlap.
You can consider the red to be the "foreground colour"
and the yellow a "midground colour". (We've already
got a background.)
When you think like this, it's natural that the foreground should
obscure the midground in this way.
When we think of logical colours as belonging to fore-, mid-
and background we say we are dealing with "multi-plane images".
Think of each colour as being drawn on separate screens, or
planes, one on top of the other. The one on top is the foreground
colour, which will then obscure the mid- and background colours
underneath.
In Program III, the red is drawn in the first plane and the
yellow in the second, so the red overlaps the yellow — any yellow
painted on the midplane "under" a red area will not
show.
So, by using this system of ORing colours onto the screen, we
can deal with overlapping images.
There's more to this than meets the eye. When you OR a foreground
onto a midground colour, the micro "remembers" that
there was a midground colour there. So, if the foreground "moves
off' the midground colour shows through.
You see, when you OR logical colour 2 with logical colour 1,
the result is logical colour 3 which, with a cunning VDU 19, we
arranged to be the foreground colour.
The situation is easier to follow in binary: %01 and %11 are
both the foreground colour. Notice that bit zero is set - that
is, equal to one - when we are talking about a foreground colour.
The other two colour numbers in a four colour mode, %00 and
%10, which do not have this bit set, are the back-and midground
colours respectively.
Now we are ORing the colours onto the graphics screen. So, the
fact that bit one is set in %11 must mean that originally there
was some yellow "underneath".
After all, if you're just ORing the three logical colours %00,
%01 and %10 how else can bit one be set without having %10 in
on the deal? (We never use %11 when ORing onto the screen since
we already have %01 to do the job — they're the same colour.)
So we can consider bit zero to be the "foreground bit"
and bit one to be the "midground bit". If either bit
is set on its own, the respective colour is shown.
If both are set, the foreground takes precedence, but the computer
remembers (by keeping bit one set) that there was yellow there.
To recap, in the last program, bit zero set shows that there's
some red in the shape, and you're always bound to see it because
it's foreground.
Bit one set means that there is yellow in the shape — even if
you can't see it because it's obscured by a foreground colour.
Figure II summarises this.
|
Logical colour number
|
Interpretation
|
|
Binary
|
Decimal
|
|
00
|
0
|
Background
|
|
01
|
1
|
Simple foreground
|
|
10
|
2
|
Simple midground
|
|
11
|
3
|
Foreground obscuring midground
|
Figure II: Multiplane images in a four colour mode
Now I hinted previously that the foreground colour could "move
off", leaving the midground showing through (if there was
anything there).
Our system can cope with this since it remembers when the foreground
is obscuring the background.
You see, by using another GCOL statement, you can "turn
off' or "clear to zero" the foreground colour bit in
the logical colour number. After all, if you change %11 to %10,
you'll be left with something in the midground colour.
We can "clear" bits like this with the AND statement.
We just AND the number we're working on with another binary number
consisting of 1s in the bits we want to preserve, and 0s in the
bits we wish to clear.
So, to clear the foreground bit, we want to AND the logical
colour number with %10.
To show how this works, consider the case of a foreground colour
obscuring a background colour. As we've seen, the logical colour
number for this is %11.
Now %11 AND %10 gives %10 -that is, we've cleared the foreground
bit leaving only the midground.
If there were no midground present — that is, if we had just
a simple foreground (%01) - then %01 AND %10 gives %00, leaving
just the background.
So, we can "turn off" the foreground by ANDing it
with %10. GCOL2 allows us to do this sort of ANDing of logical
colour numbers. It ANDs the logical colour number following it
with that on the screen.
Program IV is identical to Program III in that it draws a red
foreground rectangle, partly obscuring a yellow midground rectangle.
10 REM *** PROGRAM IV ***
20 MODE 5
30 VDU 19,3,1,0,0,0
40 GCOL1,1
50 PROCbox(0)
60 A$=GET$
70 GCOLl,2
80 PROCbox(400)
90 A$=GET$
100 GCOL2,2
110 PROCbox(0)
120 END
130 DEF PROCbox(offset%)
140 MOVE 800+offset%,200
150 MOVE offset%,200
160 PLOT 85,800+offset%,800
170 PLOT 85,offset%,800
180 ENDPROC
However, in lines 100 and 110, we AND the foreground rectangle
with %10, clearing the foreground bit. This effectively "unprints"
the foreground rectangle, revealing the part of the midground
rectangle previously obscured.
(If you remember, the obscured part was in logical colour %11,
so ANDing with %10 leaves you with %10, the midground colour.)
Similarly, we can clear the mid-ground colour. This time we
AND the logical colour number with %01, the zero "killing"
the required bit.
To demonstrate this, add these lines to Program IV:
100 GCOL2,1
110 PROCbox(400)
These changes ensure that we are ANDing the second rectangle
with %01.
When you run it, the second rectangle disappears. Actually,
the whole of the yellow midground rectangle goes — even though
you can't see it behind the red foreground.
Also, the red foreground that previously overlapped the yellow
is now totally in logical colour %01. Before it was %11 - now
we've ANDed it with %01 to give %01.
So, as our scheme has developed, we
• OR to put shapes on the screen
• AND to take shapes off the screen
Although we have restricted ourselves to a four colour mode,
this has given us three effective colours (one of which has two
logical colour numbers), and the power to overlap and recover
shapes.
Finally, we can use the ability to OR shapes to display two
overlapping shapes separately and instantly on the same screen
without overlapping them.
Program V shows how. As Figure III demonstrates, we simply OR
the rectangle onto the triangle.
10 REM *** PROGRAM V ***
20 MODE 5
30 VDU 19,3,1,0,0,0
40 GCOLl,2:PROCtriangle(200):PROCwait
50 GCOLl,l:PROCbox(200):PROCwait
60 REPEAT
70 PROCdiaplay_triangle:PROCwait
80 PROCdisplay_box:PROCwait
90 UNTIL FALSE
100 DEF PROCbox(offset%)
110 MOVE 800+offset%,200
120 MOVE offset%,200
130 PLOT 85,800+offset%,600
140 PLOT 85,offset%,600
150 ENDPROC
160 DEF PROCtriangle(offset%)
170 MOVE 800+offset%,200
180 MOVE offset%,200
190 PLOT 85,400+offset%,1000
200 ENDPROC
210 DEF PROCdisplay_box
220 VDU 19,1,1,0,0,0
230 VDU 19,2,0,0,0,0
240 VDU 19,3,1,0,0,0
250 ENDPROC
260 DEF PROCdisplay triangle
270 VDU 19,1,0,0,0,0
280 VDU 19,2,3,0,0,0
290 VDU 19,3,3,0,0,0
300 ENDPROC
310 DEF PROCwait
320 FOR loop%=0 TO 2000
330 NEXT loop%
340 ENDPROC
To display the triangle, we use VDU 19 statements to turn colours
2 and 3 "on" in the triangle colour, and to make colour
1 the background colour (PROCdisplay_triangle).
Similarly, to display the rectangle, we turn 3 and 1 "on"
and set 2 to background (PROCdisplay_rectangle).
NEXT MONTH we'll be looking at some more GCOL techniques.
Figure III: Logical colours in Program IV
