Table of contents
As stated, a movie is the final "input file" that the user creates. This file should follow certain conventions as documented here. There are 3 basic sections, header, savestate, and input log.
In addition there is also the decision of the type of file used, binary, text, or other options such as xml. The pros and cons are discussed in this section. Also described are various do’s and don’ts for planning a file format.
Header
A movie’s ability to sync to the end is determined by many factors, the header’s primary purpose is to document all these factors. These include:
Emulator version
Different emulator versions have different sync compatibility, it is important to store this so a user can know the proper one to play the movie on.
Movie format version
It is possible that the movie file format itself can go through different (and incompatible) versions. If this is the case, the version should be in the header.
ROM filename
This is more useful when there is a good set naming convention for the games in questions. But different versions of a ROM have different sync compatibilities, the user needs to know which was used to play the movie properly.
ROM Checksum
Filenames can be changed by users, the checksum provides a more thorough way of determining a ROM version.
ROM Serial
If applicable, store this. Games such NDS games use this.
GUID
This is a unique number generated for every movie file. The point of this movie is actually for savestates, in order to determine what movie they came from. This field will get saved into any savestate created while the movie was loaded in memory.
RTC
More modern consoles use RTC time to determine RNG values. It is critical that the RTC time be in a movie header. There should also be an absolute default time that is put into the movie by default, rather than the current time. The users will expect to be able to use other values however, hence why it is necessary here.
Flags & Settings
Any special emulator setting or flag that can affect a movie’s sync must be included here. This could be things like the DS firmware settings, different PPU core versions for a NES emulator, or any special settings an emulator might use.
Flags & Settings for determining console used
Some emulators emulate more than one console such as mednafen. Others emulate things like CD add-on’s and other peripherals. TASVideos submission forms depend on automatic determination of console. In cases where a file could be for different consoles, the header should include information necessary to determine this. For instance, FCEUX has a FDS flag. PCEjin has a CD addon flag. Mednafen has flags for the various consoles it emulates. Dega has a flag for Master system vs Game gear.
Rerecord count
See the glossary for a definition. The rerecord count is a tradition from the earliest days of Tool-assisted movies. While it is not a critical piece of information, users will cry foul if they don’t have access to it. It gives a rough idea as to the amount of work put into a movie.
Author
This one should be obvious. We need to know who to credit for a movie.
Optional but useful features
Comments
These are basically memos that the author of the file can include within the file. There should be an easy way for a user to put these comments in. These can be very useful for providing information that can be distributed with the movie file.
Subtitles
These would be like comments except they would be displayed as the movie is playing. While low priority, this feature has proven popular with the TAS audience. Details as to specific formatting schemes as for when and where the subtitles would be placed would be up to the specific implementation of the feature in the emulator. Ability to export subtitles to a popular subtitle format is highly desirable, because that allows to put them in encodes with high flexibility.
Savestate anchoring
TAS movies are generally (and preferred to be) movies that start from a power-cycle. This means clean ram and a fresh bootup. However, the feature to start from savestate is a useful one that is demanded by users. Movies that start from savestate should have the savestate embedded into the movie file.
Input Log
This is the series of button presses of the movie. All forms of user input should be captured in this log. This includes all possible controllers, extra input such as stylus, zapper, mouse, microphone, or other peripherals. This also includes buttons such as the power & reset buttons.
Input should be logged frame by frame and button by button. This means that if the user did not press a button for a frame then a blank frame is recorded. All buttons for that frame should be accounted for too as opposed to only buttons that were pressed. Shortcuts should not be allowed. TAS movies are often edited by hand or have sections of input copy/pasted into other movie files. Therefore it is necessary not just for stable recording/playback but also for movie editing.
In binary movies for example , the number of bytes representing a frame must remain constant and known. An unacceptable format is one where each time a button is pressed it is only logged then in the input stream. In addition the data must be not be compressed.
File type
Originally all movies files were binary format. Newer emulators have been adopting a text based format. Many prefer binary while others prefer text. Text is generally easier for the average user to edit their movies. Binary saves space (which shouldn't be a factor with modern HD disk space) and is more conceptually pleasing to developers.
The following are documentation pages of prime examples of both binary and text formats:
Over the years, both binary and text formats were obsoleted by zip-like container where each movie element can be included as an independent file, either in text or binary form. This is required to easily have different sub-file formats packed together and independent: textual input and header, savestate BLOB, screenshot PNG, config JSON, anything else. And if one sub-file is changed, removed, or added, the rest of the movie remains integral.
Summary
In summary, the file format must be robust enough to include information regarding playing the movie back, recording all possible input the user may need to use, and provide information about the author and movie. It should also allow for unforeseen expansion.
- Do make sure all possible settings that can affect movie playback are accounted for
- Do Consider manual movie editing when designing the movie format. User will need to be able to copy/paste input and modify header information
- Don’t compress movies
- Do Include power & reset buttons as options for input
- Don’t take shortcuts with input. Include every frame and every possible button. The saved disk space is nothing compared to the ease of use of a thorough input log.
- Do make sure binary headers are a predictable length. Keep a buffer between the header and input log
- For binary movies, do make an input log frame a hex friendly number of bytes (8, 16, 32, 64). Also leave a bit extra to allow expansion if needed. For example, if 27 bits are needed for all input, put 5 unused ones to round it off to 32.