Movie files

• Enough information must be provided about the movie file format to create a parser.
• A minimum of one staff member must be able to sync somebody else's movie made on a tool in order for it to enter consideration at this time.
  • Sync should be from beginning to end.
    • Savestates CAN be used to help guarantee sync in cases of instability but the result should still follow that of a single uninterrupted playthrough as we do not accept segmented tases at this time.

Gameplay authenticity

• 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 game while keeping it 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.
• Any deliberate deviations from standard gameplay should be documented for the sake of transparency.

Movie authenticity

• It should be clear if a movie starts from power-on, Save RAM or a savestate.
• If any gameplay state is stored in the file, the tool must be able to verify the legitimacy of said gameplay state at runtime.

Timing

• 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.

Accessibility

• 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.).

Audio/video

• If internal dumping tools are provided
  • It should ideally have proper audio/video sync. Audio drift (progressively desyncing audio) can be fixed in AviSynth.
    • 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 tool allows capturing UI elements such as frame numbers and other system messages into the video stream, there should ideally 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.
• If internal dumping tools are not provided:
  • The game should run smoothly enough to produce quality video with OBS Studio.
    • If the game normally doesn't run smoothly, it is not expected that the tool would fix the performance problems.

• EmulatorResources/Features
• Laws Of TAS