If you appreciate the work done within the wiki, please consider supporting The Cutting Room Floor on Patreon. Thanks for all your support!
This article has a talk page!

Bugs:Super Mario 64 (Nintendo 64)

From The Cutting Room Floor
Jump to navigation Jump to search

This page details bugs of Super Mario 64 (Nintendo 64).

Cactus 2.0!
This article has just been started and needs the article basics added.
Help us out and add them.
Hmmm...
To do:
Add more bugs, many of which are documented here.

Despawning Big Goombas Without Killing Them

if (obj_handle_attacks(&sGoombaHitbox, GOOMBA_ACT_ATTACKED_MARIO,
                               sGoombaAttackHandlers[o->oGoombaSize & 1])) {
            mark_goomba_as_dead();
        }

(Only works on the Goomba triplet spawner.)

This piece of code in the Goomba behavior file calls a function that returns a value if attacked by Mario. When this happens (as it does with every attack), the Goomba is marked as dead, so that it will despawn competely when exiting its spawn radius.

Unlike Mini Goombas and normal-sized Goombas, however, Big Goombas can't be killed by weak attacks like ordinary punches -- yet they are marked as dead regardless, and even though they still aren't actually killed, they will despawn as soon as the spawn radius is exited and reentered. This can be tested best at the starting point in Tiny-Huge Island.

This bug only works with the triplet spawner, as it has its own update function with code for loading and unloading enemies (bhv_goomba_triplet_spawner_update), which explicitly checks if any Goomba in the group is marked as dead, and if so, doesn't spawn that enemy anymore.

Empty File Deletion Crash

Present in all releases of the N64 game, including Shindou and Super Mario 3D All-Stars.

On the File Select screen, perform the following actions within quick succession of each other:

  1. Select "Copy".
  2. Select an empty file (preferably C or D, because they are closer).
  3. Select "Check Score" from the Copy menu.
  4. Select an empty file.

If done correctly, "Select File" on the Score screen will shortly fade to "No Saved Data Exists". Once this happens, select "Erase" and wait for the screen to overlap. You will be asked if you wish to delete the data in "NULL." Selecting "Yes" at this prompt will cause an address error which will immediately crash the game. If done on the 3D All-Stars version, the software will crash back to the Switch's home menu. The Wii VC is unaffected by this bug; the delete animation gets stuck, but selecting any of the other options (e.g. "Check Score") fixes it. On the Wii U VC and Nintendo Switch Online versions, the game will continue normally, albeit with the message claiming that "Mario 9" was erased.

Backwards Long Jump

The Backwards Long Jump hyperspeed method, or BLJ for short, is the most famous hyperspeed method in Super Mario 64. Due to their versatility, BLJs are commonly used in all kinds of speedruns and challenges. When Mario initiates a long jump, his horizontal speed is multiplied by 3/2. A BLJ occurs when a backwards-moving long jump is interrupted before the effects of drag can counteract the speed gain from the 3/2 multiplier. This does not occur with forwards long jumps because long jumps have a "hard cap" of +48 horizontal speed, which Mario's speed cannot exceed. No such cap exists in the negative direction, because normally the "soft cap" of -16 speed from drag is enough to stop any speed gain.

Demonstration

In the code, the case ACT_LONG_JUMP in the switch action function explains this, as it isn't called if Mario's forward velocity is at a negative integer past the speed cap.

case ACT_LONG_JUMP:
            m->marioObj->header.gfx.animInfo.animID = -1;
            set_mario_y_vel_based_on_fspeed(m, 30.0f, 0.0f);
            m->marioObj->oMarioLongJumpIsSlow = m->forwardVel > 16.0f ? FALSE : TRUE;
            if ((m->forwardVel *= 1.5f) > 48.0f) {
                m->forwardVel = 48.0f;
            }
            break;

There are several different types of BLJs. The distinguishing feature of different types of BLJs is what they use to interrupt the long jump:

  • Slope BLJs use slopes by going up a slope.
  • Stair BLJs use stairs by going up a flight of stairs.
  • Elevator BLJs use the upwards movement of an elevator or other object.
  • Side BLJs use two floors at slightly different levels by oscillating between them.
  • Ceiling BLJs use an exposed or low-hanging ceiling by making Mario hit his head and start traveling downwards faster.

BLJs can also be pause buffered to increase the amount of long jumps that can be performed in a given amount of time or space.

The BLJ glitch was patched in the Shindou release, and therefore also the iQue version. This also means that any emulator releases of these versions lack the BLJ glitch, namely the Japanese Wii VC release, the Japanese Wii U VC release, and all versions of Super Mario 3D All-Stars.

