diff options
Diffstat (limited to 'src/docs/draft-tasd-spec-0001.xml')
| -rw-r--r-- | src/docs/draft-tasd-spec-0001.xml | 13 |
1 files changed, 7 insertions, 6 deletions
diff --git a/src/docs/draft-tasd-spec-0001.xml b/src/docs/draft-tasd-spec-0001.xml index 0d7bcc1..f2a6bcd 100644 --- a/src/docs/draft-tasd-spec-0001.xml +++ b/src/docs/draft-tasd-spec-0001.xml @@ -44,7 +44,7 @@ <section anchor="introduction" numbered="true" toc="default"> <name>Introduction</name> <t>The Tool Assisted Speedrun Dump (<strong>TASD</strong>) 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 <strong>TASD</strong> 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.</t> - <t>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.</t> + <t>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.</t> <t>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.</t> <section numbered="true" toc="default"> <name>Overview and Preliminaries</name> @@ -64,7 +64,7 @@ <t>Unless specified otherwise, all multi-octet integers are big-endian.</t> <t>We use the terms <strong>Tool Assisted Speedrun</strong>, <strong>Tool Assisted Superplay</strong> and <strong>TAS</strong> interchangeably in this document.</t> <t>In subsections of (<xref target="descriptions" />), the term "in direct form" is used. That term is defined to mean a packet in a <strong>TASD</strong> file directly (first order packet) rather than a packet inside a TRANSITION or MOVIE_TRANSITION packet (second order packet).</t> - <t>String values <bcp14>MUST</bcp14> use UTF-8 encoding. If an example of a string value is given, the example will be between quotation marks. The quotation marks are not included in the string. Not all content between quotations will be string value examples, so be aware of that when continuing through this document.</t> + <t>String values <bcp14>MUST</bcp14> use UTF-8 encoding. As such, string values <bcp14>MAY</bcp14> contain any number of NUL characters and have no concept of "null termination". If an example of a string value is given, the example will be between quotation marks. The quotation marks are not included in the string. Not all content between quotations will be string value examples, so be aware of that when continuing through this document.</t> <t>Unsigned and signed integers can have different bit widths. For instance, an 8-bit integer can be used in one part of the specification and a 64-bit integer can be used in another part of the specification.</t> <t>Boolean values <bcp14>MUST</bcp14> be a single octet with the value of <tt>0</tt> for <strong>FALSE</strong> or <tt>1</tt> for <strong>TRUE</strong>.</t> <dl> @@ -130,7 +130,7 @@ +-----------+===========+]]> </artwork> <ul spacing="compact" empty="true"> - <li>In this example, enough variable boxes are in the packet diagram to require being split into 2 sections to take up less horizontal space in this documentation. The packet diagram is separated by an ellipsis (<tt>...</tt>) on the same text row as the variable names to signify that the packet diagram is continuing.</li> + <li>In this example, the packet diagram contains enough variable boxes to require being split into 2 sections, in order to maintain consistent horizontal spacing in this documentation. The packet diagram is separated by an ellipsis (<tt>...</tt>) on the same text row as the variable names to signify that the packet diagram is continuing.</li> </ul> </section> </section> @@ -146,8 +146,8 @@ <t>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).</t> <section numbered="true" toc="default"> <name>Problems With Existing Formats</name> - <t>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 <strong>RESET</strong> timing information or indicate additional settings/information. Non-standard controllers are also not supported in commonly used formats.</t> - <t>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.</t> + <t>Existing formats are either incomplete for some verification needs or don't exist at all for some consoles. For example, a format commonly used for NES console verifications (r08) only encodes 2 standard controllers worth of sequential data. The format doesn't indicate whether those inputs are per latch or per frame. It also doesn't contain <strong>RESET</strong> timing information, additional settings, or metadata. Non-standard controllers, such as the NES Zapper, aren't supported either.</t> + <t>Until now, controller input formats were written in a way that was "good enough" for each use case, but rarely in a "standard" way. Often, any additional data had to be supplied separately as command-line arguments. While that process may work for a specific device, it's less than ideal when it comes time to redistribute the replay data so that others (especially those using different replay devices) can also successfully replay the same TAS.</t> </section> </section> </section> @@ -1913,7 +1913,7 @@ </references> <section numbered="false" toc="default"> <name>Copyright Notice</name> - <t>Copyright (c) 2021-2023, Vi Grey, Bigbass, and rasteri</t> + <t>Copyright (c) 2021-2025, Vi Grey, Bigbass, and rasteri</t> <t>All rights reserved.</t> <t>Redistribution and use of this documentation in source (XML format) and/or "compiled" forms (TXT, PDF, HTML, etc), with or without modification, are permitted provided that the following conditions are met:</t> <ol> @@ -1923,6 +1923,7 @@ <t>THIS DOCUMENTATION IS PROVIDED BY THE AUTHOR(S) "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.</t> </section> <!-- Change Log +draft 16 - 2025-02-01 Bigbass Clarified NUL characters in strings. Revised "Introduction" paragraphs. draft 15 - 2023-10-15 Bigbass Reordered SNES controller types |