Apparently, moving a (mostly) white object is as easy as I thought it was. My tool generated the 7 needs frames and they progressed nicely across the screen. The only tricky part is I need to turn an X value into two different values:
- Byte # in row
- Frame # to display
This was pretty easy (or so I thought, more on that below). Take X divide it by 7 and round down to get the byte # in the row. Take X mod 7 (i.e remainder) and you get the bit offset with in the byte which corresponds to the frame. I’m worried that math is also too much work to do every movement, so I generated and lookup table for X to Byte/Bit but it’s 2 bytes for each column so that’s another 560 bytes for lookup tables. Remember we’re working with things on the order of magnitude of 32-48k. So that’s a total of 944 bytes for lookups, almost a whole K. I’ll need to figure out which is better doing some testing, for now lookup table it is.
We’re good, right? For non-white objects, no so much:
Reading further in the book (yes, I end up working ahead when perhaps I shouldn’t), looks like I need to handle odd/even frames for odd/even bytes differently. Oh, the fun never ends.
Which, when I think about it, makes total sense. Here is the first frame as a bitmap:
And here is the second:
The first one is all on green pixels (the G at the bottom) and the second is all on violet pixels (the V). I could just move two bit at a time, the the second (displayed) frame would be:
So, it’s back to green like I want. That seems cheap like a 2-bit suit (Ok, I had to). But, it does feel like cheating. Maybe that is what I’ll need to do and what games do and we don’t know it, but I don’t think so.
Time to read more and see, looks like the parts I’ve moved through so far at the “easy parts”. Figures.