Subject: Re: [stella] Re: the big sprite|
From: Erik Mooney <emooney@xxxxxxxxxxxxxxxx>
Date: Mon, 6 Apr 1998 14:39:12 -0400 (EDT)
> 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!!