[Coco] getting graphics into CoCo games easier

[Steve Bjork]

Back in the days when I was creating games for the CoCo, I first 
created them used fcb data statements for the graphics data.
It wasn't long before the games were mostly data and took forever to 
assemble all the data with a little bit of code. So I redesigned my 
utilities to output pure binary data file that could be loaded in at 
runtime along with the much smaller assemble code file.

The key to making the graphics work was all sprites were address via 
a lookup table.  The code only need to know what sprite number it 
what to draw and it could find the graphics data by the information 
in the table loaded with all the graphics.

Later versions graphics utilities would not only include the address 
of the graphics data but the MMU settings for the data block of 
graphics and the controls of how long to display it and what the 
sprite would be.  (As in a player running to the right, there are 4 
to 6 sprite are needed to show that motion.)

If I can find the graphics utilities I'll try to get them running 
under the Rainbow IDE and the VCC system.  (But thiat is a big if 
because my main CoCo that I used to create my final games was stolen 
about 6 years and I don't know if I have any backups on floppies.

Should I find the code, the VCC under windows would make my old 
program run very, very fast!  (and no need to write a new version 
that run under windows.)

Steve (Rampage) Bjork

At 08:01 PM 1/19/2008, you wrote:

>One thing we've needed for years is a way to convert existing 
>graphics from a PC into sprites and bitmaps for use with CoCo games, etc.
>
>I could easily write a Projector-3 format driver that converts 
>whatever is on the graphics screen into a compressed .asm source 
>code file representing the image, as well as specific areas of the 
>image as a grid or single areas.  If a grid of a certain 
>width/height/size is chosen, a source code file would be created 
>with fcb's/fdb's/fqb's of the graphics data.  I know of ways to 
>automatically create the sprite masks, including a one-pixel black 
>bordered mask if that's desired.
>
>Again, you could take any kind of image, and if it's not a GIF, BMP, 
>or some other P-3 compatible format you can use a PC editor to turn 
>it into one, then move it to a virtual .dsk that P-3 (running in 
>M.E.S.S. or VCC) can access.  Load in the picture, and then choose 
><E>ncode and type .asm for the new extension and voila. That's what 
>I want it to do anyway.  A highlighter grid will appear on the 
>display where you can section off the area the sprites are in and 
>size them, etc. before saving to the source code file.
>
>I'm sure the .asm file could grow pretty large if I don't use some 
>kind of compression scheme, but the Rainbow IDE doesn't care how big 
>the files are and has no problem with crunching this kind of 
>stuff.  The idea is to make it easier to make CoCo games using 
>existing HQ graphics found all over the web, scanned in, hand drawn 
>from the PC, etc.
>
>I also almost forgot, does Chet Simpson's ImageMaster actually work 
>to create CoCo sprites in .asm source?