[Coco] DynoSprite Demo 2 is here!

[Richard Goedeken]

Hello everyone,

I am proud to announce the completion and release of DynoSprite Demo 2, which
shows off the game engine that I've been working on for the past year and a
half.  This is the final demo that I intend to release, as the engine is now
at a stage of completion where it could be reasonably used for an entire game
as it is.  My next steps will be to finish up the documentation, release the
source code under an open source license, and then start working on my game.
Before I get into the details, here is a link to download the demo:

http://www.fascinationsoftware.com/media/DynospriteDemo2.zip

My initial motivation for writing this engine was to build something for
myself and for the community that could assist in the creation of very high
quality games for the Coco.  I know that many of us in the Coco community
share a feeling that our favorite 8-bit computer platform is capable of much
more than most people thought back in the day, and many of the games which
were available were somewhat lackluster and didn't use the machine to its
fullest potential. There have been a few really magnificent releases for the
Coco which have shown what is really possible, but not very many. Honestly,
it's because the hardware design makes it extremely difficult to use it to the
fullest potential.  But I hope that DynoSprite can change that and inspire at
least a few other developers to make awesome homebrew games in the future for
the CoCo 3.  By using the DynoSprite engine, a game developer can spend his or
her time on the interesting parts of game development, like the art, physics,
and gameplay, instead of fighting to get every last drop of performance out of
the hardware.

>From a technical standpoint, I wanted to try and use the Coco's strength (lots
of memory with 512k upgrade) in order to make up for its weakness (no
dedicated sound/sprite hardware).  To that end, I wrote a 'sprite compiler' in
Python, which parses text files containing sprite color maps, and uses some
complicated algorithms to generate near-optimal 6x09 assembly language code
for drawing and erasing the sprites on the screen, pixel by pixel, byte by
byte, word by word.  I'm pretty sure that there's no way to do faster
general-purpose sprites than what DynoSprite does, and it's done
automatically.  The final assembled sprite code does take up more memory than
normal sprite data would (about 4-5 bytes/pixel for DynoSprite vs. 2 bytes per
pixel for a traditional sprite engine), but it's worth spending the memory to
get all the sprite performance that we can.

The playable part of this demo is not intended to be an artistic 'tour de
force'.  The demo is intended to be a simple thing to showcase the DynoSprite
engine, which abstracts the game code from the core of the engine.  DynoSprite
is designed to be general purpose and could easily be used for many different
types of games.  For the demo which I am releasing today, the DynoSprite
engine is about 9400 lines of assembly code (plus a sophisticated build system
with about 3600 lines of Python code), while the game-specific part of the
demo (background tilemap generation, screen update, and ball physics) is only
about 1200 lines of 6809 assembly.

In this demo, there are only 5 different background tiles (colored pyramids
and black) which are mapped into tetris-like pieces placed in random positions
on the background tilemap during level initialization.  But the engine will
allow each level to have up to 255 different tiles which can be used in a
background map that can be up to 2000 tiles wide (100 horizontal screens) by
68 tiles high (5 vertical screens).

The engine isn't suitable for every type of game.  I made design decisions
which open some doors but close others.  It is useful for quite a few
different game styles though.  Some of the potential ideas which I think map
very well to DynoSprite's capabilities are:

 - Side-scrolling: R-Type, Silkworm, Super Cobra
 - Platforming: Super Marios Bros, Wonder Boy, Pitfall 2, Mega Man
 - Top-scrolling: Ikari Warriors, Heavy Barrel, Alien Syndrome, Time Pilot
 - Beat-em-up: Double Dragon (this ran on 6809s), Final Fight
 - Top-down racing: Micro Machines, Super Sprint, 1000 Miles Rally
 - Isometric games: Marble Madness, Zaxxon

The core engine only takes up 2 pages (16kb) of code and data, but there are a
lot of features.  The 320x200 16-color graphics mode is used.  The background
graphics are tilemapped with 16x16 tiles.  Vertical and horizontal scrolling
are supported, with a starting position granularity of 1 row vertical and 2
pixels (1 byte) horizontal.  Every new frame can be positioned within +/- 8
rows vertically and +/- 8 pixels horizontally of the last frame.  The amount
of CPU time required to scroll each new frame is roughly proportional to the
distance of the scroll, and it's fast.  Scrolling +/- 4 pixels either vertical
or horizontal takes less than 7.7 milliseconds on a 6809.

I also spent a lot of time optimizing the most CPU-intensive parts of the code
for the Hitachi 6309 processor.  The compiled sprite code is different for the
6309, as well as many of the core engine routines.  So there are separate disk
images for the 6809 ond 6309 version of the demo.  The difference is noticable
when playing the demo: the sprite routines are about 20% faster, and the
scrolling routines are about 25% faster.  The 6309 version stays at 60fps
unless you're scrolling full speed both horizontally and vertically.

DynoSprite has been tested and validated on many different Coco variants,
including on a real Coco 3 with RSDOS and a floppy drive, a CocoNET MicroSD
cartridge, a Coco SDC adapter, HDB-DOS with DriveWire loading over the serial
port, and with the Vcc and MESS emulators.  All of the game assets are
automatically processed, built, packaged, and compressed with the DynoSprite
build system.  With the exception of audio waveforms, all of the game assets
are divided into groups, and only the asset groups which are needed for a
particular level are loaded for that level.  This should allow for large
games.  All of the game loading logic and memory management code is built into
DynoSprite.  There is a virtual memory manager which automatically relocates
memory pages when the graphics aperature crosses over them.  The data
compression algorithm used is DEFLATE, which is the same algorithm used by
PKZIP and GZIP.  In fact, the build system uses GZIP by default because it is
much faster than my Python implementation of a compressor.  This should get a
compression ratio between 2:1 and 3:1 for most game assets.

The maximum sprite size is 62x32.  Sprites can be positioned anywhere on the
screen with single-pixel precision.  They can overlap with the left, right, or
bottom sides of the screen.  DynoSprite also uses a variable frame-rate
mechanism which allows the game to maintain the same feeling of speed even
when the frame rendering time exceeds one 60hz field time.  The frame rate can
drop down to 30hz or 20hz and the game video will just get choppier instead of
feeling like it's bogging down.  This is a mechanism which must be supported
by the game code in order to work.  All of the game code and assets are
separated from the core engine code, and there is an object-oriented design to
the interface between the game and the engine.  This simplifies the game
development effort.

DynoSprite has built-in support for keyboard and joystick control, RGB and
Composite colors, and internal 6-bit DAC and Orchestra-90 sampled sound
output.  There is a splash image loader which is used for the main menu
background and the small splash images shown in the level loading screen.
There are also some "fade in / fade out" routines for applying smooth
transitions in-between the various screens.

So that's pretty much it.  I've spent many many hours working on this and I'm
very glad to finally be able to release this demo to you.  I hope you all
enjoy it, and that this software can be helpful in creating some incredible
Coco games.  In the next few weeks I will be writing more documentation and
getting everything put together to make a source code release.  Feel free to
contact me directly with any questions that you have.

Regards,
Richard