|
Rush Hour ?-??-83
This is the earliest of three known prototypes for Rush Hour. While all three prototypes are fairly far along, they differ greatly in their stability. This prototype has a very unstable display and is prone to rolling and flickering to the point of making it nearly impossible to play. Also everything is slower in this version due to the lower framerate which is the result of timer underflows. The oil slicks are functional in this version whereas they were disabled in the last version. The reason for this is because the code for the skidding caused by the oil slicks is extremely buggy and can cause the player to continually skid upwards (pinning the player to the top of the road) if the car hits one in the bottom lane. This bug also is also triggered if the player hits a car in the bottom lane as car collisions also trigger the skidding code.What makes these prototypes interesting is that there is some odd debugging code active that at first glance looks like random garbage on the screen. The reason for this is that the programmer was trying to figure out how long specific blocks of code were taking so he could adjust them because if the code takes too long or too little time it can cause the display kernel to lose sync which makes the picture roll or flicker.The way this debugging code works is that the code displays whatever value is in register PF2 (playfield register 2) and outputs it on the screen as graphics. Normally this value is just a loop timer value that counts down to zero and will display whatever number it is currently on as a graphic pattern on the screen based on which bits are set for the given number in binary (eg. a 4 will display a x-- pattern, 3 will display an -xx, 2 will display -x- , and 1 will display a --x pattern). These patterns are the 'graphical garbage that is displayed over the screen. This timer normally runs every 64 cycles, however if the timer underflows then the loop countdown happens every cycle which creates a different looking pattern. This is when the game begins to lose sync and roll.The programmer was attempting to fix these issues by setting initial timer values which controlled how long a block of code is allowed to run. By tweaking these values the programmer was able to get the display to be more and more stable. It's also worth noting that Rush Hour uses a great many timer values for its code whereas most games only use two.
|
