Re:A look at inner workings of Joycon and Nintendo Switch
by aji on Monday November 06, 2017 @06:23PM
(#15639878)
the importance of console verification is to make sure a TAS isn't relying on any emulator bugs (such as timing, uninitialized memory, etc) and would theoretically be possible on the actual hardware. it also speaks to the accuracy of the emulations themselves
Re:A look at inner workings of Joycon and Nintendo Switch
by zzazzdsa on Tuesday November 07, 2017 @07:19AM
(#15642766)
For a specific example of something like this being important, remember the (very impressive) Watch for Rolling Rocks in 0.5 A presses video from a couple years ago? https://www.youtube.com/watch?v=kpk2tdsPh0A (For the uninitiated, this video presents a TAS of Super Mario 64 which beats the level Watch for Rolling Rocks without pressing the A button outside of keeping it held from entering the level.) It turns out that the route presented in the video actually fails console verification, since the crazy things he does trigger some annoying FPU crashes on console, but not on emulator. There is a happy end, though: a fixed route was published after this was discovered, and it passes console verification just fine (assuming the inputs dont desync over the 13 hour run)
http://tasvideos.org/TASBot.html
In addition to TASBot, there's also a growing practice of using physical rigs to "verify" tool-assisted runs:
http://tasvideos.org/ConsoleVerificationGuide.html
This isn't generally regarded as necessary for a TAS to be valid, but it allows it to work on TASBot and similar rigs, which can help it get in front of a wider audience. It also helps figure out which TAS techniques are theoretically possible in non-TAS runs.