[stella] WIP: Salmon Run: Asymmetrical Playfield

[Thom Cherryhomes]

am I hallucinating, or is the kernel in river raid doing an hmove on
every scan line?

-Thom


On 3/14/07, Thom Cherryhomes <thom.cherryhomes at gmail.com> wrote:
> I grabbed the disassembly of River Raid off Stella.. holy crap, the
> playfield generation code is ingenious! I will study this code for at
> least the rest of the day to get a new technique. :-) Thanks, Thomas!
>
> -Thom
>
>
> On 3/14/07, Thom Cherryhomes <thom.cherryhomes at gmail.com> wrote:
> > okay, I'm going to do some thinking and experimenting.... i will keep
> > you guys posted.. Thanks so much for the help.
> >
> > This is proving to be a challenge..hehe...
> >
> > -Thom
> >
> >
> > On 3/14/07, bob.montgomery at thomson.com <bob.montgomery at thomson.com> wrote:
> > > 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
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Stella mailing list
> > > Stella at atari2600.org
> > > http://atari2600.org/mailman/listinfo/stella
> > >
> >
>