Tandy Coco 3: new game engine called DynoSprite and demo

[Richard42]

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 plan for the near future is to start working on a game with this engine. 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. I have also written some documentation for the DynoSprite engine and released the source code under a BSD license. You can get it from my github page:

 

https://github.com/richard42/dynosprite

Regards,
Richard

[RangerG]

I would love to see more homebrews for the CoCo. I think with DriveWire and now the CoCoSDC (and a flash cart in the works I believe) that the user base for these games is getting larger. Thanks for this.

[Amphioxys]

Totally awesome! This has long been a dream of mine... Is there any chance you could make a YouTube video of the demo??

[remz]

Amazing job!

This is a work of art: documented, complete game engine.

 

I also wrote a sprite/tilemap engine for the coco 3 a couple of years ago using compiled sprite. You can see a youtube video of it here, or you can download the DSK and try it. It runs at 60 fps with up to 8 sprites, but that was it. No game logic, no sound, nothing else

https://sites.google.com/site/rveilleux/coco3home/rems-coco-3-files

Rem sprite demo: http://youtu.be/0tsD7sQ1bAY

 

 

Fantastic work Richard!