Wii VC Round-to-Zero

Stream by Switchpalacecorner, after 71.5 hours of raising in Wii Virtual Console

After 146.5 hours (6d 2h 30m)

Wii VC Round-to-Zero is an emulation inaccuracy in the Wii Virtual Console (Wii VC) version of Super Mario 64.

When converting a double-precision floating point number (a double) to a single-precision floating point number (a float), some doubles will have to be rounded to a nearby float. There is a discrepancy in the rounding mode used:

• The Nintendo 64 typically uses the round-to-nearest mode. This means that if the double is not exactly equal to a float, it will round up or down to the float that is closest in value to the original number. This behavior is accurately emulated by most emulators and the Wii U VC.
• The Wii VC instead effectively uses a round-toward-zero mode. This mode rounds all positive doubles down, and all negative doubles up, to the nearest float.

While the programmers did not intentionally use doubles very often (favoring single-precision floats instead), they occasionally used them accidentally, causing extra double-to-single conversions in many places in the game's source code. The rounding involved creates discrepancies in the Wii VC version of the game, such as slightly different surface normals, which build up over time throughout gameplay. For this reason, TASes produced for either N64 or Wii VC cannot generally be played back on the other platform without desync.

Technically, the Wii VC version of Super Mario 64 does set the Wii's CPU to round-to-nearest. However, storing a double to the Wii's floating point registers and reading it back as a single is undefined behavior. In practice, doing so ends up discarding the lower bits of the mantissa—a truncation, which rounds toward zero. (The opposite situation, storing a single and reading it back as a double, is supported and converted correctly.)

Platform drift

In Bowser in the Fire Sea, round-to-zero causes a bug known as Wii VC platform drift, where the oscillating platforms that sink into lava will slowly rise up to the height of the origin.

This code controls the oscillation of these platforms. The variable y represents the platform's height.

y -= sins(t) * 0.58;
t += 0x100;

Here, y and sins(t) are both single-precision floats. However, in C, the numeric literal 0.58 is a double since it lacks a trailing f, as in 0.58f. This causes the expression sins(t) * 0.58 to evaluate to a double, which is then converted back to a float for the subtraction-assignment to y.

Using the N64's rounding mode, y will repeatedly return to its original value and continue oscillating with fixed maximum height. Even though each double-to-single conversion produces a small amount of error, this error balances out over the course of the platform's cycle. On the Wii VC, however, the error always accumulates in the same direction (upward if the platform is below y = 0, and downward if the platform is above y = 0), and so the platform slowly drifts in the vertical direction.

The platforms in BitFS are below y = 0, and so they gradually rise upward. As a result, the bug is of interest to the A Button Challenge, since it lets Mario ride the platforms up to skip a pole that requires an A press to dismount.

Drift speed

From its starting position of height y = −3065 until it reaches y = −2048, this platform rises 254 times by ${\textstyle {\frac {1}{4096}}}$th of a unit for each 256-frame cycle: 127 times as it goes up, 127 times as it goes down (at the peak and bottom of the oscillation cycle, the platform stays still so no rounding occurs). So the platform initially drifts by about 13.08 units per hour:

${\frac {127}{256}}\times {\frac {1}{4096}}\ {\frac {\mathrm {units} }{\mathrm {frames} }}\times \left(30\ {\frac {\mathrm {frames} }{\mathrm {s} }}\times 60\ {\frac {\mathrm {s} }{\mathrm {min} }}\times 60\ {\frac {\mathrm {min} }{\mathrm {h} }}\right)\approx 13.0806\ {\frac {\mathrm {units} }{\mathrm {h} }}$

The floating-point numbers are distributed non-uniformly; the gap between floats doubles after each power of two, so their number line is denser closer to zero. Because the platform drifts toward zero, the error factor (initially ${\textstyle {\frac {1}{4096}}}$) is halved after certain thresholds, and so the platform's net speed is also halved. First, above y = −2048, it drops to about 6.54 units per hour. It continues to halve in net speed as it passes through y = −1024, y = −512, and all other ${\textstyle y=2^{n}}$ boundaries, until it stops around y = 0.

Each time the platform oscillates through one of these boundaries, its behavior becomes complex. Throughout its cycle, the platform is sometimes above ${\textstyle y=2^{n}}$ and sometimes below. The overall speed decrease as the platform's average height passes through the boundary is represented by the differential equation

$v_{y}={\frac {dy}{dt}}=\arccos \left(y\right)$

The platform suddenly slows down quickly, then at a slower rate before it decelerates faster again, and finally, suddenly the platform's acceleration completely stops, the speed settling at a constant, half of what it started with.

Over the course of several days, the platforms rise high enough for Mario to reach the elevator past the pole. It takes eight days for the platform to reach high enough for a dive recover to land in the elevator shaft, but using VSC with a lava boost requires only three days.

History

The original BitFS platform raising discovery by Andru! on May 10, 2018.

The platform-drift bug was discovered by xAndru! on May 10, 2018. He had left his Wii powered on overnight while in Bowser in the Fire Sea, and noticed that the oscillating platforms had risen above their original positions.

After several failed attempts by various players, the A press save in Bowser in the Fire Sea was console verified RTA on June 20, 2018 by Emilia Blue. Six days later, pannenkoek2012 TASed the red coin star in zero A presses using a modified Nintendo 64 emulator that replicated the rounding error.

Scope

The bug does not occur in any later Wii VC releases, nor in the Wii U VC or in any mainstream Nintendo 64 emulators. At the time of its discovery, the bug did not occur on the Dolphin emulator, but was corrected in 2018 to match the behavior of the Wii hardware.

No objects other than the sinking platforms are known to have similarly exploitable behavior. (However, as said, the rounding inaccuracy does cause other discrepancies between the versions of the game.)

This bug does not affect the sinking platforms in Lethal Lava Land because they are already located at y = 0.