This article lists conditions on which TASVideos can start accepting and publishing movies made with a new emulator for a platform without existing mature TAS emulators. As such, be wary of the fact that these rules do not reflect our expectations toward the latter.
Game-specific tools and non-emulation TAS frameworks (like libTAS) may have their own requirements significantly different from these.
Game-specific tools and non-emulation TAS frameworks (like libTAS) may have their own requirements significantly different from these.
Note: These rules are written from the site maintainer perspective — they outline the bare minimum to be able to accept and publish finished movies.
The Features page lists features desired by the players to make new movies.
The Features page lists features desired by the players to make new movies.
Table of contents
Movie files
The emulator must be capable of creating a movie (key input) file that it can later replay.
Re-recording
It must be possible to create tool-assisted movies on the emulator. This includes the absolute minimum of adjusting the emulation speed and sync-robust savestates.
- Sync-robustness means that if the same savestate is loaded 10 times, the emulation must progress exactly the same way each time. There must not be random factors other than what is included in the savestate.
- In particular, the clock of the host computer and the files present on the host computer (besides the ROM) must not affect the emulation.
- Changes in emulation speed and loading/writing savestates must not be written into the movie, or it must be possible to ignore them when playing back the movie. When a savestate is loaded, the movie must automatically rewind to the time of the state being loaded.
Emulation quality
The emulation should replicate the behavior of the original system sufficiently for the games to run without noticeable deviations in gameplay itself. This may be decided on a game-by-game basis if the overall level of emulation accuracy is deemed sufficient.
- Gameplay behavior that deviates from the original system in a way noticeable to a casual viewer in a substantial portion of emulated games is unacceptable.
- Additional or missing lag, difference in load times and fade-ins/fade-outs, minor cosmetic glitches, etc., are acceptable as they are not considered part of gameplay.
- The behavior of critical game programming elements such as movement physics and the random number generator should at least try to feasibly match the original system while keeping the emulation deterministic. In practice, deliberate accuracy concessions are inevitable but they should remain reasonable.
- For simple seeds derived from the system state (e.g. power-on RAM state or system time), providing zeroed values by default or as an option is standard practice.
Movie authenticity
On this site, movies are usually made in the form of speed records that will be challenged by other players. It is therefore mandatory to provide a common ground for all movies of a particular system. That common ground is usually decided to be power-on or reset.
- The movie file must indicate whether it begins from power-on or a savestate.
- The indications must be tamper-proof; for example, if it indicates that it begins from a power-on, it must not load the savestate after resetting.
- The movie should store the player's input, not the emulation results (such as CPU state changes or video frames). Ideally, only the input and the game (and, in some cases, system configuration) are required to reproduce the playing session.
- The CPU state changes and/or video frames are easy to tamper with, destroying the credibility of the movie.
Timing
The movie file must indicate the length of the movie in a way that can be derived into fractional seconds without access to the game and emulator.
- For movie specifications only allowing frame-based input with a constant system-wide frame rate, the number of frames should be reported in the movie metadata, and this number should be verifiable by parsing the input stored in the movie proper.
- For movie specifications based on polled or sub-frame (e.g. cycle-level) input, or using variable frame rate, or otherwise making it fundamentally impossible to verify the duration without playing it back, only the metadata is necessary. In this case, all the relevant applicable information (e.g. exact duration down to fractional seconds, cycle count and such) should be stored in the metadata.
Other movie information
All information contained within the movie file must be parsable and interpretable without access to the game or the emulator.
- Complete documentation of the movie file format is required.
- We strongly encourage including a UTF-8 text field for the author in which they can input their name, although it's not strictly required.
Accessibility
The emulator must be freely available for download from a public repository without subscriptions or fees.
- It should be available for at least Windows or Linux; ideally both. Other systems (e.g. MacOS, Android) are not sufficient in isolation but are a welcome bonus.
- It should be customizable: source code must be provided with a license permitting modification and redistribution. Build instructions should also be provided.
- Different releases should remain available for as long as possible: not only because people may still be using them (so we'll need to sync their movies), but also because replaying them years later may be needed for something (encoding, comparison, etc.).
Sometimes we let some of those requirements slip, but doing so will increase the work our encoders and judges have to do, so it is preferred that these rules are met.
Audio/video dumping features
It should be possible to create an A/V file of the movie playback using the emulator and pick the codecs to use for dumping.
- It should have proper audio/video sync.
- The duration of generated audio data should match the duration of generated video data regardless of possible framerate changes.
- The reported framerate of the video file should correspond to respective platform framerates.
- All audio samples produced by the emulated system should be dumpable in principle. This should not be affected by dumping speed or the emulator's behavior outside of the A/V dumping context. Before dumping, audio may be resampled internally to a standard sample rate (usually 44.1KHz) using a high-quality resampling algorithm.
- Either video frames or audio samples may be sacrificed internally by the emulator to maintain A/V sync. Prefer sacrificing video over audio by default or provide the option to choose between the two.
- Each frame in a dumped video should match the resolution natively rendered by the emulated system by default or as an option. If applicable, the emulator must handle resolution changes during dumping; the standard practice is splitting the output files.
- If the host computer is not fast enough to render at 100% speed, it should still be possible to force the emulator to dump all rendered frames without skipping and without duplicates — whether natively or with the help of a third-party application.
- If the emulator allows capturing UI elements such as frame numbers and other system messages into the video stream, there should be an option to disable this behavior when dumping.
- Ideally, both video and audio streams should be stored within a single container as the result of dumping, but this is not strictly required. Multiple audio sources, if applicable, may be mixed together internally or dumped as separate files.
See also: