1,811
edits
Crash: Difference between revisions
Adding the second known source of sound glitch.
Tastebuds. (talk | contribs) m (fixed typo) |
(Adding the second known source of sound glitch.) |
||
| Line 8: | Line 8: | ||
| Exceed the [[Objects#Object Limit|object limit]] || style="background-color: #ffb65e"| N/A || This is technically not a crash as the game developers accounted for this scenario and made the game enter an infinite loop. However, this infinite loop has the same symptoms as a crash and is one for all practical purposes, so it is included here. This "crash" can be done via a variety of methods including cloning, hat duplication, monty-mole pellet build-up, or money-bag duplication. | | Exceed the [[Objects#Object Limit|object limit]] || style="background-color: #ffb65e"| N/A || This is technically not a crash as the game developers accounted for this scenario and made the game enter an infinite loop. However, this infinite loop has the same symptoms as a crash and is one for all practical purposes, so it is included here. This "crash" can be done via a variety of methods including cloning, hat duplication, monty-mole pellet build-up, or money-bag duplication. | ||
|- | |- | ||
| | | Sending the camera into a [[Parallel Universe|PU]]|| style="background-color: #ff9696" | Floating-Point Overflow || | ||
|- | |- | ||
| Walking at PU speed for only a portion of the 4 quarter steps on a [[frame]] || style="background-color: #ff9696"| Floating-Point Overflow || | | Walking at PU speed for only a portion of the 4 quarter steps on a [[frame]] || style="background-color: #ff9696"| Floating-Point Overflow || | ||
| Line 44: | Line 44: | ||
| Entering Wiggler's Cave on the Disk Drive version || style="background-color: #ff9696"| Floating-Point Unimplemented Operation || When Wiggler is initialized, his health value is 1024 for a single frame before being reset to 3. Wiggler uses his health to index into a table to get his speed (to move faster when at lower health); 1024 causes it to index out of range and read a denormalized floating-point number as his health, which causes an unimplemented operation exception since the N64 does not implement any operations on denormalized floats except comparisons. | | Entering Wiggler's Cave on the Disk Drive version || style="background-color: #ff9696"| Floating-Point Unimplemented Operation || When Wiggler is initialized, his health value is 1024 for a single frame before being reset to 3. Wiggler uses his health to index into a table to get his speed (to move faster when at lower health); 1024 causes it to index out of range and read a denormalized floating-point number as his health, which causes an unimplemented operation exception since the N64 does not implement any operations on denormalized floats except comparisons. | ||
|- | |- | ||
| Standing in the | | Having an object too far away from the camera make a noise (JP only) | ||
| style="background-color: #ff9696" | Floating-Point Unimplemented Operation | |||
|When a noise's pan is determined, it uses the position of the object to calculate the pan. When the object's absolute z-position relative to the camera is large (>= 22000 units) and the x-position relative to the camera is very negative (<= -66000), an index for the pan will be generated outside of the bounds of the array for the pan. When the value outside of the array is an invalid float, the audio thread will crash (sound glitch). Additionally, when the x value is negative enough, there will be two out-of-bounds array reads. | |||
|- | |||
|Standing in the camera's position|| style="background-color: #ff9696" |Floating-Point Division-by-Zero||When Mario stands in the same position as the camera, the game will crash due to a division by zero error.<ref>[https://www.youtube.com/watch?v=vK16L2J0la4 "Faster fastest crash in BoB" by Madghostkek]</ref> | |||
|} | |} | ||
| Line 50: | Line 54: | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
! Cause !! Exception Type !! Notes | !Cause!!Exception Type!!Notes | ||
|- | |- | ||
| Have too many 3D models on screen at once|| style="background-color: #fffca8"| Invalid F3D command || The main display list buffer has two sides, the left side holds F3D commands the game runs, and the right side holds allocated buffers for matrices. When an object's graphics are drawn, 16 bytes are used from the left side and 64 from the right side for each separate 3D model from the object. These two sides overlap when there are too many of these models on screen, leading to both sides being overwritten with garbage data and invalid F3D commands. | |Have too many 3D models on screen at once|| style="background-color: #fffca8" |Invalid F3D command ||The main display list buffer has two sides, the left side holds F3D commands the game runs, and the right side holds allocated buffers for matrices. When an object's graphics are drawn, 16 bytes are used from the left side and 64 from the right side for each separate 3D model from the object. These two sides overlap when there are too many of these models on screen, leading to both sides being overwritten with garbage data and invalid F3D commands. | ||
|- | |- | ||
| Moving the camera immediately when entering [[VCutM]] || style="background-color: #fffca8"| Invalid F3D command || The object that spawns the rotating checkerboard platforms in VCutM references a model that doesn't exist. Normally this isn't a problem, since it's not on screen so it's culled before any damage occurs, and it despawns 1 frame after loading the level. However rotating the camera on the first frame, right before it despawns, it just barely comes into view. The non-existent model ends up sending invalid F3D commands to the RCP. | |Moving the camera immediately when entering [[VCutM]]|| style="background-color: #fffca8" |Invalid F3D command||The object that spawns the rotating checkerboard platforms in VCutM references a model that doesn't exist. Normally this isn't a problem, since it's not on screen so it's culled before any damage occurs, and it despawns 1 frame after loading the level. However rotating the camera on the first frame, right before it despawns, it just barely comes into view. The non-existent model ends up sending invalid F3D commands to the RCP. | ||
|} | |} | ||
==References== | ==References== | ||
<references/> | <references /> | ||
<!-- Category --> | <!-- Category --> | ||