[stella] WIP: Salmon Run: Asymmetrical Playfield

[Thom Cherryhomes]

yeah, after thinking it all over, I'm currently in the process of
refactoring the kernel considerably. This has been an amazing learning
experience (and the reason I unrolled the loop was to make it work so
i could test ideas (because I was running out of registers), but I
know now what I need to do.)

Yeah, I was hoping to leave PF0 alone so that I can gain a few cycles. :-D

the whole point is that the entire river is randomly generated (with a
timer determining the end of the stage.), i will add code to ramp up
the difficulty based on the difficulty switches and the level.

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?

-Thom


On 3/14/07, bob.montgomery at thomson.com <bob.montgomery at thomson.com> wrote:
> 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
>
> _______________________________________________
> Stella mailing list
> Stella at atari2600.org
> http://atari2600.org/mailman/listinfo/stella
>