A Game Development Blog by Nickolas Marentes for the Tandy Color Computer 3.

      This blog will primarily focus on the creative and technical design aspects I employ to create this game.
      Due to time constraints, I will not be delving into the actual coding details.



  MAY
2021

Chapter 06 - Elevators, Fire and Compiled Sprites

For 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 chapter.

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 it further.

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.



OLD GRAPHICS



NEW GRAPHICS


Traditional Sprites

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 sprites.

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.


Compiled Sprites

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 well.




Copyright 2021 by Nickolas Marentes