[stella] Inspired by cybergoth

["Roger Williams" <mer02@xxxxxxxxxxxxx>]

Hi all...

 

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.

 

--Roger Williams