Subject: [stella] Inspired by cybergoth|
From: "Roger Williams" <mer02@xxxxxxxxxxxxx>
Date: Tue, 16 Apr 2002 20:11:51 -0700
Since things have been quiet, I figured I'd let on what
I'm working on at the moment. With luck, y'all may see
a demo in a month or two.
For a lot of ideas in my mind (and a few things I've seen
others pondering) we need something like a quasi-generic
multi-object kernal. I'm interested in rotations, which
means I can't do the usual tricks to enforce vertical
separation. I need something fully generic no matter how
"crappy" it looks; motion and action will have to distract
the player from the "electronic noise" of flicker artifacts.
What I'm working on is a kernal which does the following:
1. Player 1, both missiles, and symmetric playfield
2. As many multiplexed copies of player 0 as you can stand
3. Very minimal RAM use
4. Hardly any prep code outside of the kernal
I can hear the veterans thinking "here's another newbie
who doesn't realize how many cycles this is all gonna take."
But it does actually appear feasible.
Cybergoth got me thinking with his routine that just does
two passes of the bubble sort regardless of whether the
file is sorted yet or not. How about sorting the sprite
list DURING THE KERNAL? Hmmmmm. Each pass through the
kernal amounts to one pass through the sprite list.
This has the interesting effect that the sort routine ALSO
takes care of the intelligent flicker automagically. If a
sprite is skipped without being drawn on, you swap it down
with the previous one. If sprites are interfering, they
will be sorted around one another continually. To do this,
it's necessary to do exactly one pass per screen, which means
that an object introduced at the wrong end of the file will
make everything blink for as many frames as you have objects;
still, if there is a lot of motion going on, I think this will
be easily passed off as ripple or "interference" just as the
smart flicker is.
This allows me to eliminate a whole bunch of data structures
and control logic. The flipside is that lines are still only
76 cycles long and it takes quite a bit more than that to
advance to the next sprite, so I will be using a state
machine to spread the transfer calculations out over several
lines. This will make each multiplex sprite several lines
higher than it "really is" for flicker purposes. But it will
be a 2-line kernal and could be coded to allow 1-pixel
vertical resolution for all objects, with no external sort.
I have about half the code half-written :-) and it looks like
it will take about four extra (2-scanline) lines, making the
typical square player about double-height for flicker purposes.
I have a very kewl and persuasive flowchart which I would post
if I hadn't used Microsoft Publisher to draw it.
The only code outside of the kernal presets all the non-
multiplexed players and the first multiplexed player a la
Combat, and at the end of the kernal must cycle through any
remaining multiplex sprites in the list (that the screen
logic didn't reach for some reason) and swap them if they
should have been within the screen boundary. This should
leave at least 2000 cycles free between frames for other use.
RAM use is shaping up to be about 10 bytes for pointers, temp,
and cache vars for the sorting code; 18 bytes or so for the
nonmultiplexed players and playfield pointers; and 5 bytes
for each multiplexed copy of P0. The list is sorted indirectly
so 2 of those bytes are X and Y positions which can double as
game position data, since objects don't have to move around
in the list. (Two more bytes point to a descriptor which
specifies the height, color, and bitmap location; and the last
byte belongs to the sort list.)
I must say that I wasn't optimistic about this when I started
playing around with the idea but it is starting to get really
interesting. The final product will have a lot of compromises
but I think it will be a different and very interesting set
of compromises compared to solutions we have seen elsewhere.