I took some time on Saturday to get some platforms onto the screen. This turned-out to be simpler than I thought. I started with just a single, full-width platform scrolling continuously from the bottom to the top and then repeating. From there I progressed to using the LFSR data to randomize the platform pattern -- I'll talk about that a bit below. Then I moved to having three independent platforms on the screen at a time. I was so pleased with myself that I posted a video!
LFSR Data Anomalies
The LFSR is working great for my (pseudo-)random numbers. But as I noted in the video, it was possible to get either empty platforms or full-width "sweeper" platforms. Today I played around with correcting that.
The platform data is simply a bitmask, with each bit representing a corresponding portion of a platform's span. I started checking for "all ones" values in order to prevent the "sweepers". A full-width platform would be impossible to pass, resulting in "Game Over". I played with it a bit, and settled on simply substituting a default platform data value for any "all ones" values I found.
The nature of an LFSR is such that you can't really get a completely zero value for the LFSR. But my LFSR is 16-bits wide, and my platform data is only 8-bits wide. At first I was taking only half of the LFSR value for my platform data, and half an LFSR can be zero. I even observed an empty platform scroll up the screen in "real life" -- I should be a tester! :-) Anyway, now I also check for an "all zeroes" value and substitute the default platform data value in that case as well.
The platform data was already as random as the LFSR could make it, but I wasn't totally happy with how the platforms were looking. It seemed like there would be runs of too many gaps between platforms, or not enough, or whatnot -- all that could just be my imagination too. Anyway, I decided to experiment a bit, particularly with XORing the LFSR data with...whatever. Anyway, I settled on XORing the two halves of the LFSR data together, then applying the tests for "all ones" and "all zeroes" as described above. I don't know for sure if this is any better than before, but it feels better in the seat of my pants!
Just A Little Swizzle...
I wasn't entirely happy with the way the scroll planes were moving. They had been moving upward one position every 2, 4, 8, or 16 frames, depending on the plane. The code for handling this was also looking a bit unwieldy as well, at least for the "every 16" case. So, I refactored...
I changed from the 2-4-8-16 factors to factors of 2-4-6-8. The introduction of the "every 6" case required an independent counter, since 6 isn't a power of 2 like the rest of them. Anyway, I think the results looks a bit better overall -- less jerky and more quick. It does seem to lose a bit of the feeling of depth, but I think it is still alright. Plus, the code seems a lot cleaner too.
More To Come
I did that scroll plane swizzle after shooting the video above, so I suppose you will have to wait a bit to see it. I imagine that the next progress report is just days away!
Also, I have a few topics that relate more to the background of the project rather than to the progress of the project itself. For the benefit of the technically curious among us, I want to provide a bit more information about the CoCo, what tools I'm using, etc. I'll try to meter them out, and continue to intersperse them with some progress reports.
Watch this space!