Several Commodore 64 games use color bars to achieve the illusion of a moving landscape. Even other platforms such as the Amiga use this approach quite often on games. Horizontal bars usually alternating two different colours are used. As long as each bar moves towards you, it gets bigger and bigger, giving the illusion of a “3D” scroller, or prospective scroller if you prefer.
One of the oldest games using such an effect is “Buck Rogers”.
If you look at that picture, you can easily see that the height of the bars is carefully choosen so that they can provide a 3D effect illusion. Bars become bigger and bigger as long as they get closer to the player. And bars near the mountains move more slowly than bars near the ship. So, the landscape is scrolling taking perspective into account.
Other Commodore 64 titles use such a technique, both racing games and space shoot-’em-up. Some examples follow.
I have not studied the code of the games, but I think Buck Rogers uses programmable characters to make the colour bars. This approach makes things easier to program (and that’s what we will be later using on this post), but clearly restricts at some degree the use of programmable characters for other graphics elements. In facts, as far as I am concerned, Buck Rogers seems to be using only sprites to create moving objects, leaving programmable characters to be used for the bars, without having to bother with raster splits for the color bars themselves.
On Outrun and the Space Harrier titles, the background color is changed more times on each frame, so that raster bars are created. This provides for a cheap way of representing a 3D effect, leaving programmable characters free to be used for the graphics. As a matter of fact, Space Harrier 2 uses both programmable characters and hardware sprites for graphics objects. Using characters for the color bars would have caused clashing problems with the graphical objects made up of characters – that’s why they used raster splits.
Now, if you are interested on reproducing a similar effect on your Commodore 64, I have coded some BASIC programs that deal with prospective colour bars. I have used programmable characters as I think they are the only viable way for such effects in BASIC.
DOWNLOAD: Commodore 64 BASIC prospective scroller
There are three programs in the above .d64 image.
Be sure to test these programs on a stock Commodore 64 computer with no cartridge inserted, as some cartridges may affect the timing of these routines and cause flickering.
The first program (p.scroll.slow) uses simple POKE instructions to make the movement. Some bytes of the programmable characters are changed over and over, and the VIC-II chip takes care of updating all the characters on the screen. The technique used is quite similar to that of my “scrolling chessboard programs” (please see the programming section of this blog).
Perspective is somewhat taken into account by creating four color bars of different sizes. The farthest color bar from the observer is only one character high. The next bar, which is closer to the observer, is two characters high. The next bar, which is even closer, is three characters high. And finally, the fourth bar, which is the closest to the observer, is four characters high. This way, bars near the observer are bigger than the bars far from the observer.
The program can be exited by holding down RUN/STOP and by hitting RESTORE.
Movement must also take perspective into account, of course. So, each time the landscape is moved, the first bar from the top will be scrolled by one pixel. The second bar from the top, by two pixels. The third one, by three pixels. And finally, the last bar, which is the closest to the observer, by four pixels. The POKES in lines 12 and 13 just accomplish this. The code should not be too difficult to figure out, especially if you take a look at this program, which uses the same principle for plain vertical scrolling.
On lines 10 and 11, the landscape is drawn on its initial appearance. The technique of printing on memory is used, by modifying the content of location 648 decimal. This allows for a faster initialization process.
Is it possible to move the landscape by printing values on memory? It can be done, and that approach makes it possible to have a faster movement than by using pokes. The program “p.scroll.fast” just does that. Notice all the print statements there. I had to work out the strings matching each frame of the landscape.
Again, the code should not be that difficult to understand, and a similar technique has been used on this program.
Using PRINT statements for the prospective scroller allows for a neatly faster and smoother movement. I soon realized there was room for some other effects. Imagine you are moving towards a city. If you are very far from the city, you won’t see it. But, as long as you get closer and closer, you will start to see something. And, as our planet is round (that’s not big news, isn’t it?), objects at a certain distance seem to slowly move upwards as long as you get closer to them.
The third program, “skyscrapers”, just tries to simulate this. At a certain point, you will see some skyscrapers slowly appearing.
The subroutine starting from line 200 draws the skyscrapers. Each part of the skyscrapers corresponds to a different character. Three characters are used. Notice the way characters are arranged on the screen. After those are printed, the matching character shapes are deleted. No skyscrapers must be shown at the beginning.
At a certain point, the subroutine starting from line 50 gets used. Counters are arranged so that it is possible to make the skyscrapers raise from the horizon, one pixel at a time. Only one byte at a time needs to be changed to scroll all the “buildings”. I choosed a vertical lines based pattern just to fit my taste.
The buildings can be moved up faster: just call the subroutine starting from line 50 more often (for example, add a GOSUB 50 statement on line 28, right before the PRINT statement). But that way, I think the movement would be too fast to be somewhat “realistic”.
“Skyscrapers” can be easily escaped by hitting RUN/STOP + RESTORE when the scroll has stopped. “p.scroll.fast”, after RUN/STOP + RESTORE, requires some blind typing. Just type GOTO100 or RUN100 (then press return, off course) and you are done
“Skyscrapers” is a quite efficient BASIC program in my humble opinion. We all know the limits of BASIC V2, but still I don’t think many other 8 bit home computers can achieve such results with pure BASIC, even if equipped with better BASICs on ROM. However, this program can be easily ported to the VIC 20, and I think it can also be ported on the Plus/4-C16-C116 range of computers. By the way, I don’t think it would be very easy to port such a program on the Sinclair Spectrum 48K or 128K (using Sinclair BASIC).