> Colour changes would be possible, but they would be 11 cycles, since
> we have to change colour for both player graphics. The ball and the
Right, forgot about that.
> playfield thing would be a bit difficult, since conditional branches
> would mess up the timing. Also, since the players are moveable, the
> writes to PFx or ENABL would occur at different cycles in the scanline.
> That means graphics left of the player would be affected one line
> earlier than graphics right of the player, which would look a bit
> jerky.
Alright, playfield is out. The ball is still possible, even without
branching. Assuming Y is used as the counter during the draw-sprite
routine, and the stack has been preset to ENABL:
TYA
SBC BallY
AND #$F8 ;this is a constant for ball height - must be multiple of2
PHP
PLA ;to reset the stack pointer
14 cycles, no branching, to do the ball... 15 if you replace the constant
with a variable ball height. *Barely* enough to do that, the wide sprite,
and colors for said sprite - you said there were 28 cycles free at
double-resolution. (you said there were only 22 contiguous and six
separate - the PLA can go in the six separate, and the other 22 are
filled.)
As for display inaccuracy, I don't think it's a concern... given the very
muddy collision-detection of the real MK games, I hardly think that
misplacing the ball or the color by one scanline is a concern.
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
Don't post pirate BINs to Stellalist. Be a programmer, not a pirate.
Write the best game, win framed autographs of famous Atari alumni!!
