SM Run-Ahead Decision

Aug 4th, 2018
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Retroarch's Run-ahead feature can be summed up from the article here (http://filthypants.blogspot.com/2016/03/using-rollback-to-hide-latency-in.html):
  3. "The way it works is whenever the player's input changes, you roll back one frame and apply the new inputs retroactively and then emulate two frames to catch back up. This makes your inputs go into effect one frame before you actually pressed the button(s)."
  5. To re-iterate, when your input changes, Retroarch rewinds your game by a frame then applies your new inputs and advances frames to account for that. It rewinds then fast-forwards.
  7. If an emulator is rewinding and fast-forwarding frames to implement inputs, then it is not emulating the hardware properly. If an advantage such as this would be allowed, then the priority would be not to play the proper, accurate game as released by Nintendo, but a modified software to run the game.
  9. As such the moderators have talked about it and concluded that it should not be allowed. Henceforth all Retroarch runs must be done with Run-Ahead disabled.
  11. We're working to update Deertier's rules eventually, but at the moment Speedrun.com's ruleset should be followed.
RAW Paste Data