Frame Walking

Frame walking is a fairly simple glitch you can do yourself with a bit of practice and timing. Run up to a steep slope (e.g. near the crater that spawns bowling balls in Bob-omb Battlefield, or one of the rock spires in Jolly Roger Bay) and use the joystick to move each frame as you take each step.

The reason for the glitch is that when Mario does a quarter step, the game checks how steep the slope is. If it's too steep to walk on, Mario does a quarter step and then slides down. When moving on a steep slope, however, Mario's speed decreases over time and eventually makes him slide off, but not when doing a quarter step each frame before Mario's state changes to sliding.

The steeper the slope is, the harder the timing gets, eventually becoming frame-perfect each time.

Demonstration

Shell Hyperspeed

The Shell Hyperspeed glitch is a pretty easy glitch where, if Mario's on a very steep slope while riding a shell, his speed increases by a negative integer, to the point where you can build up negative speed. Going off the slope can make Mario go backwards at a fast speed, eventually decreasing over time when you're not on the steep slope.

This is because there is no negative speed cap in the update_shell_speed(struct MarioState *m) function.

if (m->forwardVel > 64.0f) {
    m->forwardVel = 64.0f;
}

C^ Hyperspeed

Hmmm...
To do:
Add the code on how it works from the source code.

C^ Hyperspeed is a pretty hard glitch to where going on a step slope, (For example: On the white slope past the Chain Chomp in Bob-omb Battlefield), moving and going in first person, Mario begins skidding indefinitely to where you can build up speed, in which if you fall off the slope, exit first person and land in a object that's claimable and exit the course before Mario's speed resets, Mario's current speed is kept inside the castle, causing the 10k glitch.

Koopa The Quick Glitches

Bowling Ball Deceleration

Using a bowling ball clone while in a race, you can force Koopa the Quick's animation index out of bounds, causing his animations to break. Eventually, his animations will become normal and then break again due to a wraparound.

static void koopa_the_quick_animate_footsteps(void) {
    cur_obj_init_animation_with_accel_and_sound(9, o->oForwardVel * 0.09f);
    koopa_play_footstep_sound(2, 17);
}
(Source: pannenkoek2012)

Koopa The Quick PU Speed Build Up

Using the same technique as in the Bowling Ball Deceleration glitch, forcing Koopa the Quick into a corner will cause him to indefinitely build up PU speed, eventually going into a PU.

In the code for the koopa_the_quick_detect_bowling_ball function, the reason why Koopa the Quick can build up PU speed is because there is no negative speed cap, just like Mario when he starts building up speed doing a BLJ.

if (distToBall < 400.0f) {
                if (ballSpeedInKoopaRunDir < o->oForwardVel * 0.7f) {
                    return 1;
                } else {
                    o->oForwardVel -= 2.0f;
                }
            }
(Source: pannenkoek2012)

Text Redirection

When walking up to a sign or a star door that you don't have enough stars to open, Mario will stop in place, but his speed will be kept. This means that by building up enough speed and reading a sign, you can redirect Mario in a different direction. This glitch is frequently used in speedruns.

Invisible Bowser

In the second Bowser fight, if you grab Bowser as he's about to teleport, you can hold and throw him while he's invisible. The reason why is because the function for Bowser to teleport is cancelled out. This can be fixed by purposely making Bowser fall, making him become visible again.

Misalignment

A misalignment is a 1x1-unit area a floor hitbox extends to but wall hitboxes do not. On convex corners, they allow Mario to snap up to the floor from up to 78 units below it, as opposed to just 30 units when there is a wall hitbox present.

Misalignment is caused by the same truncation that results in PUs; because floor and ceiling detection is done with integers, all decimal places are removed. If Mario has the right position off the floor, his position will be rounded to a spot on the floor, making the floor appear to extend to his actual position. Walls do not do this, since they use floating-point numbers, which causes the floor to not properly align with its adjacent walls.

SM64 MisalignmentDemonstration.png


(Source: pannenkoek2012)

Tick Tock Clock Pendulum Box

The box holding the pivot of the first pendulum in Tick Tock Clock is an extremely glitchy object. With a precise jump, it is possible to grab onto the top of the pendulum, which is not visually suggested to be possible as it is inside the box.

Pulling himself up will put Mario inside the box, which will cause Mario's model to undergo erratic animation irregularities and rapid displacements when he performs various actions, as seen in the footage.

SM64 Pendulum Buginess Demonstration.gif


(Source: Supper Mario Broth / toyuru2)