Re: [stella] Collaboration

Subject: Re: [stella] Collaboration
From: Glenn Saunders <cybpunks2@xxxxxxxxxxxxx>
Date: Sat, 18 Jan 2003 01:10:56 -0800
At 09:00 AM 1/18/2003 +0100, you wrote:
That means, that you don't care if in a grenade line the safe zone
changes it's color too. Right?


Yes, that should work.

Now we're getting somewhere.

That's not the big problem, because those writes only take three cycles.

Every little bit counts. I liked the efficiency of loading PF0 once at the top of the kernel and forgetting about it as a timesaver. That was a big reason for using the mirrored playfield which most playfield bitmaps don't use.

No, that also wouldn't work due to the grouping that I described in my
reply to Chris.

I WAS counting on VDEL to make it so that the write to at least one of the sprites would not have to happen at a precise time. Don't know if that's really possible or not in this kernel, but that would help the tearing issue because you'd be left with a matrix of 4 possible combinations for the time-critical car and one of the missiles (both in left side, both in right side, car in left and missile in right, missile in left and car in right).

Overall, only 3 objects could potentially bunch up since for any given scanline pair only one missile would be altered.

Ultimately I think some mid-screen kernel branching is going to be necessary because the bunching would need different kernels for alternating scanline pairs.

Getting meaningful processing on the playfield scanline was my big problem. By the time I calculated something, time was over and I couldn't even store to a temp variable to be able to pick up where I left off.

If you perform your branching during the grenade zones, then I can work the AI so that the two missiles will only cross if they are at least one tombstone row apart, vertically.

That way you'd never have all 4 objects on the same scanline AND close together horizontally at once.

I don't want to limit he AI but that might work. Hopefully it wouldn't be too exploitable. Remember that the general movement pattern for the sprites is a zig-zag diagonal AND their objective is to reach opposite ends of the screen, so they wouldn't likely be on the same scanlines AND close together for too long.

Also, as the screen gets full of tombstones the chances of lining up all the sprites will be minimized because there are going to be tombstones blocking such an alignment, plus, if I never allow the sprites to actually overlap that might help too.

I'm still quite convinced that the tearing problem is avoidable. But the
solution might eat some precious cycles (plus a lot of extra ROM) that
you might rather use for other things (coloring, balls, wider PF/safe

Feel free to eat ROM space for the time-being. I have a feeling that if I implement all my game ideas (with just the basic graphics and animation elements) the game will probably have 1K or so left over. It's really just a tweaked 2K game concept.

How big is it so far?

You could write a very simple single-zombie kernel, implement some
animations and AI movement patterns and then find out how it looks.

I'm quite confident that the coarser movement will look okay.

The sooner you find the magic solution to the tearing problem the sooner I can show the list a demo ;)

---------------------------------------------------------------------------------------------- Archives (includes files) at Unsub & more at

Current Thread