Emulation speed may be adjusted, because the process, that looks uniform and seamless, is actually gradual. A game is emulated frame by frame at a rate determined by the emulated platform. Your computer usually takes less time to prepare every next frame, than the original system took, so emulation gets internally suspended to match the original framerate.

That gradualness allows pausing emulation, which freezes the game at the state it was at. And if we can pause, nothing prohibits us from unpausing it and pausing back any time we wish, say, next frame. This is how Frame Advance was born. Once you press the key assigned for frame-advancing, the game emulates one more frame and gets hanged up on pause.

Being able to emulate each frame on command allows the desired precision of actions and gives time to examine everything before entering input. See how exactly emulators provide Frame Advance.

Some controllers, especially analog ones, are difficult to operate precisely. Emulators offer the option of manually specifying the exact input that you wish to use. Not only does this remove limitations in the input hardware used to make the movie, but it also allows exact values to be picked, allowing for perfectly controlled movement.

2d control sticks in particular benefit from this by allowing exact direction and velocity control.

Emulators record your play to input files, that allow to navigate through, edit, replay, share. These are traditionally called movies, though they have nothing to do with video. They provide enough determinism to make games react similarly to similar input each time it's replayed. Input file is a foundation of tool-assistance.

When you start movie recording (refer to Emulators Usage for how to access this function), you must record from the game's initial state it has on load (Power On), that would be a base for further manipulations. You don't start a movie from a savestate normally, because this way it won't have a preliminary input to approve that game state. In some cases though, it's allowed to start from a savestate, when your movie requires unlocking some special mode. Then you record how you unlock it from load, make a savestate, and start recording from such approved one.

Each savestate represents a complete snapshot of a game memory, that normally changes depending on your actions gradually. It can be stored (saved) and restored (loaded), and loading it will instantly bring the game to the saved state.

Competently combined with movies, savestates create a whole new concept - stable rerecording. That means it gets remembered what frame the state was saved on, what input preceded it, what values some useful counters had at that point. This allows to restore not just the game state, but the entire movie state as well. Good emulators also allow undoing saves and loads. The final trait of savestates used for tool-assistance is that we have 10 slots for them (some cases allow even more), not just one.

You should have one savestate which you use extremely often (termed "quicksave" although any savestate is arguably a quicksave). There should be a 2nd savestate trailing the quicksave that can be used for backup. Other savestates are for replaying your movie and/or resuming recording at some point. You should have at least one savestate around the beginning of the level that you are on. Here is how experienced TASers use their savestate slots.

There are two systems of saveslot switching. The first system is a couple of keys used to change the saveslot number and a couple of keys to save and load. The second system consists of 20 keys, with each pair controlling save and load of a distinct saveslot. Emulators have either the second system, or both. Default keys vary by emulator.

Our emulators internally allow to show some useful info on top of the game window.

Autofire (turbo-buttons emulation) causes the emulator to press a designated button every second frame. Autohold causes the emulator to press the button every frame. There may be many other types of autofire options.

Autofire is strictly unnecessary for making TASes, as frame advance is the most precise form of slow motion (lag or some limit can break autofire patterns). Autohold may be necessary when pressing a mass of keys that will likely cause some not to register (depends on a keyboard).

Assign keys so that one hand takes care of directional input (up, down, ...), the other hand common button input (A, B, ...). Assign keys that are rarely used out of the way.

The frame advance button should be close to the hand that is least involved (usually the hand using directional input). The quickload button should be close to the other hand. The quicksave button can be anything as long as it is not easy to press by accident. All other savestate buttons should be out of the way.

Avoid assigning keys to the control keys on your keyboard. However, in cases when a keyboard doesn't allow too many keys to be pressed at once (which is what we're doing while recording movies), frame advance can be assigned to Ctrl or alike, to let it work above the limit. Sometimes using arrows for D-pad also helps with that problem.

It is recommended to change the frame advance key once in a while, unless you are fine with wearing that button out.

FractalFusion uses, for example:

Refer to that thread for which control schemes our TASers actually use.

Most games have a title screen requiring you to push a button (in general or a specific button) to advance to the main menu or to the game itself. As an exercise in basic tool-assistance, try to find the first frame at which pushing a button will advance the game in this fashion. This works as follows:

Use of more save states during this process is encouraged, as it can help things go considerably faster.

Much of TASing can be boiled down to this basic procedure - repeating a short segment over and over again until the best possible result is achieved. Here the desired input is relatively trivial (finding the best frame at which to push one button).

I loaded a previous savestate by accident; what do I do?

Load your quicksave, or the most recent savestate that works. This is a feature called bulletproof rerecording, which protects your movie. There also might be an option to undo last save or load.

Available only in some emulators (TODO: elaborate). Where it's not, there probably is a lua script for that.

While recording, load your savestate and enter the input you want for player 1. When you're satisfied, pause the emulation without saving and cycle through the different input tracks until you reach player 2. The default keybind for this action is ">" (shift + ".") and "<" (shift + ",").

Then simply load that same savestate again and enter player 2's input. During this time, player 1 will automatically repeat the input you entered previously. When you're finished, you can then save over the savestate and both inputs will be recorded.

In this video, dwangoAC guides Sand_Knight through everything from the basics of creating a Tool-Assisted Speedrun movie file to using frame advance and other tools like TAS Editor within FCEUX. This is also a good overview of various techniques used to route a game and test a game's mechanics. Basics like performing a binary search are included as well as a deep dive of various topics such as a demonstration on how to recover from accidentally advancing more frames than you intended to before making a savestate. At the end the different techniques we used get put to the test in a head-to-head comparison of who had the fastest time.

This video features an actual TAS session by Aglar, where he is TASing in Gens with Sonic HeadsUpDisplay script.

TASing in DeSmuME recorded by paul_t

TASing in Mupen64 done by Rising Tempest