[stella] 6-digit score WITH background colour change (!!)

["Andrew Davie" <adavie@xxxxxxxxxxxxx>]

This isn't actually all that tricky, but here's an example using the free
cycles in the 6-digit double-height score routine to change the background
colour.  Excuse the formatting, it's just a testbed.  Looks OK; might use it
for Qb.
Cheers
A
--
 _  _  _| _ _        _| _    * _                               _  ,
(_|| )(_|( (/_\/\/  (_|(_|\/(_(/_                           ,~' L_|\
                                                         ,-'        \
see my Museum of Soviet Calculators at                  (            \
http://www.taswegian.com/MOSCOW/soviet.html              \    __     /
                                                          L,~'  "\__/
                                                              @--> v

----- Original Message -----
From: "Erik Mooney" <emooney@xxxxxxxxxxxxxxxx>
To: <stella@xxxxxxxxxxx>
Sent: Tuesday, February 13, 2001 4:37 AM
Subject: Re: [stella] pseudoplayers


> > >You'll want to store the offsets as the change from the previous line,
> > >rather than an absolute value.  That way, on each scanline, you can
just
> > >read the byte and dump it into HMM0 or HMM1.  (You'll also store the
> > >offset in the upper 4 bits of the byte in this case.)  That does also
keep
> > >the ability to skew the object to be more than 8 pixels wide, like you
> > >have there.
> >
> > Can the bytes really go directly into HMM0 and HMM1, though?  You are
> > talking about using the offsets synonymously to the "fine" control on
the
> > movement?
> >
> > Because there are only 16 coarse positions, and +/-8 on the fine
control,
> > at any decimal representation of the missile position it's possible that
> > the offset will require changing the coarse position value, not just the
> > fine control.
>
> The bytes can go directly into HMM0 and HMM1.  The fine control gives an
> object a +/- from its previous location.  It's not an absolute from the
> coarse position -- it's a modification of whatever position the object
> currently has.
>
> (I think; it's been too long since I did any actual 2600 programming.
> Someone will correct me if I'm wrong, I'm sure :) )
>
> And there's more than 16 coarse positions; in fact, there's a coarse
> position every 3 pixels (one cycle.)  It's just that the standard
> positioning loop takes 5 cycles (15 pixels) per loop, which makes it look
> like RESxx can only position an object every 15 pixels, and that's how
> it's usually used.
>
> > I was looking at the offsets simply as a way to describe the shape, and
I'd
> > have to calculate the fine/coarse line by line or precalculate that
frame
> > by frame and store the results into an additional table in RAM.
>
> You don't have to do a new positioning loop/RESMx every line, which is
> good because you can't :)  (It is possible to write some amazingly tricky
> code to position two objects on the same line, but you couldn't possibly
> do a playfield as well.)
>
> > >You wouldn't have to, if your code in the kernel can take the negative
of
> > >an upper nibble quickly enough.  I think doing XOR #$F0 / CLC / ADC
#$10
> > >will work, and you may be able to skip the CLC if some code immediately
> > >previous (usually a compare) leaves the carry in a known state.
> >
> > I'm still optimistic that this game is the kind of thing that could
> > probably fit in 2K in a pinch, so that I should have some room to store
> > this kind of thing rather than calculating it on the fly.
> >
> > RAM, however, is going to be tight, though.  I've already done some
> > estimating.
>
> Adjusting to limited RAM on the 2600 is one of the hardest problems for
> programmers who are used to making big arrays and data structures to hold
> stuff, since that's how they were taught, either from books or classes.
>
> Also, there really is no reason to try and keep any images to 2k other
> than the challenge of it, and I think the rest of the VCS is challenging
> enough already.  The space for internet transmission of a 4k image (even
> its source code) is immaterial; 4k carts are just as cheap as 2k; and it
> takes maybe 3 extra seconds to load onto a Supercharger for playing or
> testing.
>
>
> -
> Archives (includes files) at http://www.biglist.com/lists/stella/archives/
> Unsub & more at http://www.biglist.com/lists/stella/
>

Attachment: test.asm
Description: Binary data

Attachment: test.bin
Description: Binary data