Re: [stella] Star Fire - Return of the Starfield ?!?

Subject: Re: [stella] Star Fire - Return of the Starfield ?!?
From: Manuel Polik <cybergoth@xxxxxxxx>
Date: Mon, 22 Jul 2002 00:17:57 +0200
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 

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:

LDA [SpriteHMove]
JMP [SpritePosAddr]  'jump to any of the Label# 

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 

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? ;-)


Archives (includes files) at
Unsub & more at

Current Thread