Super Mario Bros. 3: Remote Sprite Bumping
HTML-код
- Опубликовано: 26 ноя 2024
- Have you ever wondered why the Paragoomba's hidden weakness is witnessing mushroom abuse? This video aims to explain why that seems to be the case.
$7F74 gets set during the movement functions for most (but not all) sprites in the game. With the several different functions used for movement and tile detection, it's a good idea to have a separate function to handle what happens if the sprite gets bumped. That's also why $7F74 exists at all, instead of just loading the tile below the sprite into the accumulator and comparing it to F3. This allows for one unified block bumping function, with multiple ways to move sprites and handle collision.
This however leads to an interesting side effect when a sprite has the function for what to do when bumped, though it never sets $7F74.
As an additional note, this should also work for Fire Snakes, though I was unable to make it happen in practice.
6:39
the death
That was fascinating. Great job on this one, super well explained and I'd never seen this glitch in action before. What was that canon trick you did at the start, to freeze the block's state?
Typically only one block can be changed at a time. That's why if both a kicked shell and Mario hit different blocks on the same frame, only a single block will be affected. On the last frame before the bumped block is restored, it puts the information for restoring the block in the correct place, and moves on. The idea is, on the next frame the game will use that information to restore the block or replace it with the "bumped block" block.
When the cannons rotate, the game writes to the same place as the bumped block, and runs the same code for swapping blocks for each of the tiles on the cannon being changed. Unfortunately, this runs before our bumped block restores its self, and the data has all been overwritten, so the block stays as Block F3.
It's frame perfect, but once you know how it works it's a bit easier to make a TAS with the trick.
This can also be done "in reverse" where the cannons change on the same frame you hit the block, and you can still see the Question Block behind the bumped block sprite (though it still gets replaced with a bumped block after the animation).
2:38 why aren't there number on the mini goombas?
6:27 same for the wrenches
Mini goombas, wrenches, and other objects like boomerangs / cannonballs are a different set of objects. They fill a completely different table, and so they are unrelated to the sprite slots shown in this video.
That table also includes fireballs from enemies, Lasers from the bowser statues, coins from blocks, bubbles when under water, LavaLotus bubbles, air bubbles from tornadoes or underwater jets, spike's ball, and hammer bro hammers.
I was looking for an old video where the person remotely received the card at the end of a level as it appeared on screen. Writing F3 to $7F74 did not do it. Do you have any idea what may have caused it? It was done in one of the cloud levels.
Oh boy, I have looked into that one way longer than anybody ever should have. And yeah, the speedrunner Stewie_Cartman has had a lot of strange things happen on their console, that being one of them.
I am convinced it was a hardware malfunction, and let me explain, because I have torn the code apart so much trying to find any possible way for the events that happened on screen to be reproduced.
First of all, after the mysterious events, the enemies aren't turned into coins, but the goal moves upwards. There's about a 5 byte window between those events occurring, so I was able to deduce where the PC jumped to. (about address $BF50 inside PRG_2) The only question is where from and how the jump was made.
To make a long story short, the only possible way to reproduce that is a hardware malfunction inside the code that parses jump tables. While the goal was checking to see what state it was in (0: idle, jump to $BB50) something went wrong on the hardware side of things and it stored the word $BF50 and jumped there instead. That's a single bit difference, and the only possible way to reproduce the events from that video.
Here's a binary comparison of BB and BF
BB :10111011
BF: 10111111
So the working theory is that an LDA instruction malfunctioned and set an extra bit to a 1. That's the only explanation I have found at least.
I also verified that such a jump would reproduce the events in Stewie_Cartman's video using a ROM hack. It's not reproduceable in the vanilla game, which is a shame.