At 10:52 AM 2/12/2001 -0500, you wrote:
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.
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 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.
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
