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?
yep.
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
zones...).
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 http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
