Re: [stella] Re: the big sprite

Subject: Re: [stella] Re: the big sprite
From: emooney@xxxxxxxxxxxxxxxx (Erik Mooney)
Date: Sun, 05 Apr 1998 17:17:12 GMT
>>Also, it might be preferable to drop the sprites down to 40 pixels wide,
>>and use the sixth byte for color, so the characters don't have to be
>I'm not sure whether to use bigger sprites or colour. I think
>we need to try it out and see which one looks better.

At double-resolution, as you said, there'd be enough cycles to do both 48
pixels wide and a color.  Although the color would make it 7 bytes per
scanline, so we could only fit 256 / 7 = 37 rows, which'd be 74 pixels high
at double-resolution.  We're down to slightly over a third of the screen
height for the character height, which is somewhat smaller than the real MK
games.  Still much larger than Pitfall Harry, Pac-man, or Sir Square
(Adventure) though :)

>I think, I need to learn how to make myself clear. :-)
>With collumns I meant the 6 bytes, which make up the sprite.
>For example, if we have graphics for a high and a low punch
>to the right with 4 animation frames each, then only the 3 or
>4 bytes on the right side would change. The 2 or 3 bytes on 
>the left might be the same in all frames. If we use a table,
>that says which collumn to use in what animation frame, and
>if we set up the sprite pointers accordingly at the beginning
>of a displayed frame, we might be able to fit in enough data
>for a middle punch animation in the same 2kb bank.

Oh, the columns... I was thinking rows for some reason - you'd have
graphics for the legs of the player that'd remain the same, but you'd have
different graphics for the top half for different punches... and I didn't
see where there'd be time to switch the pointers to the lower half of the

Your method could also compress even farther - the left few columns, plus
the color "column", might remain the same through the 10 frames of the
high-punch animation itself, and that could be exploited.  And, with this,
there'd be no need to keep one frame's data within a page, allowing the
characters to get back to their proposed 50-pixel height. (actually, at 51
pixels, five columns would fit very comfortably within one page)

(There wouldn't be a cycle penalty if some of the pointers point to
different pages, right?  As long as we never index across a page boundary?)

>BTW, in the double scanline version there are 28 cycles
>left to spare for both lines together, although you only
>get 22 of them in a row.

That's enough to load/store a color (8 cycles), and maybe even check and
turn on or off the ball or do a little bit of playfield.  The two-sprite
kernel wouldn't have support for projectiles - perhaps the ball could be
used for that?

Archives (includes files) at
Unsub & more at
Don't post pirate BINs to Stellalist.  Be a programmer, not a pirate.
Write the best game, win framed autographs of famous Atari alumni!!

Current Thread