Emulator/Sync Settings:

Game Objectives:

  • Treks over 400 miles on a road surrounded by desert
  • Takes damage to save time
    • Breaks speeding laws
  • Genre: Platform
  • Genre: ROM Hack
Desert Mario 64 is a ROM Hack of Super Mario 64, created by Kaze Emanuar in 2019. Much like the original Desert Bus game, you’re tasked with traveling across a very long road from Tucson, Arizona to Las Vegas, Nevada. Except it’s not by bus, because Mario overslept and the bus left without him. It’s by foot.

Gameplay Mechanics

While the core Super Mario 64 experience is unchanged in this hack, there are two specific additions that prevents one from mindlessly holding forward until the game is finished: The road temperature, and the speed limit.
Because the road is right in the middle of a desert, it is naturally very hot. If Mario remains on the ground for too long (The “Heat Meter” reaching 100), it acts like lava, and Mario is burned. Additionally, there is also a speed limit in place (“Speed Limit 55” according to signs on the side of the road, 58 in-game units per frame to be exact), in which Mario starts to rapidly take damage if he travels above that limit. Fortunately, Mario also slowly regains health over time, which means mistakes (Intentional or otherwise) aren’t permanent.
In the context of a TAS, the fastest method of movement on flat ground without any slopes is using slidekicks over and over. Because Mario is almost always in the air while using these, the Heat Meter can effectively be ignored. Unfortunately, the speed limit becomes the primary limiting factor, as 58 units per frame is easily reachable by chaining slidekicks, which means going fast requires a bit more thinking.

The Primary Strategy

Because Mario regains health over time, the general strategy is to break the speed limit in one giant burst until Mario has a sliver of health remaining, then coast along just under the speed limit while Mario recovers until it fully replenishes, and then do another speed burst. To be exact, Mario’s HP (While alive) ranges from 256 to 2176; he takes 32 damage per frame while above the speed limit, and heals 1 HP every two frames at all times. Due to the amount of time the speed limit can be broken, a burst involves a series of slidekicks followed by one final jump kick (Which conserves more speed in the short term, due to not sliding on the ground for a frame) as Mario’s HP almost reaches zero.
As is the case with any TAS involving long, monotonous sections of gameplay, a sequence of inputs that can be repeated over and over is crucial in reducing the amount of actual time spent working on it. And in spite of all the variables present to make this difficult - road position, speed, and HP - I managed to solve things down to the precision of exact floating point numbers.

The Sides of the Road

The road you travel on is 1600 units wide, centered on the origin, and is blocked off by invisible walls that prevent you from walking on the actual desert. Additionally, hitting these walls makes Mario lose all of his speed, which means it’s necessary for Mario to not veer in one direction too far.
Unfortunately, holding straight up on the control stick is unoptimal for speed, which means sideways motion is needed. Even worse, left and right are just slightly asymmetrical, which means drift is functionally impossible to avoid. But fortunately, the actual amount of drift needed to prematurely bonk on the side of the road is relatively large, and is able to be kept in check with periodic corrections.
Aside from the road boundaries, the playing field is effectively a flat, barren rectangle, 8000 units long. When Mario crosses X = 4000, he is warped back to X = 0, and a counter is incremented. When this counter reaches 10,053, the game ends.

Maintaining Speed

Moving the control stick changes Mario’s speed (Citation Needed). The control stick has an X coordinate and a Y coordinate, with ranges of [-128, +127] (X, left to right) and [-127, +128] (Y, top to bottom); there are also deadzones present along the cardinal directions, where all values in the range [-7, +7] act as a value of zero. A specific control stick value changes Mario’s speed differently depending on the angle of the camera relative to Mario’s own facing angle, which means specific camera angles are important in particular circumstances.
With the camera at a diagonal angle relative to Mario, it happens that the control stick values of 40,-104 and 72,-29 change Mario’s speed by just +0.0000267029 per frame, which are used to hold Mario’s speed right below the limit. The diagonal camera also allows much greater precision in slight deviations from holding exactly forward in comparison to a front-facing camera (Which has deadzones as explained previously), at the level of being able to hit individual floating points, which ultimately allows Mario to start and end a slidekick cycle with the exact same speed.
Value (X Descending, Y Max)Speed Change (Floating Point Units)Value (X Max, Y Descending)Speed Change (Floating Point Units)
127, -127+/-0 (0fpu), Max Speed
126, -127-0.0000076294 (2fpu)127, -126-0.0000152588 (4fpu)
125, 127-0.0000457764 (12fpu)127, -125-0.0000648499 (17fpu)
124, -127-0.0001144409 (30fpu)127, -124-0.0001411438 (37fpu)
123, -127-0.0002136230 (56fpu)127, -123-0.0002136230 (56fpu)
122, -127-0.0002975464 (78fpu)127, -122-0.0003471375 (91fpu)
121, -127-0.0004501343 (118fpu)127, -121-0.0005111695 (134fpu)
120, -127-0.0006370545 (167fpu)127, -120-0.0007057190 (185fpu)
119, -127-0.0008544922 (224fpu)127, -119-0.0009346009 (245fpu)
The previously mentioned asymmetry between left and right actually helps in this instance, as it allows for a wider range of floating points to be accessed.
In conclusion, the perfect looping slidekick can be broken down into sections: Full control stick magnitude to get back to 58 speed (As sliding on the ground to start a slidekick drops Mario’s speed by a few units per frame), a few FPU corrections just before the limit is reached, one final strain frame to hit the limit, coasting at +0.0000267029 during the rollout, and then landing at 57.9999961853 speed to start another slidekick again.

