[stella] WIP: Salmon Run: Asymmetrical Playfield

[bob.montgomery at thomson.com]

Hi Thom,

>....quite honestly it seems that even if I found a way to make a nice
>consistent algorithm, i would have to do it 8 times, times 20 lines,
>and assuming that i would have to unroll the loops, I would
>essentially run out of ROM space AND cycles before I even get to
>drawing the fish or the enemies....
>
>i'm curious to see if there could be ANY possibility...... to make an
>asymmetrical playfield, without totally bursting through the basic
>laws of 2600 physics.......... ugh... it seems the only saving
>grace... that I am drawing eight lines per river change, is also going
>to bite me in the ass.

A few suggestions: first, like Michael said, put your kernel in a loop!

Second, you might want to consider only having PF1 and PF2 be
asymmetrical.  This is used in a lot of games, especially ones that have
an asymmetrical playfield: Crystal Castles, Centipede, Millipede, Dig
Dug, Mr. Do!, Pengo, etc.  Either don't change PF0 at all during the
kernel or have it be symmetrical - so you don't have to write to PF0
every line.

Third.  Assuming you take my second suggestion, you have 20 lines of
playfield data, times 4 bytes per line (PF1 x 2, PF2 x 2).  Maybe put
that in RAM?  It's 80 bytes, which is a lot, but not so many that it
isn't possible.  Than you can do all your manipulation outside the
kernel, either bit-shifting or some kind of random-river-generator (like
in River Raid, or like Chris W did in Night Rider).

The other possibility is: how many rivers do you plan on, and how long
are they?  You could store them all in ROM.  Assuming you only use
PF1&PF2, each screen is 80 bytes, so a 10-screens-tall river would fit
in under 1K.  With 32K to work with you could fit at least 300 screens
worth of river in.  :D

-bob