View Page Source

Revision (current)
Last Updated by adelikat on 1/8/2022 1:07 AM
Back to Page

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.


!! 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 [EmulatorResources/Features|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.

!! Emulation stability

The nature of this site is that of an archive. The movie files will be preserved on this site as long as possible. Thus it is desirable that:
* The files will be playable on future versions of the emulator [1].
* The files will be playable on the emulator regardless of platform (Linux, Windows), or environment (plugins, etc)
* The emulator will still be around when the hardware/operating system for which it was compiled for has expired (source code should be publicly available, standards-compliant and portable).

In that sense, we favor mature emulators over those which are having new incompatible versions released every month.

!! 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 available for Mac OSX.
* It should be customizable (source code included).

Sometimes we let some of those requirements slip, but doing so will increase
the work our [Staff|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:
* [EmulatorResources/Features]
* [Laws Of TAS]

[#1]: [user:Nach]: Some statements here are ambiguous and also don't seem to be as thought out as they should be. "Changes in emulation speed and loading/writing savestates must not be written into the movie", why not? So what if that information is there as long as it is ignorable for playback? "The files will be playable on future versions of the emulator", is unreasonable. Future versions of emulators, and I just don't mean rerecording feature updates, but actual emulation updates will make old movies desync. Unless emulation core microcode is going to be stored in the movie file to be played back with, future compatibility is not really possible. The best you're going to get is maybe an emulator which splits each version of it's entire emulation core into one little package with a consistent interface, and have each new version bundle every previous emulation core package, and use the proper one on video playback. Such a system also means that if a graphics bug was fixed in a particular game, playing back an old video won't achieve the benefits of the new version. "If it runs on Windows, it should use the Windows API that allows codec selection", why must it use the Windows API for such a thing? If the codec is selectable, and has access to MPEG-4 codecs and x264, and any new codecs that we'll deem appropriate, I don't see why it must use the Windows API to do so. IMO, if it's an MEncoder frontend and can select from a list of MEncoder supported codecs, I don't see the problem.