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 >>monochrome. > >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 player. 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 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!!
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [stella] Re: the big sprite, Eckhard Stolberg | Thread | Re: [stella] Re: the big sprite, Eckhard Stolberg |
Re: [stella] Re: the big sprite, Eckhard Stolberg | Date | [stella] Congratulations to Piero, David C. Schweinsber |
Month |