Super Chip RAM; RAM-Related Game Design Changes; Top Speed; 100

Entry posted by Living Room Arcade in Night Driver Arcade Wednesday at 07:56 AM

103 views

My newest ideas about Night Driver Arcade.

Please comment respectfully. This is not my job. I don't get paid to do this. Please do not ask me to write code. If I find time to write code, I will do it. And if I never find time, then I never will. Please understand and be respectful when you comment. Thank you.

Super Chip RAM

Spoiler

So, according to my UPDATED PLAN FOR THE NDA ROM, there's no longer any need to use the standard bB kernel anymore in this project. So, from now on, we'll be using Super Chip RAM in each bank of RevEng's Multikernel Framework. Using the Super Chip, we will have a 32x12 playfield and 26 bytes of RAM (a-z) plus 48 bytes of normal-use RAM plus 80 bytes of restricted-use RAM. (See Superchip RAM at RT's website.) The discussion about Windfall RAM that we had had on July 30 is still relevant, except that please note that from now on, we are no longer talking about 'windfall RAM', now we will be talking about Superchip RAM.

RAM-Related Game Design Changes

Spoiler

Increasing the Precision of All Odometers and Instant Replay Data and the Game Clock to 2 Decimal Places

This change is necessary to implement Instant Replay, Chase Your Ghost Car, 1v1 and Rally game modes. Originally, we were simply making a home version of the arcade version of Night Driver. The arcade version has a 3-digit odometer. So, our home version likewise just had a 3-digit odometer. But since we have added additional game modes such as Instant Replay, Chase Your Ghost Car, 1v1 racing and rally racing, these additional game modes and features will surely require the increased precision to all odometers and even the game clock.

Why?

Spoiler

Any game mode in which a ghost car pace car can appear on the screen in front of the player's car will require this extra precision in the odometers in order to accurately place the ghost car on the screen. The idea goes something like this.

Suppose the ghost car is in front of the player, within the player's view. (The ghost car is located on the road between the player's car and the distant horizon.)
Suppose all odometers in the game are accurate now to two decimal places. That is, to hundredths of an odometer turn.
The distance between the player's car and the ghost car in front can be found simply by subtracting the player's odometer (xxx.xx) from the ghost car's odometer (xxx.xx). The difference might be 0.xx units.
Now, recall that a ladder analogy is now used to talk about the locations of the pairs of WRM's on the road. ("The road is like a ladder with 8 rungs.
The 7 pairs of WRM's move inside the 7 spaces created by the 8 rungs.")
If we know the distance in odometer turns from one end of the ladder to the other and if we know the distance in odometer turns from the player's car to the ghost car, then the program can accurately place the ghost car on the road in the correct location.
There are only about 90 pixels along the y-axis in bB. So I am guessing that a precision of 1/100 of an odometer turn will be enough precision to place the ghost car correctly on the screen. If my guess proves to be incorrect, we can deal with that when the time comes.

Generally speaking, Instant Replay will also work better if the precision of the odometers and odometer readings are increased to hundredths of an odometer turn. The replays will be more accurate.

In Instant Replay, the collisions are recorded using the Game Clock, not the odometer of the player's car. So, likewise and for similar reasons, the precision of the Game Clock will also be increased to two decimal places.

Superchip RAM will be used to add the two extra digits to all of the odometers and the game clock. For that, we'll use some of the 48 bytes of normal-use RAM, I'm sure.

The entire block of 80 bytes of restricted-use RAM will be given to Instant Replay to record odometer readings and collisions. Suppose we use two bytes to make one odometer recording. The first byte is 0-255 in binary and means odometer turns; and the second byte is to record two nybbles in BCD to mean hundredths of an odometer turn from .00 to .99. Similarly, two bytes per recording for collisions. Note that collisions are now recorded using the game clock. ("Collisions will now be recorded in terms of time in seconds.") I have the 80-byte block of restricted use Superchip RAM penciled in for use split between odometer readings and collisions. 40 restricted-use bytes = 20 odometer readings. And the other 40 restricted-use bytes = 20 collisions.

I understand that use of this RAM is restricted but I think the solution is simple. Reserve a few bytes of normal-use RAM for use with restricted-use RAM. That is, first, read the byte of restricted-use RAM and store it in a byte of normal-use RAM. Then do your calculations on the normal-use RAM as desired. Then, if desired, you can store the result back into restricted-use RAM.

If all goes well, I imagine we would have some normal-use Superchip RAM left over at the completion of our game design. In that case, I would use it to increase the number of odometer readings and collisions in Instant Replay. For example, if we had 16 bytes of normal-use RAM left over, I would add it to the 80 bytes of restricted-use RAM given to Instant Replay. An extra 16 bytes of normal-use RAM would give Instant Replay 8 more recordings. If we split them up evenly, Instant Replay would be able to record 4 more odometer readings and 4 more collisions.

TOP SPEED

Spoiler

Here is my newest thinking about how to implement Top Speed in Arcade mode.

A game is 100 seconds (or 99 seconds). Let us say that a game has two 50-second halves.
Recall that the game timer starts at 100 (or 99) and counts down to 0.
During the first half of the game, the 6-digit display will show the player's top speed for 2 or 3 seconds every ten seconds on the "5's": 95, 85, 75, 65 and 55.
These first five displays are passive. That is, they happen regardless of whether the player's top speed has changed or when it changed. The player's actions in the game do not affect these passive displays of the player's top speed.
During the second half of the game, the top speed is displayed only when the player achieves a new, higher top speed.
We call this type of display active because the top speed is displayed in response to the player's actions in the game.

I like this new way of displaying Top Speed. During the first half of the game, the five passive updates will keep the player informed about his or her top speed without disturbing the player's game too much. In the second half of the game, in the active mode, these real-time updates will generate some thrilling game moments. Imagine, it's the second half of the game and you are racing down the road in fourth gear and you hit a new top speed and the game interrupts the odometer and the clock just for a moment to let you know that. Thrilling!

100

Spoiler

Speaking of the game clock, here's a new tweak to let our two-digit game clock start at 100 instead of 99.

If one of the 6 hex characters is available, define one hex digit to look like a 1 and a 0 combined into a single character. That is, "10".

image.png.6713c8b6d20030686de583abdb2d2be6.png A "1" and a "0" combined into a single hex digit
%00000000
%10001111
%10001001
%10001001
%10001001
%10001001
%10001001
%10001111