[stella] WIP: Salmon Run: Asymmetrical Playfield

[bob.montgomery at thomson.com]

Hi Thom,

>The problem with dealing with precisely 22 lines of playfield data
>(including the top and bottom rows that shrink/grow depending on where
>we are in the smooth scroll), is that in order to scroll without doing
>excessive compares, I need not only some breathing room (to be able to
>generate 2 to 4 lines ahead of the screen), but i want to easily be
>able to constrain my counting using just an AND .....
>
>This pushes my memory constraints to 32 x 4 if I choose to do this, or
>am I missing something?

Well, obviously 32 x 4 bytes of RAM won't work on a stock cartridge.
You could either go to a Superchip design, or...

>i want to easily be able to constrain my counting using just an AND

Unless I'm missing something, you'll just need to drop this wish. ;)

I'd suggest using exactly 22 lines of playfield data and coding without
the easy count constraints and without the breathing room.  Or if the
breathing room is absolutely necessary, use 26 x 4 byte of RAM.  That's
pushing it, though.

Another option: store the river in RAM as a series of 22(+) bytes, one
for each row, each a lookup to a table of PF values.

This complicates your kernel, since you have to do something like this
between every row:
   ldx Index
   lda RiverRAM,X
   tax
   lda RiverLookupPF1,X
   sta PF1Temp
   lda RiverLookupPF2,X
   sta PF2Temp
   lda RiverLookupPF3,X
   sta PF3Temp
   lda RiverLookupPF4,X
   sta PF4Temp

and then your kernel would look something like this...

   ...
   lda PF1Temp
   sta PF1Temp
   lda PF2Temp
   sta PF2
   lda PF3Temp
   sta PF1
   lda PF4Temp
   sta PF2
   ...

Saves you cycles in the kernel and a ton of RAM, though it will make for
a messy kernel, since loading PFxTemp will probably have to be spread
over several lines, since you will be displaying sprites and an asym
playfield all the while.  Certainly doable, though. :)

Also limits you to 256 different river rows, but that's probably enough,
I would guess.

-bob