This page documents the development of game modifications (typically in the format of Gameshark codes) which could eventually be rolled into a game patch as desired.

See also Mario Kart 64 Game Resources

Purpose: Provide smoother, more consistent game pacing and temporal resolution

Mario Kart 64 runs at 30 input frames per second (fps) of in-game time. Under ideal conditions there is one lag frame between each input frame. Internally the game makes calculations at 60 fps. On the actual Nintendo 64 hardware, this is typically true in one player modes but not true in multiplayer modes. The game engine is not capable of dynamically adjusting the game pacing based on the number of actual runtime input fps. Because of this, additional lag frames in multiplayer mode would make the game run in slow motion from the players' perspectives (although the simulated speed internal to the game would be the same as in comparable one-player modes). To counteract this and make the play speed feel similar to one player modes, the developers introduced a scaling factor to change the amount of in-game time elapsed per input frame. In one-player modes this factor is 2, meaning that from one input frame to the next, 2 units of in-game time (2/60 of a second) are simulated to have elapsed. In multiplayer this scaling factor is adjusted based on the number of players and the course that is being played. It is adjusted to either 3 or 4 units of in-game time (3/60 or 4/60 of a second respectively). These adjustments were presumably made by game testers late in development with the hope of mimicking the intended game pacing showcased in one-player modes. They represent a 50% and 100% increase in in-game time elapsed per input frame and a corresponding decrease in temporal resolution by 1/3 and 1/2 respectively. Given only these large adjustments, the resulting game pacing on actual hardware is inconsistent and the loss in temporal resolution makes the controls less responsive.

When played on more capable hardware, including the official Virtual Console and iQue releases as well as unofficial emulators, fewer lag frames are experienced. With fewer lag frames these scaling factors actually change the effective speed of the game. They directly increase the pacing by 50% or 100%. Combined with the loss in temporal resolution, three and four player modes become almost unplayable. In these cases, it would be preferable to remove these hardware dependent scaling factors and accept a consistent real-time 30 fps.

The scaling effects are summarized in the following tables:

Thankfully, it is possible to set these scaling factors to assume 30 input fps with some simple codes. These codes set the game time units per input frame to always be 2, regardless of what the original game specified:

Three and Four Player game tempo fix:
81001C90 240A
81001C92 0002
81001C94 240A
81001C96 0002

Two Player game tempo fix:
81001A38 2409
81001A3A 0002
81001A3C 2409
81001A3E 0002

It is also possible to set the game time units per input frame to 1. This produces 60 frames per in-game second but the lag frames every other frame still exist. Thus, these codes result in the game playing at an effective runtime pacing of 50% of normal. To overcome this, it is necessary to use an emulator capable of fast forwarding at 200%. The end result is a normal pacing and very smooth 60 fps in all modes. However the music will be double speed and some frame-rate dependent animations (like power slide smoke) occur twice as often as normal.

Note: Requires emulator to be played at 200% speed for correct pacing
U.S. Version Codes
One Player 60fps tempo:
810015C4 240F
810015C6 0001
810015C8 240F
810015CA 0001

Two Player 60fps tempo:
81001A38 2409
81001A3A 0001
81001A3C 2409
81001A3E 0001

Three and Four Player 60fps tempo:
81001C90 240A
81001C92 0001
81001C94 240A
81001C96 0001

Japanese (1.0 and 1.1) versions (thanks to micro500)
One Player 60fps tempo:
810015A4 240F
810015A6 0001
810015A8 240F
810015AA 0001

Two Player 60fps tempo:
81001A18 2409
81001A1A 0001
81001A1C 2409
81001A1E 0001

Three and Four Player 60fps tempo:
81001C70 240A
81001C72 0001
81001C74 240A
81001C76 0001

1P, 3P and 4P: 81150148 3FDF
2P: 81150148 4060
Note: You can only have one of these on at at time. Need to make a more complicated code to edit this value based on the number of players.

810B3924 2400
810B3936 7FFF
810B39A4 2400
810B39B6 7FFF
810B3A38 2400
810B3A4E 7FFF

8128E3C6 000F

The relevant mips assembly instructions are:
8028E3B8 : LUI v1, 0x8019 <-- set v1 to be 0x80190000
8028E3BC : ADDIU v1 , v1, 0xEE0B <-- add to v1 to make it 0x8018EE0B
8028E3C0 : LB v0, 0x0000 (v1) <--read the byte from the address v1 is pointing to and store it in v0
8028E3C4 : ADDIU at, r0, 0x0003 <-- set AT = 0 + 3
8028E3CC : BNE v0, at, 0x8028E3E4 <-- if v0 is not equal to AT, then do jump to instruction 8028E3E4

So this part of the code is relevant because 0x8018EE0B is the memory address which holds the course you're currently on in your GP (0 for 1st course, 3 for 4th course, etc). So it's reading the course and then doing an if statement if you've just finished course 3 (the 4th course), which presumably triggers whether or not to end the GP. So this code just changes the instruction there at 8028E3C4 from ADDIU at,r0,0x0003 to ADDIU at,r0,0x000F (F is 15).

A patch containing the above codes (except All Cups Tour) can be found here and applied to the US ROM with CajeASM.