confirmed_editors
135
edits
Wii VC Round-to-Zero: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
AgentMuffin (talk | contribs) mNo edit summary |
AgentMuffin (talk | contribs) mNo edit summary |
||
| Line 14: | Line 14: | ||
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 {{w|Origin (mathematics)|origin}}. | 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 {{w|Origin (mathematics)|origin}}. | ||
This code controls the oscillation of these platforms. The variable | This code controls the oscillation of these platforms. The variable {{code|y}} represents the platform's height. | ||
<syntaxhighlight lang="C" line='line'> | <syntaxhighlight lang="C" line='line'> | ||
| Line 21: | Line 21: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Here, | Here, {{code|y}} and {{code|sins(t)}} are both single-precision floats. However, in {{w|C (programming language)|C}}, the {{w|Literal (computer programming)|numeric literal}} {{code|0.58}} is a double since it lacks a trailing {{code|f}}, as in {{code|0.58f}}. This causes the expression {{code|sins(t) * 0.58}} to evaluate to a double, which is then converted back to a float for the subtraction-assignment to {{code|y}}. | ||
Using the N64's rounding mode, | Using the N64's rounding mode, {{code|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 {{var|y}} = 0, and downward if the platform is above {{var|y}} = 0), and so the platform slowly drifts in the vertical direction. | ||
The platforms at the bottom floor in BitFS are below | The platforms at the bottom floor in BitFS are below {{var|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. | ||
The platforms at the top floor in BitFS are above | The platforms at the top floor in BitFS are above {{var|y}} = 0, and so they gradually fall downward. | ||
===Drift speed=== | ===Drift speed=== | ||
From its starting position of height | From its starting position of height {{var|y}} = −3065 until it reaches {{var|y}} = −2048, this platform rises 254 times by <math display="inline">\frac{1}{4096}</math>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: | ||
:<math>\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}}</math> | :<math>\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}}</math> | ||
The floating-point numbers are distributed non-uniformly; the gap between floats doubles after each {{w|power of two}}, so their number line is denser closer to zero. Because the platform drifts toward zero, the error factor (initially <math display="inline">\frac{1}{4096}</math>) is halved after certain thresholds, and so the platform's net speed is also halved. First, above | The floating-point numbers are distributed non-uniformly; the gap between floats doubles after each {{w|power of two}}, so their number line is denser closer to zero. Because the platform drifts toward zero, the error factor (initially <math display="inline">\frac{1}{4096}</math>) is halved after certain thresholds, and so the platform's net speed is also halved. First, above {{var|y}} = −2048, it drops to about 6.54 units per hour. It continues to halve in net speed as it passes through {{var|y}} = −1024, {{var|y}} = −512, and all other <math display="inline">\left|y\right| = 2^n</math> boundaries, until it stops around {{var|y}} = 0. | ||
Each time the platform oscillates through one of these boundaries, its behavior is more complicated. Throughout its cycle, the platform is sometimes above <math display="inline">\left|y\right| = 2^n</math> and sometimes below. The overall speed decrease as the platform's average height passes through the boundary is represented by the {{w|differential equation}} | Each time the platform oscillates through one of these boundaries, its behavior is more complicated. Throughout its cycle, the platform is sometimes above <math display="inline">\left|y\right| = 2^n</math> and sometimes below. The overall speed decrease as the platform's average height passes through the boundary is represented by the {{w|differential equation}} | ||
| Line 53: | Line 53: | ||
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.) | 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 | This bug does not affect the sinking platforms in [[Lethal Lava Land]] because they are already located at {{var|y}} = 0. | ||
==References== | ==References== | ||