[Coco] Impossibly-fast CoCo 3 sprites :) (Roger Taylor)
Chris Lomont
cocoarch at lomont.org
Sun Feb 10 23:08:54 EST 2008
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
More information about the Coco
mailing list