Conditions on which the TASvideos site can start accepting
and publishing movies for a new emulator.
Note: These are rules from the site maintainer perspective.
The page EmulatorResources/Features lists which features are desired by the players.
The page EmulatorResources/Features lists which features are desired by the players.
Table of contents
Movie files
Obviously, the emulator must be capable of creating a movie file that
it can later replay.
Re-recording
Naturally, 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 in 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 [1]. When a savestate is loaded, the movie must automatically rewind to the time of the state being loaded.
Other tools favored for TAS making are listed on Desired Emulator Features.
Emulation quality
The emulation should be as close to the original product as possible.
What qualifies as "enough" can only be discussed.
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 (CPU state changes or video frames). If the emulator is robust, only the input and the game 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.
- The movie file must indicate the length of the movie in a way that can be derived into seconds without access to the game/emulator.
- However, because the indicated length is easily changed with an hex editor, it should still be possible to programmatically verify that the indicated length actually matches with the amount of input data (i.e. access to the emulator and the ROM must not be required). Or, the emulator should reject movie files where the indicated length doesn't match the actual length of the movie.
Other movie information
By tradition, we require also that the movie indicates the
number of rerecords used in creating the movie, and includes
a field for the author in which they can fill their name
(preferably utf-8 encoded to be international-friendly).
All information contained within the movie file must be parseable
and interpretable without access to the game or the emulator (complete
documentation of the movie file format is required).
Accessibility
The emulator must be freely available via Internet without subscriptions or fees.
- It should be available for Windows.
- It should be available for Linux.
- It should be customizable (source code included).
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
those rules are met.
Possible to make AVI
It should be possible to create an AVI from the emulator.
- If it runs on Windows, it should use the Windows API that allows codec selection [1]. It should also not have a 2 GB file size limit.
- If the emulator runs on Linux and its source code is available, our Linux-friendly encoders can create their own AVI dumping tools.
It should have a proper audio/video sync.
- The number of video frames per second should be some known number. (Usually ~60 on NTSC systems, ~50 on PAL systems.) If the host computer is not fast enough to render at 100% speed, it should still be possible to force the emulator to render all frames without skipping and without duplicates.
- The amount of audio stream generated per each video frame should be consistent regardless of system load. Without that, there is no A/V sync.
See also: