> >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/