The Speed Bursts

With the slidekick perfected, it can now be looped over and over without Mario losing any HP from accidentally crossing over the speed limit (Or losing any speed from being unoptimal). When Mario’s HP becomes full (Or, nearly full), the speed limit is momentarily broken so Mario can cover more distance; the question becomes “How many slidekicks does it take for Mario’s HP to recover?” in order to now optimize this section.
In prior TASes, I settled on exactly 100, for convenience and for repeatability (As any small losses were washed out due to healing slightly more than required). From my new research, this answer varies depending on Mario’s HP at the start of a given cycle; I found three distinct “sets” of boost cycles to use at different starting HP values:
  • Cycle 01: 99 slidekicks, with one more slidekick to start the boost three frames before landing. 60 total frames of boosting, with one frame of straining right below the limit so Mario doesn’t die at the end of it. Mario’s HP at the end of the cycle is 25 higher than the HP at the cycle’s start, with the minimum value being +6 higher than the starting HP (No risk of accidental death).
  • Cycle 02: 98 slidekicks, with one more slidekick to start the boost three frames before landing. 61 total frames of boosting, with zero straining frames. Mario’s HP at the end of the cycle is 26 lower than the HP at the cycle’s start, with the minimum value being 45 lower than the starting HP (Cycle can only be done with better HP).
  • Cycle 03: The same as Cycle 01, but with 98 slidekicks instead of 99. Mario’s HP at the end is 6 higher than it is at the start, with a minimum value of -13 from starting HP (A middle ground option).
All three cycles follow the same general speed burst trend as outlined earlier, in which slidekicks are performed at full control stick magnitude, finished by doing a jump kick to conserve short-term speed better. The camera angle is changed again, from diagonal to front-facing, as the control stick can hit a better jump kick magnitude to conserve more speed this way. It is changed back to diagonal while Mario is in the process of landing from the kick; fortunately, no issues arise from needed control stick precision in this section.
While Mario does drift a large amount over the course of a cycle, the drift is corrected at the end of it so Mario’s Z position doesn’t deviate much. Despite the aforementioned asymmetry of the control stick, there are still multiple control stick values (40, -104 and 72, -29 for example) that hit the same exact speed with left or right bias, which means they can (almost) fully cancel each other out, making drift a non-issue.
At the start of the game, after the initial speed burst before any cycles are done, Mario starts off with 19 HP (Technically 275HP, but remember that 255HP and below means Mario is dead). At minimum, Mario needs to start at 46HP in order to do the slightly faster Cycle 02 boost, which means one 01 (+25HP) cycle and one 03 (+6HP) cycle need to be done before that. This puts Mario at 50 HP, after which the 02 (-26HP) and 01 (+25HP) cycles can be repeated in sequence (With a net loss of 1HP after two cycles) until Mario hits 45HP. 03 is done again for Mario to hit 51HP, at which 02 and 01 can again be repeated until Mario hits 45HP. This is a repeating cycle, hooray!
Cycle ID0302010201020102010201020103 Loop
HP at Cycle End5125502449234822472146204551 Loop
Using this supercycle, Mario does a grand total of 181 speed bursts and reaches the end about a third of the way into the next smaller cycle. I then found (After the initial submission) that by replacing this supercycle with another one that does more slidekicks, I was able to "push" the last speed burst forward in time to occur right at the end of the TAS, which ended up saving an extra two frames. The final tally: A timesave of 79 frames (By input count) over the TAS I made a few months ago.
That’s an efficiency improvement of an earth shattering, mind blowing, utterly incomprehensible!
0.011190%
The file submitted also ends input early by a few extra frames, reaching the first frame of fadeout at the same time as continuing input.

