On Mon, 22 Jul 2002 00:17:57 +0200, you wrote:
>No, to tell the truth, I've some more concerns about
>utilizing this. Except from the ROM, you'd have either
>to cope with some not to underestimate overhead during
>the kernel, or you've to waste a ton of RAM, too.
>
>Consider this:
>
>STA HMCLR
>LDA [SpriteHMove]
>STA HMP0
>JMP [SpritePosAddr] 'jump to any of the Label#
>addresses
>
>For each of your sprites you need at least two
>additional bytes, one for an HMOVE table, one for the
>pointer. Most like you'll need even two bytes for the
>pointer.
But what if those locations ARE the stored positions? Same concept as to
how River Raid stores pointers to each of the score digit graphics and
never actually stores the score. There's enough time offscreen to
calculate the X position from the pointer and HMOVE table, do whatever
game mechanics you need, and convert back to pointer/HMOVE.
Or you could calculate such during the kernel - it should only take about
four lookups and stores, which is still much less time than wasting an
entire scanline in a display loop. And you won't be repositioning the
sprite *every* scanline - more like every eight or so for a useful game.
>You need to determine *when* to reposition your sprite.
You just mean when to jump into this routine, as if you were writing
Berzerk? That shouldn't be hard for us :)
>A scrolling text with sprites. Consider this:
>
>If the chars of the scroller would move along one as-
>big-as-possible sine-wave, You'd probably never have
>more than 2(!) sprites horizontally overlapping at
>once... Any takers? ;-)
Not me :)
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
