Welcome to the new year! Starting off the second season of monthly programs is January's program Road Hog. Road Hog is a driving game similar to my later Flywheel game. I hesitate to call it a racing game as there is no acceleration. You just move the car left or right using the Z or . keys. The game is pretty easy due to the slow speed of the animation. Go give it a spin.
Road Hog is a pretty simple game overall. Interestingly, the road is calculated. This is very slow in the ZX81 and I had to use
FAST to speed up displaying the road. In later programs, I would just print the complete track which is much faster at the cost of using more memory.
The cars are displayed using simple print routines. I was trying to recreate the feeling of a car coming at you. To do this, I used a series of
IF statements against the car's position to determine what size of graphic to display. There are two minor issues that would have improved the program. The first would be to erase the car just before printing it in the new position. Doing so would have reduced the flickering of the image and left the car on-screen longer. The second change would have been to move one line at a time instead of two. Had I done that I could have changed the way the car was erased which might have shortened the code and speed up the program.
I did a better job on the car you are driving. It uses blanks on either side of the image to quickly erase your movements. The ZX81 was does better if you can print all at once. As soon as you have to separate the print statements, the latency introduced by the ZX81’s design is obvious. An easy way to improve that is to use assembly code instead of BASIC. However, as the ZX81 lacks a direct compiler, I tended to avoid that route in almost all of my programs. The ZX81’s temperament where hangs and reboots are common doesn’t help. Although, this is a problem if you are using an emulator.
As I entered the program, I got a feeling of how I originally developed this program. The mismatched line numbers tell me two things. I tended to use trial and error programming, so if something didn’t work I would add more lines of code as I fixed problem areas. Second, I would add features as I thought of them. For example there is a care counter, a simple
FOR loop. I later added a day counter that is incremented when the care
FOR loop completes. I must have redone the display routines based on my use of variables to house the subroutine locations. I don’t remember doing that in many of my programs unless I needed to jump to different
GOSUB locations using a variable. It is fun looking for these hints into my teenage programming habits.
Well, that is it for this month's program. Until next time!