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

[Roger Taylor]

At 09:45 AM 2/6/2008, you 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.

There is sprite-cycled animation in the Mary game.  I use two 
vertical syncs per screen frame to erase or redraw everything in a 
way to handle flicker and speed.  Since the game has some very CPU 
intensive background music which doesn't stop for anything, the main 
code has to do all of that drawing in a special way that ended up 
being 1) the critters are plotted directly since they occupy almost 
all of their sprite size, 2) they are erased by clearing the 
background completely since color #0 is sky blue, 3) the trees cannot 
all be drawing during one sync so I draw Mary's side of the screen 
during sync #1, and the other trees on the 2nd sync.  If Mary runs 
across the screen, the trees are drawn in the other order, Mary's 
side first.  Since the critters can corrupt anything they touch, I 
limited their height to just below the clouds, and since the trees 
are redrawn on each screen frame, you don't ever see the tiny 
portions of the trees that get erased sometimes.  Mary is OR'ed to 
the screen and uses colors $1,$3,$7,$F and when mixed with the trees, 
still yields the same colors.  The trees were color coded to mix with 
Mary without showing.

There is no single XOR instruction on the 6809.  It takes three 
instructions to OR some data onto the screen.  The 6309 can do direct 
EOR'ing (XOR'ing) and I agree it is cool and fast.  I'm sure that 
sprite data can be set up to reduce the overhead to allow a quick XOR 
onto the screen and another XOR to restore the background, but I 
haven't tried this yet.  The fastest method I know of right now is 
opcoded sprites which optimally writes only the visible portions to 
the screen, directly, byte for byte.

The erase procedure in the Jeweled game is what Steve Bjork used in 
his games, to restore the sprite area from a source backdrop 
image.  This is a very quick spaghetti coded routine in my game with 
no loops within each sprite.



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

Yes, the sprite coordinates are saved in the sprite information table.




>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.

For each sprite being erased, I quickly (2 instructions) map in the 2 
contiguous 8k blocks from the background screen, copy the bg, and 
repeat for each sprite, then I restore the MMU to map my game code 
back in.  All MMU routines are outside of this 16k workspace.  The 
32k destination/writing/workscreen is always at $8000 and no MMU bank 
switching is needed since it's always switched in.




>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).

Single array sprites.  In the Jeweled game, the fastest sprite mode 
I've witnessed which is amazing for 64 jewel sprites, is to directly 
plot using no masking, only the visible sprite bytes.  If the sprites 
are rough-edged on purpose so that the plotter can deal with bytes 
and words (2 colors or 4 colors side-by-side), it would work best, 
but since I have one-pixel black borders around the jewels and they 
are also not rough-edges, I have to mask some of the bytes, but all 
of this is computed automatically in the sprite-to-opcode generator, 
once at the start of the game.





>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.

Yes, I plan to eventually post on my site a game engine project for 
the Rainbow IDE.  One could take the project and build new games 
pretty quick if they can program in assembly and realize what's going 
on and what is expected.


>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?).

To be honest, and I'm not bragging, but I can write almost anything 
for the PC or CoCo, games or apps, all in assembly.  I'm what some 
would call a power coder, working fast, usually efficient, getting a 
lot done in a short time, getting an idea and making it work... 
Forcing it to work.  It's a computer -- I'm a human.  I'll win.
The ideas are endless and even though I can't act on request from one 
or two people, I'm trying to consider things that everybody would 
like, so expect to see a spectrum of games that *should* 
amaze...  Hey, Rainbow ---- spectrum... get it?  :)

My pending "Agent C" adventure game can now be built much quicker and 
I'll probably resume that shortly.  Such a game would be 90% data and 
I've now got a way to compile it all in one pass from the Rainbow 
IDE... actually Projector-3 is used to preconvert some graphics.