Hi Erik!
>>I can tell you, why it must flicker that much.
>>The reason is actually simple: Repositioning an object
>>takes a whole scannline.
>Takes a ton of ROM, but saves gobs of CPU time for
sprite positioning.
>I've been trying to find time to code this in a proof-
of-concept for, oh,
>about three years now. :)
I'm sure that it'll work. And I admire the brave
concept. Only problem is, that after implementing it,
you're most likely to be braindead ;-)
Hm... I'd need only 9 kernel parts, since I've only 128
horizontal positions.
Anyone knowing what happened to the programmer of
Galaxian?
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.
And it's not only the RAM to take into consideration.
You've to consider some overhead as well:
You need to adjust the HMOVE value and the pointer from
one sprite to the next.
You need to determine *when* to reposition your sprite.
I think it might do for a cool demo though ;-)
Apropos demo, here's one idea I have:
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? ;-)
Greetings,
Manuel
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
