Loadstar 229/229.d81/t.sprites

Text File | 2003-01-01 | 8.9 KB | 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
    Sprite to Pixel Collision  53279

 These registers show [all] sprites
involved in collisions. The Sprite to
Sprite register cannot sort out which
sprite touched which other sprite.
This requires more programming to
compare relative locations.

    Sprites are fun -- easy to move,
easy to switch and animate. Working
with the raw hardware registers,
using PEEKs and POKEs, can be
nerve-racking -- which is why
JoySprite is so useful in program
construction.

    Below is a list of all sprite
registers, in numerical order.

  53248 (+ sprite# * 2) X-coord (low)

  53249 (+ sprite# * 2) Y-coord

  53264 (bit-logic)     X-coord (hi)


  53269 (bit-logic)     Sprite Enable

  53271 (bit-logic)     Y-expand

  53275 (bit-logic)     Priority
  53276 (bit-logic)     Multi-Color
  53277 (bit-logic)     X-expand
  53278 (bit-logic)     Sprite Col
  53279 (bit-logic)     Pixel Col

 DMM