[Coco] getting graphics into CoCo games easier

[Robert Gault]

Roger Taylor 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?
> 
> 

That would be a useful addition to Projector. In general, the asm 
listing should be a binary representation of the image and the game 
program should provide a means of converting the source into normal 
data. For example, 16 color data could be presented as:

FXB  0  0  0  0  0  0  0
FXB  0  0  0 13  0  0  0
FXB  0  0 13 11 13  0  0
FXB  0 13 11 11 11 13  0
FXB  0 13 11 11 11 13  0
FXB  0  0 13 11 13  0  0
FXB  0  0  0 13  0  0  0
FXB  0  0  0  0  0  0  0

Where X would indicate the number of bits per pixel in the above data, 
the value would be the palette color, and the software would 
automatically convert the palette value to the necessary 4 bit patterns.
This is easy for two color screens as %nnnnnnnn notation can be used. 
Current assemblers would not like or handle the above notation.

The above would mean you could "draw" in your source code file and not 
have to use a graphics package to create the images.