Back to Page
Revision 29 (current)
Edited by Weatherton on 2/7/2021 3:55 AM
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 [GameResources/N64/MarioKart64|Mario Kart 64 Game Resources]
----
!!!Assumed Lag Frames Scaling Factor Modifiers
''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:
[http://i.imgur.com/SGCSPlB.png] [http://i.imgur.com/dE9JhWc.png]
[http://i.imgur.com/1ra3yTf.png] [http://i.imgur.com/gEGCbRO.png]
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:
!!30 fps Codes (Created by Sean Sullivan):
__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.%%%
!!60 fps Codes (Created by Sean Sullivan):
''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%%%
!!!16:9 Anamorphic Widescreen (discovered by Jorge Luis):
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.''%%%
!!!All Players Can Choose The Same Character
810B3924 2400%%%
810B3936 7FFF%%%
810B39A4 2400%%%
810B39B6 7FFF%%%
810B3A38 2400%%%
810B3A4E 7FFF%%%
!!!All Cups Tour (created by Sean Sullivan):
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).
!!!ROM Patch (created by abitalive):
A patch containing the above codes (except All Cups Tour) can be found [http://pastebin.com/tyqYiW6u|here] and applied to the US ROM with [https://github.com/Tarek701/CajeASM/releases|CajeASM].