Re: [stella] Collaboration

Subject: Re: [stella] Collaboration
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Fri, 17 Jan 2003 22:10:37 -0800
At 10:53 PM 1/17/2003 +0100, you wrote:
Hm, that might be an option, though I think a ball would be a *lot* more
flexible. 1 or 2 pixel wide objects aren't possible then anymore.

That doesn't bother me.

With "every row", I hope you mean every row *between* the tombstones.
Right? ;-)


The main problem here will be that we already have 4 (maybe 3) complete
2L kernels (~130 bytes/each), each including two (one for the tombstone
rows and one for the space between) complete kernels. That makes eight 2L
kernel codes already [~1000 bytes). Your idea would raise that number up
to 20(!) kernels (~2600 bytes).

Okay, then let's make a plan.

For the time being let's just have one ball on screen at once. That ball will either go across the entire screen (barrier mode) or just one of the designated grenade lines.

When in grenade mode, we'll be able to load a custom color. The width and position would be determined outside the kernel.) How that will probably work is the safe-zone will always colorize on all grenade lines and normally that would be set to the same color as the previous scanlines but would all switch when another color is written to that RAM locatiion--because they would all be using the same repeated general purpose kernel.

Given those limitations can't we do all the calculations with no more kernels than you are planning?

If you don't care for the color gradients, that's very easy to code.

I don't mind the gradients on the barrier or the safe zones enough to lose cycles trying to get rid of them.

The biggest problem for me now is to avoid those nasty tearing effects
that happen when you change a register while the object is drawn.

I thought you already solved that. Ouch.

four object writes within two lines that have to happen nearly
completely outside the visible screen this is not an easy task.

Like I said, you can cheat the screen width inward by one additional playfield pixel on each end as a last resort. But it looks like we're going to need more kernels with different write timings keyed to the X positions of the objects. I was expecting that.

Therefore it's IMO a MUST to avoid them (even if we have to give up the
single pixel Y-positioning of the zombies).

I was already prepared to give up the single pixel Y-positioning of the zombies a long time ago. If it saves you the time, please consider that a final decision in order to avoid the tearing problems.

This will just make the zombies move a little jerky on the Y axis but I think the walk cycle animation will help mask it.

Archives (includes files) at
Unsub & more at

Current Thread