How Super Mario World Speedrunners Beat The Game in 40 Seconds By Writing Code With Koopa Shells
It doesn’t matter how airtight you think your game is; speedrunners will prove that it’s not, and there may be no better example than Super Mario World, where top speedrunners literally write code in-game using Koopa shells, eggshell particles, and clever controller manipulation to beat the game in just over 40 seconds.
In January of 2015, speedrunner Sethbling completed the first-ever “0 Exit” run of Super Mario World in just under six minutes, a speedrun category that requires players to beat the game, reaching a total of zero level exits. Sounds impossible, right? How could a player possibly complete the game without completing even one level? Well, it’s easier said than done, but it involves a glitch called “arbitrary code execution”, or ACE for short, the same glitch used by Ocarina of Time speedrunners to complete the game in under ten minutes, which allows players to trigger the end-game credits early.
The path has been heavily optimized since Sethbling’s six-minute completion, with the world record time sitting at just 41.022 seconds, by the Brazilian speedrunner Furious, who spends more time navigating the menus before starting level one than he does playing it. That’s how incredibly quick this path is. That particular run isn’t on YouTube, but Sethbling’s second-place 41.350 time is, and can be watched below. Don’t worry too much about what he’s doing to set up the ACE just yet, as it will seem like complete nonsense. I will do my best to give a breakdown of what is happening beneath the video.
How Does It Work?
Computer memory is divided up into blocks with associated addresses, that store particular information. One block could, for example, store the x-position of a Koopa shell that is on screen, while another block could store the value associated with any power-ups that Mario may have at that time. If either of these parameters are changed, the value in that block of memory will be updated. Normally, the game knows exactly what blocks of memory to reference and when to do so, as well as what lines of code to execute in response to certain actions or inputs, but what if you accomplish something in the game that the developers did not intend to be possible? What lines of code will the game jump to in response?
This particular ACE is accomplished by tricking the game into getting Yoshi to eat a Chargin’ Chuck. As this is not intended to be possible, there is no specified spot in the code for the game to jump to in order to issue a response, and it instead jumps to a portion of the memory called “open bus”. This isn’t mapped to any devices, and will instead return the contents of the memory data register, which just contains the last written memory value. These memory values can be altered by placing certain sprites at certain places in-game, and then eating the Chargin’ Chuck will trick the game into executing said memory as if it were code. By writing code that sets the game’s mode to “credits”, speedrunners are able to warp to the end-game credits in 40 seconds.
Now let’s get really technical. Upon executing the Chargin’ Chuck glitch, the game jumps to address $014A13, which is not mapped to any memory and thus jumps to open bus. The open bus will contain $01, as that is the highest byte of the address it just tried to jump to. The first instruction will be as though there is a continuous sequence of 01’s and will jump to an ORA ($01, x) command, where x just so happens to be the sprite slot of the Chargin’ Chuck. Only 12 sprites can be loaded at any given time, meaning x can be between 0 and 11. In this case, it’s 9. The indirect look-up address is thus $01+9, which in base-16 (hexadecimal) is equal to $0A. This is the next address the game will look at, and it corresponds to the high byte values of Yoshi’s y and x-coordinates, in this case $0107. ORA ($01,x) has now become ORA ($0107), which returns $17. The second instruction is then ORA [$017], y.
That’s a rough example of how the open bus process occurs. For a technical breakdown of the entire sequence, check out Sethbling’s pastebin. For now, I’ll skip the technical jargon and simply explain what the speedrunners need to set up in order for the code to eventually reach the credits.
Runners play with two five-player multitaps plugged into their console, each with two controllers plugged into the first two ports. Controller one in port one is the gameplay controller, while the other three controllers have specific buttons held down with elastic bands to manipulate the y-value that the aforementioned ORA command references. Runners will pick up the red shell, jump and land on the left side of the fourth Koopa, leaving behind a shell whose x-coordinate will later be referenced. Runners then use a horizontal block duplication glitch on the Yoshi block, then hit the original Yoshi block and run left.
Once the camera starts following Mario, runners stand still and quickly turn around twice. The x-position of this turn-around animation will be referenced in the ACE. When the second Yoshi spawns, if the screen is scrolled to the exact right pixel, the eggshell fragments will despawn at a very specific height. The y-velocities of the bottom left and top right fragments as they despawn will too be referenced in the ACE. The red shell is dropped, then the screen is scrolled all the way to the right, and Mario runs 17 pixels to the left. An upkick is performed. The x-position of the splat animation will be referenced in the ACE.
The player then rides Yoshi to the right, eats a red shell, and performs the item swap glitch to trick the game into making Yoshi eat a Chuck. The x-position of Mario on the frame before he is eaten will be referenced in the ACE. If all is done properly, the game will warp the player to the credits. It’s that easy!
Source: Read Full Article