home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Loadstar 229
/
229.d81
/
t.sprites
< prev
next >
Wrap
Text File
|
2022-08-26
|
9KB
|
349 lines
u
S P R I T E S A R E F U N
By Dave Moorman
This article is for the Beginner
C-64 programmer who is ready to
become an Intermediate. You have
BASIC down, and want to get into some
of the cool stuff our sweet little
computer can do. Like sprites.
"Sprite" is not the legal term.
Atari, Apple or TI trademarked the
term before Commodore could get
around to it. The official term is
"moveable objects." Whatever. But
when it comes to sprites, no one does
it better than a C-64.
Sprites are small bitmap images
which can appear on top of (or
behind) screen characters without
messing up the screen data. They are
part of the hardware functions of the
VIC II -- Video Interface Chip. The
VIC II was created in 1981 to be the
Mother of All 8-bit Video Devices,
and became one of the reasons the
Commodore 64 was designed and on the
market in just three months.
The VIC II has a ton of features:
40-column text screen
320x200 pixel High Resolution
Bitmap Graphics
160x200 (double-wide) pixel
Multi-color Bitmap
Graphics
16 colors -- with up to four
colors in each character
cell
Raster Interrupts for split
Screens
Light Pen capable
8 Sprites
Being 1981 technology, the VIC II
has limitations. But remember, it is
a 4 Megahertz co-processing chip
which must share memory with the 1
Megahertz 6510 micro-processor. What
it accomplishes is pure magic.
Like sprites. If you have ever
read what a programmer has to do to
get moving objects on a VGA screen,
you will certainly appreciate how
easy sprites are to program. However,
the programming is hardware based,
involving many of the 47 registers of
the VIC II chip. (A register is a
memory location inside the C-64 which
controls a co-processor such as the
VIC II. When you POKE53281,0 to get a
black background, you have just put 0
into one of the VIC II registers.
Sprites require quite a bit of
set-up. An ML module such as
JoySprite greatly helps in
controlling sprites -- and even adds
a number of features through clever
Machine Language programming.
Here we will look at sprites
themselves -- and use some of the
registers to make, display, and move
sprites around the screen. The
problem for programmers is that in
their rush to get the C-64 out the
door, Commodore included BASIC 2.0,
which was actually designed for the
PET computer some five years before.
No BASIC commands were added for
sprites (or sound).
However, BASIC 2.0 does have PEEK
and POKE, which allow use to directly
access memory and registers. Which we
will now do.
A sprite must have an image -- a
24x21 pixel bitmap. In high
resolution mode, the On pixels can be
any one color. The Off pixels are
transparent, showing whatever is on
the screen behind the sprite. So our
first step is to create a sprite. A
[simple] sprite, that is. You can do
all this in immediate mode, or write
the code as program lines and RUN
your program. We will just show the
code.
FOR X=0TO63:POKE832+X,255:NEXT
This FOR-NEXT loop POKEs 255's
into memory locations 832 to 895. In
binary digits, 255 = 11111111. With a
bitmap, every bit (BInary digiT) that
is on or 1 becomes a pixel on the
screen. So here we have created a
block of on pixels.
Now a sprite must know what image
to display. Sprite images are
numbered 0 to 255, and point to a
memory location divided by 64. That
means that the sprite image at 832 is
image number 832/64 or 13. (We have 3
easy to use locations for sprites at
832, 896, and 960 -- numbered 13, 14,
and 15 respectively. See "Build a
Boot" for move about making room for
more sprites.)
The sprites themselves are also
numbered -- 0 through 7. So we will
put image 13 in sprite 0.
POKE2040,13
The sprite image pointer bytes
begin 1016 bytes after the beginning
of the text screen. For the default
text screen, that means 2040-2047
hold the sprite image numbers for
sprites 0-7.
So far, so good. Now we have to
turn on the sprite. The sprite enable
register (53269) uses bit-logic to
tell which sprites are on or off.
Bit: 7 6 5 4 3 2 1 0
M: 0 0 0 0 0 0 0 0
To turn on Sprite 0, we must set bit
0. (Do you see a pattern here?) That
would be:
Bit: 7 6 5 4 3 2 1 0
M: 0 0 0 0 0 0 0 1
Values:128 64 32 16 8 4 2 1
If you add up the Values of the
set bits, you will have the decimal
value to POKE into 53269. In this
case it is easy: 1.
But where is the sprite? We have
not positioned it on the screen yet.
Each sprite has an X and Y location,
with the values in the following
memory locations:
53248 Sprite0 X
53249 Sprite0 Y
53250 Sprite1 X
53251 Sprite1 Y
53252 Sprite2 X
53253 Sprite2 Y
53254 Sprite3 X
53255 Sprite3 Y
53256 Sprite4 X
53257 Sprite4 Y
53258 Sprite5 X
53259 Sprite5 Y
53260 Sprite6 X
53261 Sprite6 Y
53262 Sprite7 X
53263 Sprite7 Y
You don't have to remember every
number. The X-coordinate POKEd with
X- POKE 53248 + SP# * 2, location
Y- POKE 53249 + SP# * 2, location
For our purposes, we will put the
sprite at 100x100:
POKE 53248,100:POKE 53249,100
And there it is! OK, it is just a
block of color. But you did it
yourself, right!
We have one little problem with
the X-coordinate. The screen is 320
pixels across. Moreover, sprites can
hide behind the borders, so the first
full position on the screen is 24.
Try it!
Now try POKE 53248,320. It does
not work. A byte can only hold a
value of 0 through 255. And we need
at least 344 to put the sprite behind
the right border. What we need is
just one more bit (binary digit).
Then we can use values 0-511.
The designers didn't have room on
the chip for eight more registers, so
they had to use a bit-logic byte for
the high bit of the X-coordinate --
53264. This works just like the
sprite enable byte. For Sprite 0,
this is not too hard. You have to
divide the X-coordinate into low and
high bytes.
When I am programming and need
LO/HI divisions, I write a couple of
DEFined FuNctions:
10 DEF FNL(X)=X-FNH(X)*256
20 DEF FNH(X)=INT(X/256)
Here is a clunky way to do it in
immediate mode:
X = 300
XH = INT(X/256)
XL = X-XH*256
POKE 53248,XL
POKE 53264,XH
Since we are working with Sprite
0, we are only dealing with bit 0 in
53264. When you are working with more
sprites, use JoySprite -- which does
all the grunt work!
Now for the color. The color
registers begin at 53287. So, POKE
53287+Sprite#,Color will do the
trick. For Sprite 0, just POKE
53287,7 to turn your sprite yellow.
Multi-color (another bit-logic
byte at 53276) will turn any or all
sprites to multi-color mode. To do
this, two bits are used for each
pixel, which is then twice as wide as
a high resolution pixel. The two bits
give each sprite a possibility of
three colors (and transparent).
00 - Transparent
01 - Color 1 53285
10 - Color 2 53287+Sprite#
11 - Color 3 53286
All sprites share 01 and 11, with
the color registers as shown above.
Only Color 2 (01) is peculiar to the
particular sprite.
To see multi-color at work, do
this:
FOR X=0TO63:POKE832+X,16+8+2+1:NEXT
This will create three sets of four
vertical bars -- 00, 01, 10, and 11
(in that order). You can then POKE
the registers with various color
codes.
Sprites are not all that big --
24x21 pixels on a 320x200 screen. So
we can double the width and height of
a sprite, again with two bit-logic
bytes:
X-expand 53277
Y-expand 53271
Since we are working with Sprite 0,
POKEing a 1 into these registers will
affect our image. Note: the
resolution is not improved, becoming
rather blocky.
Sprites can appear on top of
screen pixels or behind, depending on
the Priority register. This, too, is
a bit-logic byte -- at 53275.
The last pair of sprite registers
report collisions. When a sprite
touches any other sprite, or any
screen pixel, the event is recorded
in one of two bit-logic bytes:
Sprite to Sprite Collision 53278