PLEASE NOTE: This is a draft proposal document. It does not represent any TASVideos policy.
Verifiable Doom TASes.
Doom should need no introduction. It's a fast paced first person shooter, with an active speedrunning community. It has appeared many times on many "most wanted TAS" lists. The game runs in JPC-RR in principle, but practically speaking, it's far to slow to do any useful TASing. However, the base game includes a recording format which, if it can be made to meet the requirements of TASVideos, would allow for TASing without being encumbered by JPC-RR limitations.
I believe very strongly in verifiable TASes. In fact, I'm oppossed to some of the emulators that are allowed here on TASVideos. However, I think that Doom TASes can conform to very strict standards of verifiablity. The basic concept I want to use is verified playback. This idea stems from the thought experiment: If someone makes a TAS on a specifically source code modded emulator (or even a modified game rom), but it plays back in the official emulator with the official rom, is there a problem? I don't think so; the modded emu and rom are just tools like any others. So the basic plan for Doom then is to have an officially certified playback method, but any method at all allowed for recording.
The outline then looks like this:
- Movie file: Doom movie ".lmp" files, with possibly extra metadata added.
- Verification playback engine: Dosbox running the original executable (can be verified by checksum).
- TASing engine: Anything is allowed; but prboom-plus seems to be the best candidate for actually having TASing features amongst currently existing source ports.
Requirements
The EmulatorResources/Requirements list is of great practical importance to TASing emulators, so I'm going to show how this propsed setup meets or could be made to meet these requriements. Open that page and read along with this:
Movie files
Doom "demos", sometimes called .lmp files, store player inputs and are replayable by the original executable.
Re-recording
While the original engine is not without bugs, it is believed to be reasonably sync-robust. There are thousands of existing Doom demos that have been played back thousands of times without desync.
Emulation quality
The original executable is, by definition, as close to original as possibly imaginable. Also at issue is DosBox; the game seems to run quite well in that environment, though. Finally, how well the TAS engine matches the playback engine is relevant; and ports like prboom-plus and Chocolate Doom have had quite a bit of work put into demo sync compatibility with original executables.
Emulation stability
- There are no future versions of Doom; since the .lmp file is defined as what plays on a particular frozen authentic version, this point does not apply.
- Demos play back on any system that DosBox supports. In addition, demos play back on any system that prboom-plus or Chocolate Doom supports.
- DosBox, Doom (original), Chocolate Doom, and prboom-plus are all open source.
Movie authenticity
- Movies cannot start from savestate, only at beginning of levels with fresh starts.
- The frame length of the movie can easily be derived from a simple parser without playing the movie.
- The movies only store player actions, in terms of movement/rotation, shoot, switch guns, use.
- This point is not satisifed; there is no header. However, the frame length is always available to a simple parse, so this is not a problem.
Other movie information
At the moment, this capability does not exist, however the existing demo format has the possiblity of a footer after the end of input that will not break compatibility on the original system, and can easily be made to hold any desired metadata.
Accessibility
As previously mentioned, all relevant programs are available with source code, and run on multiple operating systems.
Possible to make an avi.
Prboom-plus has video dumping code which satisifes all of these requriements.
Features
See EmulatorResources/Features. The current state of prboom-plus is as follows:
Savestates
[1]Bulletproof recording
Unknown?
[2]Resume Recording From Savestate
Supported
[3]Savestate Undo (Low priority)
Unknown?
Timing
[4]Frame Advance
Easily implemented
[5]Slow Motion
Supported
[6]Fast Forward
Supported
[7]Frame Search (Low priority)
Not supported
Usability
[8]Key remapping
Supported
[9]Read-only Toggle
Unknown?
[10]Information Display
Supported
[11]Export To AVI
Supported
[12]Memory Search
Not relevant, since all useful information can be displayed directly
[13]Autofire (Low priority)
N/A
[14]Auto-hold (Low priority)
N/A
[15]Combos or macros (Low priority)
Ehhh...
[16]Rewind (Low priority)
Unknown?
Emulation features
[20]Proper emulation of power cycling
N/A
[21]Disabling layers
Supported (fullbright, "all actors visible through walls" toggle).
[22]Accurate emulation of soft resets (Low priority)
N/A
Additional Emulator features
[23]Lua or Python Scripting
Not supported, and would be significant work.
[24]Lag Counter (Low priority)
N/A
[25]Option for frame advance to skip lag frames
N/A
LMP format
Things of note:
- Some sanitation is required by the parser to reject invalid movies. In terms of the LMPC tool:
- GF > 50 or GB > 50 is not allowed.
- SL > 50 or SR > 50 is not allowed.
- SL > 40 or SR > 40 when TL > 0 or TR > 0 is not allowed.
- Once these basic checks have been made, every other possible configuration is a set of allowed values. The demos only contain "actions", actions that in principle could all be executed by a player in realtime, and so is TAS valid.
- Is http://www.chocolate-doom.org/wiki/index.php/Doom_1.91_demo_format interesting?
- Because the engine stops playback after recieving go = 0x80, the rest of the file is ignored and a footer can be used to hold metadata.
Supportable game versions
My reccomendation would look something like this:
- UDoom 1.9 "doom.exe" for Doom demos and vanilla-compatible pwads. (-complevel 3 in prboom-plus and Chocolate Doom)
- Doom II 1.9 "doom2.exe" for Doom2 demos and vanilla-compatbile pwads. (-complevel 2 in prboom-plus and Chocolate Doom)
- Final Doom executable form tnt/plutonia iwads and pwads that require it (-complevel 4 in prboom-plus and Chocolate Doom)
- Boom 2.02 "boom.exe" for pwads that require it (-complevel 9 in prboom-plus; no Chocolate Doom support).