Wii VC Round-to-Zero: Difference between revisions

From Ukikipedia
Jump to navigation Jump to search
mNo edit summary
No edit summary
 
(23 intermediate revisions by 11 users not shown)
Line 1: Line 1:
[[File:WiiVC BitFS.png|thumb|300px|right|Stream by Switchpalacecorner, after 71.5 hours of raising in Wii Virtual Console]]  
[[File:WiiVC BitFS.png|thumb|300px|right|Stream by Switchpalacecorner, after 71.5 hours of raising in Wii Virtual Console]]  
[[File:WiiVC BitFS 146hr.png|thumb|300px|right|After 146.5 hours (6 days 2.5 hrs)]]  
[[File:WiiVC BitFS 146hr.png|thumb|300px|right|After 146.5 hours (6 days 2.5 hrs)]]  
'''Wii VC Round-To-Zero''' is a special phenomenon caused by emulation inaccuracy exclusive to [[Virtual Console|Wii Virtual Console]] (Wii VC). This is a new glitch discovered on May 28, 2018, that contributes to the [[A Button Challenge]].
[[File:Original-bitfs-raising.jpg|thumb|The original BitFS platform raising discovery by Andru! on May 10th 2018.]]
'''Wii VC Round-to-Zero''' refers to an emulation inaccuracy in the [[Virtual Console|Wii Virtual Console]] (Wii VC) version of SM64. When converting a double precision floating point number (a "double") to a single precision floating point number (a "float"), the N64 typically uses the round-to-nearest rounding 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. While this behavior is accurately emulated by most emulators and the Wii U VC, the SM64 Wii VC instead uses the round-to-zero mode. This mode will always round the double up if it is negative, and round it down if it is positive.


In the Wii Virtual Console, it is possible to raise the moving platform at the beginning of [[Bowser in the Fire Sea|BitFS]], due to a rounding error that is unique to the Wii Virtual Console. It is believed this happens because the Wii doesn't round-to-nearest with floating point numbers, as the [[Nintendo 64|N64]] does, but instead rounds-to-zero. Since the moving platform is below 0, it tends towards it. It is possible to [[Abbreviations|DR]] in about 8 days, and it is possible to [[Vertical Speed Conservation|VSC]] with a lava boost in 3 days.
While the programmers did not intentionally use doubles very often, favoring single precision floats instead, they occasionally used them accidentally.


The glitch was discovered by '''Andru!''' when he went to sleep leaving the Wii powered on for several hours in Bowser in the Fire Sea (BitFS), and found that the oscillating platforms had left their original positions.<sup><ref>''Bowser in the Fire Sea in 0x A Presses? (New Glitch Explanation)'', by bad_boot: https://www.youtube.com/watch?v=MFxJuq3FRgI&feature=youtu.be</ref></sup>
<syntaxhighlight lang="C" line='line'>
y -= sins(t) * 0.58;
t += 0x100;
</syntaxhighlight>


==Applications==
In the above code sample, <code>y</code> and <code>sins(t)</code> are both single precision floats. However, in C, the numeric literal <code>0.58</code> is a double since it lacks a trailing <code>f</code>, as in <code>0.58f</code>. This causes the expression to evaluate to a double, which is then converted to a float before being stored in <code>y</code>. Examples such as this one arise in many places in the game's source code, and over time they result in large discrepancies between the N64 and Wii VC versions of the game. For this reason, TASes produced for one of these platforms cannot generally be played back on the other without desync.
Currently, only the blue moving platforms in BitFS and LLL on Wii Virtual Console are known to have this property. All other consoles such as the original N64, WiiU Virtual Console, and Shindou do not have this rounding error.
 
The example given above is taken from the code controlling the oscillation of the platforms at the beginning of [[Bowser in the Fire Sea]]. Using the N64's rounding mode, the <code>y</code> variable, which represents the platform's height, 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. This is known as '''Wii VC platform drift'''.
 
From its starting position of y=-3065 until it reaches y=-2048, this platform rises 254 times by 1/4096th 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 doing the math, 127/128*1/4096units*30frames*60seconds*60minutes, we get that the platform drifts by ~13.0806 units/h.
 
Once it passes y=-2048, the platform halves in rising speed: ~6.5403 units/h. The platform continues to halve in speed as it passes through y=-1024, y=-512, y=-256, and all other 2^n boundaries til it comes to a halt near y=0.
 
As it passes through a 2^n boundary, its behavior becomes complex. Throughout its up-down oscillation cycle, the platform is sometimes past the 2^n boundary and sometimes not. The overall speed decrease as the platform's average height passes through the 2^n boundary is represented by a differential equation of <math>v_y=\frac{dy}{dt}=\arccos(y)</math>: 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.
 
The platforms at the beginning of the level are below ''y'' = 0, and so they gradually rise upward. Over the course of several days, they are high enough they can be used to reach the elevator past the pole, which previously required one A press to get past. It takes eight days for the platform to reach high enough for a dive recover to land in the elevator shaft, but using [[Vertical Speed Conservation|VSC]] with a lava boost requires only three days.


