[Coco] Phoenix IDE gaining sprite/tiles/map editor

[Nick Marentes]

All of my games dating back to my TRS-80 Model 1, had the graphics 
stored seperately from the code. The reason was to keep the assembly 
source code short and optimised with just code. This made it easier to 
read. It was also due to EDTASM being written for 64K and so your source 
code buffer capacity was limited.

I now use Robert Gault's patched EDTASM6309 that has a much larger 
buffer but I still keep the graphics seperate to aid code readability.

I remember coding my TRS-80 Model 1 games as two or three seperate 
blocks of code because they would not fit all together in the 16K or so 
of buffer space available back then. Very messy.

For the graphics, I used an Amiga with the package "Brilliance". I found 
this to be a very good package for the 2D graphics I was creating and 
have resurrected my Amiga for my current project to do the same. I've 
tried using Paintshop Pro and while it's a very good graphics program, 
it doesn't quite compare to the fluidness and easy at which I find using 
Brilliance on my Amiga... running faster and smoother at 8Mhz with only 
1Mb of RAM.

My current game for the CoCo, "Fortress", does not map the tiles in the 
conventional way. They are also very large. A normal Sprite editor does 
not suit and so I have broken the graphics development process into 
several stages.

Stage one was to write a custom map editor in BASIC... completed.

Stage two is to draw the graphic elements that make up the graphics with 
my Amiga, saving the pages of graphics as individual GIF images. Later 
these are transferred to the CoCo using GIFREADR... work in progress.

Stage three, I will write a BASIC program that will take these images 
and compress and compile each graphic element to take up less space.

Stage four, I write code within the game that during play will build the 
finished map into graphics, storing it in another compressed format for 
the Game Engine itself to use.

A lot of post processing of graphics but this is necessary to reduce the 
burden of graphics manipulation to the CPU during runtime and allow the 
game to run as fast as I can to achieve the desired frame rate.

This engine will move large amounts of graphic data at 30 frames per 
second. The addition of sound and the remainder of the game elements 
will push it down to 15 frames per second.

The engine will use 115K of RAM to operate (not including the compressed 
graphics) and will utilize double buffering and offer hardware scrolling 
of 1 byte (2 pixel) increment (this is working now).

A lot of work but hopefully the end result will be satisfying.

Nick Marentes