Well, I guess by now the jig is up... Having so far demonstrated a lack of imagination in the Retrochallenge 2015/01 event, I am falling back to something familiar. I am porting Fahrfall as an exercise in learning to program the Apple II. At least that lets me concentrate on learning Apple II software architecture and 6502 assembly language rather than toying with game design...?
Random Patterns
Almost any game needs a source of random numbers. The most obvious use of random numbers in Fahrfall is the generation of randomized platforms, but they are also used in the "game over" audio and for a few behind the scenes functions. Of course, computers really have no way to pick truly random numbers, so some technique must be used to generate "pseudo random" number sequences that are not easily predictable by humans.
There are several techniques available for generating "pseudo random" numbers. The one that I tend to use is a software implementation of a linear feedback shift register (LFSR). In the CoCo version of Fahrfall, I implemented a "Fibonacci" LFSR. This time I implemented a "Galois" LFSR because it seemed a bit easier for the 6502 to process. The code is so simple and fast, I may go back and reimplement a "Galois" LFSR for the CoCo version of Fahrfall as well!
Step By Step
I am using the low resolution graphics mode on the Apple II. This mode provides a broad array of colors while minimizing the amount of data required to paint a screen. The resolution is lower than the video mode used on the CoCo version of Fahrfall, but I think it is adequate to provide enjoyable gameplay.
The encoding of pixel data in the low resolution mode is a bit easier to wrap one's mind around than the encoding used for the other Apple II video modes, but it is still a bit odd. Sixteen colors are available and two pixels are encoded in a single byte -- so far, so good. What is weird is that the two pixels represented by a single byte are stacked vertically rather than horizontally, so the two pixels in a byte represent parts of different lines. Weirder still (at least to me), the most significant nibble of the byte represents the lower line.
In any case, this pairing of pixel data caused me to implement my earlier "moving platforms" code experiment using 24 line pairs rather than 48 separate lines. This code structure seemed a bit awkward, since I will likely want to process player inputs and do other things in between platform movements without having to duplicate code for odd and even platform locations. So, I refactored the code to handle 48 different platform positions and to plot the platforms with properly encoded pixel data.
Refactoring
Continuing along the same path, I did more refactoring of the remaining bits of my code. That code was developed organically as I initially toyed with the Apple II. Now that the code is going to be a game, it needs to adopt a structure conducive to that end. That means moving various bits of inline code into reusable subroutines, minimizing and/or removing duplicate code segments, changing labels here and there, etc. This also includes beating the overall structure of the code into a traditional game loop. As it now stands, the code forms a skeleton upon which I can hang the rest of Fahrfall.
Now that I've confirmed that I am working on a port of Fahrfall, it might make sense to move further coverage of this effort to the Fahrfall blog. I considered doing that, but that might be a bit confusing for folks following the Retrochallenge contest. I'll just keep the cover here for now. If the effort is a success, then I'll move further coverage to the Fahrfall blog later. So if you want to watch the progress of porting Fahrfall to the Apple II, then you just have to stay tuned!
No comments:
Post a Comment