06 - Elevators, Fire and Compiled SpritesFor this chapter, I have begun to get a few of the objects moving and the players character walking.
I have made all the Elevators
in the game operate autonomously by moving up and down along their
respective rails, stopping for a moment at each platform to
allow passengers to board.
Secondly, I have all the Fires
burning where they have been assigned. The purpose of the fires is to
act as an obstacle that your character cannot pass unless there is a
switch available that turns the fire off.
Lastly, I have your player's character appearing as a Sprite
that can walk left and right on the platforms as well as to step onto
an elevator and ride up and down to access other platforms. Still to
add is the ability of your character to jump across platforms, throw
EMF bombs and fall to his doom. These will be added for the next
I will hold off presenting a video of this current work until the next chapter when I'll have more to showcase.
What is a Sprite?
In the real world, Sprite is a colorless, lemon and lime flavored soft drink created by The CoCa-Cola Company.
But in the computer world, a Sprite is a two-dimensional bitmap that is integrated into a larger scene, most often in a 2D video game.
Originally, the term "sprites" referred to fixed-sized objects
composited together by hardware with a background. Back in the 70's and
80's, computers from Atari, Commodore, Texas Instruments, MSX systems and many video arcade machines had sprite capabilities
built in to their video generation hardware as a way of making the
creation, moving and display of these objects easier and quicker than
using software alone. Hardware generated sprites took the burden off
the CPU to allow smoother and faster movement of characters and objects
within a game scene.
The CoCo does not have this hardware capability so sprites needed to be generated via software.
Sprites in Zero Hour
For this chapter, I have created all of the
game's sprites but only the elevators, fires and player sprite are active. The player's sprite now walks on
the platforms and rides the moving elevators.
The sprites in Zero Hour are inspired from my first CoCo3 game that I created back in 1988, Rupert Rythym.
I always liked the graphics I had created for this game and simply
modelled the graphics from that game as a starting point and then improved
The player's character is much the same although I added a few
extra frames for the walking animation. The original used 3 frames
of walking animation which was barely enough and he had a bit of an odd waddle
to his stride. I have improved and extended the walking animation to 6
frames and he now has a more natural stride. I also improved the
appearance of the security robots and the roving eyeball droid sprites
and will eventually get them moving in the game.
What do I mean by traditional sprites? To answer this, you need to understand the way software sprites are normally created.
With Rupert Rythym, I created the graphics using a 2D graphics editor
and stored these in RAM as small bitmaps. I also created a version of
the same graphics that was a mask of the original. When I wanted to
display the sprite, I would read each byte from the master graphic and the
mask to work out the overlay of the
graphics onto the background. This masking overlays the pixels of the
sprite cleanly over the pixels of the background it is covering while
still exposing all of the pixels in the background not covered by the
sprite. The blank areas of the sprite bitmap are black and are
therefore treated as transparent.
This was required for each byte in the sprite. Bytes that were completely blank
and did not contain any valid graphics of the sprite where skipped
completely. This worked well and created some nice
smooth graphics fully superimposed over the background.
The problem with this method was that it was slow. There was a large
CPU overhead for each sprite requiring multiple reads of bytes to end up with the
results I was wanting to achieve. This limited the number of sprites I could display and the frame rate of the game.
In my later games, I did away with the mask as I worked out ways to
achieve the same results without it. This sped up the processing of
each sprite but it would never match the speed of dedicated hardware
Depending on the game, if the sprites didn't require overlay over other
background graphics (background was simply blank) I could achieve a
speed up by avoiding the overlaying of pixels to the background.
Another method was to design the entire sprite so that it filled a full byte
boundary OR I could simply ignore the boundaries and hope the
sprite's black edge overspill didn't look too bad.
These were early days when I was trying to learn new and better techniques to display sprites in my games.
Enter the Compiled Sprite technique.
This technique does away with many of the reads and checks of the
traditional techniques. It replaces the bitmap graphics of each sprite
stored in RAM with direct machine code for drawing the sprite.
What I do is to design and create all of the Sprite graphics using a 2D graphics editor package as before. I use Brilliance on my Amiga computer but one can use any package they are comfortable with on a PC, Mac or even the CoCo.
Once I am happy with the graphics, I then encode the graphics as actual
code to draw the sprite. I can load an 8 bit (2 pixels) or 16 bit (4 pixels) register with
data that I simply store directly to the display at the desired
location usually pointed to by an address register using an offset. If
that data that I am writing are repeated elsewhere in the sprite, I
write them too, avoiding the need to reload the data. I also
merge the pixels in bytes that don't fill the byte without the need to
test the byte because I've already predetermined that.
By using direct code, I save a lot of CPU time by avoiding many of the
reads and checks because I already know in advance what bytes need to
be skipped and which need to have the pixels overlaid with the
background. The end results are faster sprites.
There are some disadvantages though. Compiled Sprite code takes up a
lot more RAM. It essentially runs as an unrolled loop, one sequential
block of code running from start to finish. It's also more time
consuming to create and change the code manually. The more sprites
meant more code.
But I have a solution!
Compiled Sprites Utility
After I create all the sprites using a 2D graphics program and
importing the graphics to the CoCo, I then run a utility I've written
in BASIC to analyze each sprite and gather common data bytes. I also locate
bytes which need to be written complete or overlaid with the
background. The program then starts POKE'ing the code to recreate each
sprite to an assigned part of memory.
Depending on the number of sprites I have, this can take 10 minutes to
complete but when done, I can display any of the sprites from within my
game by supplying a location to draw the sprite (X register), the
sprite number I wish to draw (B register) and then call the generated
Compiled Sprite code.
Like magic, the sprite is drawn with perfect pixel overlay onto the
background graphics. This, along with the main graphics engine of the
game managing the restoration of the background that was overwritten by
the sprite, it makes the use of sprites very easy and fast.
In future revisions of this utility, I would look for further
optimizations to the code generation but for now, this is working very