From 078bb10ef377cb9a090f33932fa7e01ec23bd6d5 Mon Sep 17 00:00:00 2001 From: bigbass1997 Date: Fri, 13 Oct 2023 12:56:33 -0500 Subject: Removed Other encoding from GAME_IDENTIFIER and performed editing pass over descriptions and introduction summary --- src/docs/draft-tasd-spec-0001.xml | 46 +++++++++++++++++++++------------------ 1 file changed, 25 insertions(+), 21 deletions(-) (limited to 'src/docs') diff --git a/src/docs/draft-tasd-spec-0001.xml b/src/docs/draft-tasd-spec-0001.xml index 35f3945..e527bf3 100644 --- a/src/docs/draft-tasd-spec-0001.xml +++ b/src/docs/draft-tasd-spec-0001.xml @@ -44,8 +44,8 @@
Introduction The Tool Assisted Speedrun Dump (TASD) interchange format is a file format for storing data to allow "Tool Assisted Speedruns" or "Tool Assisted Superplays" to be played on physical video game console hardware using TAS replay devices. Created to be hardware and software agnostic, the TASD interchange format uses a key-based, binary, packet format to break up pieces of information into easily-parsable and forward-compatible chunks. The format is extensible by simply defining additional keys or value types as necessary. When parsing the file, software can skip any packets whose key is unknown or unsupported. - Keys can be used multiple times or completely omitted as needed. This reusability eliminates the need of a predefined delimiter to separate pieces of data such as a list of TAS authors. - While files generated by emulator dump scripts should provide as much information as possible, because keys are optional, the file can be expanded later with any additional data as desired. No intermediary file format is necessary. + Packets of a given type can be used multiple times or completely omitted as needed. This reusability eliminates the need of a predefined delimiter to separate pieces of data such as a list of TAS authors. + While files generated by emulator dump scripts should provide as much information as possible, because packets are optional, the file can be expanded later with any additional data as desired. No intermediary file format is necessary.
Overview and Preliminaries The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. @@ -143,11 +143,11 @@
  • High extensibility
  • Ability to easily generate using lua scripting in emulators
    • - Consideration was also given to how usable the format would be for the software that interacts with replay devices (examples: methods of ingestion/parsing, ease of ingestion/parsing in various languages). + Consideration is also given to how usable the format would be for the software that interacts with replay devices (examples: methods of ingestion/parsing, ease of ingestion/parsing in various languages).
    Problems With Existing Formats - Most existing formats are either incomplete for some verification needs or don't exist at all for some consoles. A format commonly used for NES console verifications (r08) only encodes 2 standard controllers worth of sequential data and a format commonly used for SNES console verifications (r16m) only encodes up to 8 standard controllers worth of sequential data. There is no built in way to store RESET press timing information or indicate additional settings/information. Non-standard controllers are also not supported in commonly used formats. - For consoles not as popular as the NES and SNES, controller input formats would frequently be written in a way that is meant only to work and not in a "standard" way. While that process works, it's less than ideal for redistribution of console replays so that others (especially with differing TAS replay devices) can also verify the same TAS. + Most existing formats are either incomplete for some verification needs or don't exist at all for some consoles. A format commonly used for NES console verifications (r08) only encodes 2 standard controllers worth of sequential data and a format commonly used for SNES console verifications (r16m) only encodes up to 8 standard controllers worth of sequential data. There is no built in way to store RESET timing information or indicate additional settings/information. Non-standard controllers are also not supported in commonly used formats. + For consoles not as popular as the NES and SNES, controller input formats would frequently be written in a way that is meant only to work and not in a "standard" way. While that process works for a specific device, it's less than ideal for redistribution of console replays so that others (especially with differing TAS replay devices) can also verify the same TAS.
    @@ -513,7 +513,7 @@
    Type
    -
    Function of the person who is being attributed. Author is meant for a TAS movie author. Verifier is meant for a person who initially console verified the the TAS movie using the TASD file. TASD File Creator is meant for the person who initially dumped the TAS movie controller inputs into the TASD file. TASD File Editor is meant for a person who edited the TASD file.
    +
    Function of the person who is being attributed. Author is meant for a TAS movie author. Verifier is meant for a person who console verified the TAS movie(s) contained in the TASD file. TASD File Creator is meant for the person who initially created the TASD file, such as when dumping inputs from a TAS movie. TASD File Editor is meant for a person who edited the TASD file.
    Name
    Name of the individual getting the attribution (example: "OnehundredthCoin").
    PLEN
    @@ -533,7 +533,7 @@
    Category
    -
    Name of the TAS movie run category (example: "Any %", "100%", "No Warps").
    +
    Name of the TAS movie run category (example: "any%", "100%", "No Warps").
    PLEN
    Length of the packet payload.
    @@ -551,7 +551,7 @@
    Name
    -
    Name of the emulator used to play the TAS movie while dumping controller inputs (example: "FCEUX", "Bizhawk").
    +
    Name of the emulator used to play the TAS movie while dumping controller inputs (example: "FCEUX", "Bizhawk"). The emulator's version or core name SHOULD NOT be included.
    PLEN
    Length of the packet payload.
    @@ -685,7 +685,7 @@
    Link
    -
    URL that points to the TAS movie or submission (example: "https://tasvideos.org/4567M").
    +
    URL that points to the TAS movie file (example: "https://tasvideos.org/4567M").
    PLEN
    Length of the packet payload.
    @@ -703,7 +703,7 @@
    Frames
    -
    Number of blank frames (inputs where no buttons are being pressed) needed at the beginning of a TAS console replay of the TAS movie. If Frames is a negative value, the value of Frames amount of inputs of the TAS console replay of the TAS movie should be removed.
    +
    Number of blank frames (of input where no buttons are being pressed) needed at the beginning of a TAS replay. If Frames is a negative value, the value of Frames indicates the number of frames that should be skipped from the TAS input data. A negative value is not applicable if there is no way to determine how much input data should be skipped (e.g. NES with INPUT_CHUNKs where each input represents a single latch).
    @@ -785,7 +785,7 @@ GAME_IDENTIFIER Packet GAME_IDENTIFIER packets MUST be in the following format:
    Type
    -
    Hash, checksum, or identifier algorithm Identifier is using.
    +
    Hash, checksum, or identifier algorithm used to create the Identifier.
    Encoding
    -
    Describes the data encoding of Identifier.
    +
    Describes the data encoding of Identifier. Raw binary indicates no encoding is used. Base16/32/64 all use the standard RFC 4648 encodings, without extensions. Base 16 and Base 32 are case-insensitive.
    NLEN
    Length of Name
    Name
    -
    Name of Type meant if the hash, checksum, or identifier algorithm Identifier is using is not included in Type. If Type is [FF], Name SHOULD NOT be empty (0 octet length string).
    +
    Name of the hash, checksum, or identifier algorithm used to create the Identifier. If Type is not [FF], Name SHOULD be empty (0 octet length binary data).
    Identifier
    Game hash, checksum, or identifier data.
    PLEN
    @@ -1105,11 +1104,12 @@
    Port
    Controller port number (Port number MUST be 1-indexed).
    Inputs
    -
    Controller input data for controller on Port. Input values are usually in native format (usually active-low). Input formats for specific controller types are described in ().
    +
    Controller input data for controller on Port. Input values are usually in native format (usually active-low). Input formats for specific controller types are described in .
    PLEN
    Length of the packet payload.
    A single INPUT_CHUNK packet MAY contain up to every input of a TAS movie console replay and MAY contain fewer than every input of a TAS movie console replay. If there are more than 1 INPUT_CHUNK packets, the INPUT_CHUNK packets MUST be in order of the TAS movie console replay inputs, where earlier inputs in the TAS movie console replay are earlier in the TASD file and later inputs in the TAS movie console replay are later in the TASD file. + The input data contained in Inputs is divided up based on the PORT_CONTROLLER type corresponding to the Port number. Refer to for each available type and the number of bytes used for each instance of controller input. Keep in mind that the PORT_CONTROLLER type can be changed using TRANSITION packets.
    INPUT_MOMENT Packet @@ -1142,10 +1142,11 @@
    Index
    Time value to start sending Inputs data.
    Inputs
    -
    Controller input data for controller on Port. Input values are usually in native format (usually active-low). Input formats for specific controller types are described in ().
    +
    Controller input data for controller on Port. Input values are usually in native format (usually active-low). Input formats for specific controller types are described in .
    PLEN
    Length of the packet payload.
    + The input data contained in Inputs is divided up based on the PORT_CONTROLLER type corresponding to the Port number. Refer to for each available type and the number of bytes used for each instance of controller input. Keep in mind that the PORT_CONTROLLER type can be changed using TRANSITION packets.
    TRANSITION Packet @@ -1208,6 +1209,7 @@
    Count
    Number of Lag Frames in a row starting from Movie Frame.
    + Emulators typically consider a "lag frame" to be any frame in which the emulator believes the game does not poll/read controller inputs.
    MOVIE_TRANSITION @@ -1290,7 +1292,7 @@
    Unspecified Data
    -
    Arbitrary data. Can be used for any data. Because this is unspecified data, there there is no guarantee any software to control a TAS replay device will support data in this packet type.
    +
    Arbitrary data. Can be used for any data. Because this is unspecified data, there is no guarantee any software used to control a TAS replay device will support data in this packet type.
    PLEN
    Length of the packet payload.
    @@ -1922,6 +1924,8 @@