The glitch was fully console verified RTA on 06/20/18 by ethanwhitesm64,<sup><ref>BitFS 0x A Presses [https://youtu.be/B1m-5LWOxW0]https://youtu.be/B1m-5LWOxW0</ref></sup> and used by Pannenkoek2012 to collect the red coin star 0x 6 days later using a modified N64 emulator that replicated the rounding error.<sup><ref>Bowser in the Fire Sea with Red Coins 0x A Presses (Wii VC Only) [https://youtu.be/Aa_CciaM4aM]https://youtu.be/Aa_CciaM4aM</ref></sup>
The glitch was discovered by '''[https://www.youtube.com/channel/UCz8K5WhRhrjFRNGvkWupUlQ xAndru!]''' when he 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.<ref>[https://www.youtube.com/watch?v=MFxJuq3FRgI "Bowser in the Fire Sea in 0x A Presses? (New Glitch Explanation)" by bad_boot]</ref>


The first attempt, by ethanwhitesm64, failed because he DR'd to early and missed the platform.<sup><ref>oops (ethanwhitesm64 misses pole) [https://www.twitch.tv/ethanwhitesm64/clips]https://www.twitch.tv/ethanwhitesm64/clips</ref></sup>
The bug does not occur in any later Wii VC releases, nor in the Wii U VC or in any mainstream N64 emulators. At the time of its discovery, the bug did not occur on the Dolphin emulator, but has since been corrected.<ref>[https://dolphin-emu.org/blog/2018/07/06/dolphin-progress-report-june-2018 "Dolphin Progress Report: June 2018"]</ref>


The second attempt, by barruuuu, failed because after a successful DR, he overshot the elevator and when he ran back, he fell through the hole.<sup><ref>lol (barruuuu falls through elevator) https://clips.twitch.tv/OpenDependableClintVoteNay</ref></sup>
No objects other than the sinking platforms are known to have similarly exploitable behavior, though the rounding bug does cause many discrepancies between the original and Wii VC versions of the game, including slightly different surface normals.


The third attempt, by Switchpalacecorner, failed because after a successful DR, the top moving platforms loaded and moved down below the lava. While it is possible to get the next platform using the side ledges, Switch missed it and fell down back to the first floor.<sup><ref>new sm64 glitch: BitFS Platform Raising (warning: boring) https://clips.twitch.tv/TriumphantHelpfulYogurtSeemsGood</ref></sup>
This bug does not affect the sinking platforms in [[Lethal Lava Land]] because they are already located at y=0.
 
==Applications==
After several failed attempts by various players, the A press save in [[Bowser in the Fire Sea]] was console verified RTA on 20 Jun 2018 by Emilia Blue.<ref>[https://youtu.be/B1m-5LWOxW0 "BitFS 0x A Presses" by Emilia Blue]</ref> Six days later, pannenkoek2012 TASed the red coin star in zero A presses using a modified N64 emulator that replicated the rounding error.<ref>[https://youtu.be/Aa_CciaM4aM "Bowser in the Fire Sea with Red Coins 0x A Presses (Wii VC Only)" by UncommentatedPannen]</ref>


==References==
==References==
<references/>
<references/>
<!-- Category -->
[[Category:Glitches]]
{{Glitches}}

Latest revision as of 16:48, 4 October 2023

Stream by Switchpalacecorner, after 71.5 hours of raising in Wii Virtual Console
After 146.5 hours (6 days 2.5 hrs)
The original BitFS platform raising discovery by Andru! on May 10th 2018.

Wii VC Round-to-Zero refers to an emulation inaccuracy in the Wii Virtual Console (Wii VC) version of SM64. When converting a double precision floating point number (a "double") to a single precision floating point number (a "float"), the N64 typically uses the round-to-nearest rounding 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. While this behavior is accurately emulated by most emulators and the Wii U VC, the SM64 Wii VC instead uses the round-to-zero mode. This mode will always round the double up if it is negative, and round it down if it is positive.

While the programmers did not intentionally use doubles very often, favoring single precision floats instead, they occasionally used them accidentally.

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

In the above code sample, 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 to evaluate to a double, which is then converted to a float before being stored in y. Examples such as this one arise in many places in the game's source code, and over time they result in large discrepancies between the N64 and Wii VC versions of the game. For this reason, TASes produced for one of these platforms cannot generally be played back on the other without desync.

The example given above is taken from the code controlling the oscillation of the platforms at the beginning of Bowser in the Fire Sea. Using the N64's rounding mode, the y variable, which represents the platform's height, 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. This is known as Wii VC platform drift.

From its starting position of y=-3065 until it reaches y=-2048, this platform rises 254 times by 1/4096th 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 doing the math, 127/128*1/4096units*30frames*60seconds*60minutes, we get that the platform drifts by ~13.0806 units/h.

Once it passes y=-2048, the platform halves in rising speed: ~6.5403 units/h. The platform continues to halve in speed as it passes through y=-1024, y=-512, y=-256, and all other 2^n boundaries til it comes to a halt near y=0.

As it passes through a 2^n boundary, its behavior becomes complex. Throughout its up-down oscillation cycle, the platform is sometimes past the 2^n boundary and sometimes not. The overall speed decrease as the platform's average height passes through the 2^n boundary is represented by a differential equation of : 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.

The platforms at the beginning of the level are below y = 0, and so they gradually rise upward. Over the course of several days, they are high enough they can be used to reach the elevator past the pole, which previously required one A press to get past. 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.

The glitch was discovered by xAndru! when he 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.[1]

The bug does not occur in any later Wii VC releases, nor in the Wii U VC or in any mainstream N64 emulators. At the time of its discovery, the bug did not occur on the Dolphin emulator, but has since been corrected.[2]

No objects other than the sinking platforms are known to have similarly exploitable behavior, though the rounding bug does cause many discrepancies between the original and Wii VC versions of the game, including slightly different surface normals.

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

Applications

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

References