[Coco] Impossibly-fast CoCo 3 sprites :) (Roger Taylor)

[Chris Lomont]

I have some simple CoCo3 assembly routines on my website www.lomont.org. 
There is an asm mandelbrot program among other things.


Andrew wrote:
> Roger,
>
> I have been following your progress on this game, and your 
> descriptions of the fast sprite routines. However, I am not sure as to 
> how your entire loop is run - I assume it is something like:
>
> 1. draw background (static background)
> 2. get input
> 3. wait for vbl
> 4. erase sprites (quickly!) at last position
> 5. move sprites (to new position)
> 6. draw sprites (mary, trees, bees, etc) at new position
> 7. loop to step 2
>
> My main question is "what is happening in step 4"? Based on your 
> descriptions of not being able to do animation, etc - it seems like 
> you are XORing the sprites to the screen? That way, you get the speed 
> you need, without having to resort to a slow buffer copy of the 
> background image during the vertical blank. Provided you can get the 
> sprites erased and replotted in time during the vbl, there wouldn't be 
> any flickering.
>
> You noted that you can't do animation, though? Not within a sprite, 
> certainly, but if you have up to 64 sprites, each "frame" could have a 
> different sprite plotted (ie, just change the offsets into the sprite 
> table appropriately?). Am I understanding this correctly?
>
> Is it only speed and/or memory limitations (or something else equally 
> valid - like not having to mess with MMU coding) that is keeping you 
> from doing bufferring of the background (ie, simply grab the 
> background and redraw it over the video buffer during VBL to erase all 
> sprites)? I am just curious on the time hit/constraints.
>
> Something else - is the Mary sprite one large sprite, or is she made 
> up of multiple smaller sprites? I know on the NES, sprites were made 
> using multiple 8x8 sub-sprites. Can you gain more speed by limiting 
> the sprite size (width, mainly) to byte or word multiples? I know on 
> the PC this is something you can do (but it may be because of the 
> 80x86 architecture).
>
> As far as the routines are concerned - are you going to release any of 
> the code (not necessarily the game code, but the sprite routines - or 
> at least a tutorial on how to do high-speed CoCo 3 graphics coding)? I 
> have yet to see a tutorial or anything on how to really do proper CoCo 
> 3 graphics programming in assembler - before the Rainbow went under, 
> there were tons of articles on CoCo 2 graphics, but hardly anything 
> about the CoCo 3.
>
> Lastly - are you going to do any other arcade style games with the 
> routines? I know you have your new gems game coming out - but what 
> about something like Robotron - or to be really ambitious, a SmashTV 
> clone? Granted, it would have to be scaled down - but something fun 
> could be done (oooh - how about a CoCo 3 Reactoid remake? How about 
> Canyon Climber?).
>
> -- Andrew L. Ayers
>    Glendale, Arizona
>
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco


-- 
-------------------------
Chris Lomont
http://www.lomont.org