This feature stores a complete movie file in each savestate. If a previous savestate is loaded by accident, the movie is not ruined, but can be recovered by loading the last savestate. This is a very important safeguard, as savestate errors are frequent.

Since players rarely (if ever) record a movie all in one sitting, emulators should be able to resume recording of a movie from a savestate.

It happens many times that a player will save a state and immediately wish they hadn't, and desire to recover the state they just overwrote. An emulator should back up the most recently overwritten savestate to allow limited undo capabilities. An emulator should also back up the current state (whether it has been saved or not) whenever another state is loaded, so that it can be reverted to the state it was in before the load occurred.

Visualization of all alternative timelines in the current TAS, this helps TASers to have a clear picture of their work. The visualization should display which savestates belong to which timeline and where is the currently played frame of the movie.

The ability to pause and advance the emulator by a single frame is essential for achieving maximum precision. Most people seem to prefer that if you hold the frame advance key down, the game will advance at the current speed.

Not everything that is difficult to play in real time requires the precision of frame advance. Emulators should be able to emulate at 50, 25, 12, 6, and 3 percent normal speed (and possibly other speeds).

Lots of games include long periods of time where input from the player is not allowed, for example, level transitions or cinematic segments that advance the plot. Emulators should be able to emulate faster than real time to allow skipping through these portions. This includes having a button dedicated to emulating as fast as possible, and the ability to set the emulation speed to (for example) 150, 200, 300, 400, or 800 percent normal speed.

Like frame advance, but also tests for which frame to switch button presses after holding the previous button(s). Simplifies the process of repeatedly loading a save state to find the minimum number of frames before the game allows a desired outcome. To support this feature, it is practically required that the emulator also supports rewinding^[17] first.

Most people like to remap game buttons and emulator functions to keys other than default, or to a gamepad. These include pausing the emulator, selecting/saving/loading a savestate, frame advance, etc. Ideally, joypads should be supported in addition to the keyboard, for those who wish to use them for emulator features without going through an external mapping program.

In read-only mode, loading a savestate will cause the movie to begin playback from that savestate. Out of read-only mode, loading a state will resume recording from that point. Saving a state will create a savestate without changing the movie file in either mode. Of course, the toggle must work even while the movie is in the process of playing or recording.

The emulator should allow players to display useful information while playing, such as the frame counter or which buttons are being pressed.

It helps movies to be published more easily if the emulator can export to AVI (using a user-selected encoding scheme) during playback. A frequently-requested feature is for the AVI to be split into multiple files if it approaches 2 gigabytes, because larger AVI files tend to be corrupted.

When making a movie, it is helpful to be able to search through memory to find and display values at specific addresses, or to search for a specific value. This is most useful for boss fights, but also for optimizing movements and randomized resource usage. Preferably it should be possible to watch known relevant values while the game is running without needing to navigate through a dialog every frame to see the numbers.

It's very convenient if the emulator allows players to set a button to be pressed every other frame, or every third frame, etc. Preferably the autofire should take effect on the frame it is activated individually of other buttons, so that it is possible to set two buttons to alternate, and it should be possible to autofire any button on any player's controller.

For games that need a button held down for a long period of time (such as the "run" button) or for making 2-player runs easier to make, the ability to simply toggle any button on or off (so that it doesn't need to be manually held down) is surprisingly helpful.

The ability to replay a frequently-used key sequence into the movie currently being recorded. Very few emulators support this although several people have requested it.

An emulator should transparently save a state every 5 seconds or so, and keep track of the last 20 or so states so that a movie can be rewound, in effect. This is especially convenient for people watching the movies who want to reexamine a bit of the action without replaying the whole movie from the start. The number of states and frequency of saves should be configurable. A nice extra feature is for the emulator to use these (or other) rewind states to allow for (possibly unlimited) single-frame rewinding.

adelikat: Any emulator with Lua capability can easily be scripted to do this. As such these emulators don't need (and probably won't have) a hardcoded version of this. For those emulators I put them listed as partially implemented.

TODO: expecting emulation experts.

It does not need to be accurate (as that would be likely to introduce nondeterminacy without using a savestate). Its result should be, if inconsistent, reproducible.

Some games have 'dark' areas that are unplayable until your character retrieves a certain item, such as a torch or night-vision goggles. If specific sprite layers can be disabled, these areas may become playable without the required item. It can also be used to reveal hidden parts of the level to find hidden items or better understand the level layout.

• This feature is really of lowest priority. Analyzing the game by watching the screen output is rather superficial approach. Use Lua for displaying hidden data. Use VG maps/atlases for understanding the level layout. --AnS

Most emulators don't do this. It would be nice.

• What does this actually mean? How can we find out if an emulator emulates soft resets accurately? What are soft resets, anyway? -Bisqwit
  • A soft reset is what happens when the player hits the reset button on the console (as opposed to a hard reset, which is achieved by turning power off and back on). These would more accurately be called warm resets and cold resets, because they are both hardware features. Certain games exhibit different behavior between a warm reset and a cold reset, and at least one Sega Genesis game (X-Men) requires a warm reset in order to complete it. --upthorn
    • Some consoles and handheld systems support soft-reset via button-combinations. Are they counted? --klmz
      • I think this paragraph really means emulating subframe resets. --AnS

A powerful tool that allows the user far more control over how the emulator behaves.

Whenever the a game fails to poll for input, this counter would increment. This is useful for minimizing lag, and optimizing menus/screen transitions.

An extension of the lag counter feature. This would be a toggle that allows frame advance to advance to the next frame in which input is polled.

A Piano Roll-based editor allowing quick movie splicing and nonlinear editing of the movie Input. Bonus points for implementing extensive data visualization (Lag log, Hot Changes, Markers, etc).

If the emulator lets the player set options that might affect playback, such as sound frequency or PAL/NTSC, these settings should be saved in the movie file and automatically loaded during playback.

It is also useful if the movie files stores data such as:

• ROM Name
• ROM Checksum
• Emulator version
• Number of rerecords
• A user-configurable comment (such as the author's name)

And the emulator should alert the user of any possible errors on playback from these values mismatching, such as playing back the movie using a ROM that has a different checksum than the movie was recorded with.

Note that the ROM checksum should be written in a way that allows reliably distinguishing a wrong ROM from a correct one. A CRC32 or MD5sum of the entire ROM's contents (including possible trainers) would be preferable. It should not be just a copy of some bytes from the ROM, because that does not enable reliable detection.

Possibility to start recording from power-on with no savestates or RAM or SRAM stored within the movie file, is necessary to provide a fair, common ground for competitive purposes.

It is also a requirement on this site.

The movie format should support recording of non-standard input that might be important for certain games (gun accessory, motion sensor, light sensor, etc.).

Supports recording of soft resets, or hard resets or power cycles that don't clear SRAM.

TODO: descriptions

Easier to slice and concatenate input.

Easier to modify a segment without affecting the others.

Note: FCM uses offsets from previous input events.

Note: FCM records toggles instead of the current state of the input. Do PXM and PJM record cheat/hack toggles?

TODO: descriptions