Improvements

Unless there's actually another super-super secret cycle that lets me squeeze out even more time, I'm honestly clueless as to what else can be done.

Encoding Notes

In this ROM Hack, Mario holds a radio that plays a number of copyright unsafe Boomer Tunes™; specifically, AC/DC’s Highway To Hell blocks a YouTube upload from being seen worldwide. By using the MHS memory editing application, it’s possible to locate the address used for music volume (0x00935344 on Mupen 1.0.11 and 0x008EF00C on Mupen 1.1.1 from my tests, unknown for other versions) and lock the value to 0 so that no music plays.

eien86: Claiming for judging.

eien86: Delayed waiting for author to provide information about the emulator plugins used

eien86: Well, this is obviously Desert Bus ported to a Mario 64 form. In my opinion, the movie has nil entertainment value per se, but only in the fact that it reaches the end of this game-shaped punishment method in an arguably optimal and flawless manner.
The contrast between fascination and tedium manifests in the opinions of voters, 5 or which voted favourably and 3 negatively, and of comments left in the game topic. No doubt will we see such division in the Youtube comments when this gets uploaded (btw, I don't envy the encoder).
Accepting to standard
Encoder: I was able to sync this movie using the set of plugins specified by the movie.
EZGames69: Oh boy


TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15552
Location: 127.0.0.1
This topic is for the purpose of discussing #9230: DyllonStej's N64 Desert Mario 64 in 6:32:28.10
GJTASer2018
He/Him
Joined: 1/24/2018
Posts: 299
Location: Stafford, NY
There's some level of insanity involved in creating this hack, and an even greater level of insanity in TASing it! (Yes vote) Plus, you didn't have to break BizHawk to make it, unlike what happened with the actual Desert Bus... :P
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
Post subject: 1, 2, 3...
Spikestuff
They/Them
Editor, Publisher, Expert player (2632)
Joined: 10/12/2011
Posts: 6435
Location: The land down under.
Not it.
WebNations/Sabih wrote:
+fsvgm777 never censoring anything.
Disables Comments and Ratings for the YouTube account. Something better for yourself and also others.
CoolHandMike
He/Him
Editor, Judge, Experienced player (894)
Joined: 3/9/2019
Posts: 692
Lol over 6 hours of bouncing. More permanent link to hack. https://romhacking.com/hack/desert-mario-64
discord: CoolHandMike#0352
Post subject: 2f Improvement in Userfiles
DyllonStej
He/Him
Experienced player (574)
Joined: 6/6/2016
Posts: 39
I've made an additional improvement of two input frames by timing of "the first frame of fadeout", at the expense of not being able to end input as early due to the timing being more strict. It is linked at User movie #638593397933906760
Check out my main channel and contact me here: https://www.youtube.com/channel/UCngaLL0QDbsAGYj7zsB8o_Q
Post subject: request for info
eien86
He/Him
Judge, Skilled player (1871)
Joined: 3/21/2021
Posts: 261
Location: Switzerland
Hi DyllonStej For me to judge the movie, I need to be able to reproduce it first. For this I'll need you to tell me exactly which plugins you used for Mupen, where can I get them, and what configuration you used. Thanks
DyllonStej
He/Him
Experienced player (574)
Joined: 6/6/2016
Posts: 39
For the record, the plugin settings used for the movie are built into the .m64 file itself. Additionally, to my own knowledge and from my own experience, the ability to sync this hack and other Super Mario 64 related things isn't inherently reliant on specific plugin settings or emulator resolution (In contrast to something like Ocarina of Time). This is why I didn't make any specific notes in the sync settings aside from the emulator used, which does affect sync. Regardless, Video: Jabo's Direct3D8 1.6.1 Sound: Jabo's DirectSound 1.6 Input: TAS Input RSP: RSP emulation Plugin As for "how", there's normally a "repack" of the emulator (https://repack.skazzy3.com/ ) that contains these plugins alongside the most recent version of Mupen, but that's down now for some reason. I think I can only say "Find them somewhere else" (Jabo is closed source apparently), but again, the settings aren't required for sync.
Check out my main channel and contact me here: https://www.youtube.com/channel/UCngaLL0QDbsAGYj7zsB8o_Q
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 15552
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [6166] N64 Desert Mario 64 by DyllonStej in 6:32:28.10