[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