[Coco] getting graphics into CoCo games easier

[Roger Taylor]

At 08:23 AM 1/20/2008, you wrote:
>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.
>
>--


Great idea.  Actually, I'm drawing my sprites this way right now, 
using CCASM's FQB (form quad byte psuedo op)... fqb $FF0000FF  where 
0-F is the color.

Just a random example of a what I'd like to make P-3 produce for the 
.asm data.  I find it also quicker and easier to pad sprites+mask to 
256 or 512 bytes.  You can load reg.A with the sprite #, clear reg.B, 
shift A to the left if needed, add the MSB of what CPU page the 
sprites start, etc. to save a few cycles.

fqb $FF0000FF
fqb $F000000F
fqb $F000000F
fqb $FF0000FF
fqb $FFF00FFF
fqb $FFF00FFF
fqb $FFFFFFFF