I don't think the graphical corruption in the credits will be a problem, since the fact that it beats the game can be confirmed by continuing and seeing your inventory is now full of p wings.
Am I to understand that the 2-second SMB3 TAS can't be submitted yet? Is it just because emulators are lacking sub-frame inputs or is there also an accuracy issue?
It's because emulator input file formats are incapable of representing sub-frame inputs. FCEUX can handle them if they're input via Lua (and, although quite possibly not perfectly accurate, is accurate enough to emulate the run in question); however, there's no way to specify the input in question in an input file/recording.
I would prefer clean credits over glitched credits. But that is just my personal opinion.
I really did not expect something like this to be possible. There has been some 1 second TAS because of some konami code and maybe savegame abuse, but I never expected solid games like SMB3 to be beatable in 1 second.
I'm interested in reading more info about the DPCM glitch. It hasn't been explained thoroughly here yet, I think. What is DPCM anyway?
Is it that the game checks for input multiple times a frame and makes sure the input is the same; if it isn't, it polls for more input as long as it always changes?
Is something like this viable for other consoles? If yes/no, why?
As far as I understand, DPCM is the unit on the NES that play sampled sound.
There is a bug in early version of the NES that corrupt data read from the controller. Many games have a workaround. They fetch data from the controller until it reads the same value two times in a row.
If you change every time the controller state, it goes in an infinite loop and corrupt things.
I don't know the details about the corruption.
In SMB3, at one point, the NES began to execute a part of the memory that is the same at the part where the controller state is stored. You can then execute arbitrary code, as what was done in SMBW.
Am I right ?
Is something like this viable for other consoles? If yes/no, why?
The glitch requires the game to use a particular sort of controller read routine (that waits for a stable value on the controller). The NES has a glitch that makes this sort of read routine useful, so we'd expect many NES games to have the glitch. Other consoles don't have the glitch in question, so games don't have much of a reason to use the glitchy read routine; it's possible that games could use it for some other reason, but seems fairly unlikely. As such, I'd expect the glitch to be mostly NES-specific.
I think it's also worth mentioning that not every game uses the DPCM channel, and those that don't also don't need to use the controller read routine that enables this kind of glitch (of course this needs to be investigated in a case by case basis.)
Battletoads for example, another game with a notible game end glitch, does not enable the DPCM channel and only polls the controller once per frame.
FCEUX can handle them if they're input via Lua (and, although quite possibly not perfectly accurate, is accurate enough to emulate the run in question); however, there's no way to specify the input in question in an input file/recording.
Can I have the script?
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
FCEUX can handle them if they're input via Lua (and, although quite possibly not perfectly accurate, is accurate enough to emulate the run in question); however, there's no way to specify the input in question in an input file/recording.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
feos, it's really awesome to see you pushing for emulator improvements and working towards them yourself. As someone who cares but doesn't have anything like the time, i really, really appreciate your efforts.
Subframe input in fceux this year or next year would be amazing to see.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Thank you, these explainations are very clear. Basically, it's because the levels that has slopes have a different collision detection for all tiles. And Mario is ejected upwards very fast instead of right, yes, I could see that, in the level 6-8, at the beginning, I removed 2 of the bricks, I went behind them and Mario teleported on the slope just above.
The shell code execution? This was presented on the streams when it was being created, so I think I can explain it.
You have to position the sprites of the enemies (which needed to be turtles IIRC) in an specific X coordinate so that it gets interpreted as ASM. The enemies de-spawn when they are off-screen (and their values will remain for some time) but other enemies may spawn in the addresses you just set, so you have to be careful on how & when to scroll the screen. There was another value that had to be manipulated, but can't remember what was it...
As been mentioned it's the same method as used in the title screen ending glitch.
It abuses the fact that SMB3 reads input multiple times per frame and compares the reads until they match to get around the DPCM bug in the NES.
So by just sending alternating inputs each read the game will get stuck in the controller reading loop for as long as these inputs are alternated, causing all kinds of bad behaviour with NMI re-entering on top of itself corrupting the stack. (MMC3 IRQ for the statusbar split also plays a part in SMB3).
In the end this makes it possible to trick the game into excuting RAM contents as code, and in RAM the koopa shells was used to write a small loader that reads inputs, stores it in RAM and eventually executes those inputs. And from there on total control is achieved.
When I get the code cleaned up a bit, I'll post all the source code and tools used for the AGDQ 2017 ACE.
