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:
  1. Movie file: Doom movie ".lmp" files, with possibly extra metadata added.
  2. Verification playback engine: Dosbox running the original executable (can be verified by checksum).
  3. TASing engine: Anything is allowed; but prboom-plus seems to be the best candidate for actually having TASing features amongst currently existing source ports.


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.


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

Movie authenticity

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.


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.


See EmulatorResources/Features. The current state of prboom-plus is as follows:


[1]Bulletproof recording


[2]Resume Recording From Savestate


[3]Savestate Undo (Low priority)



[4]Frame Advance

Easily implemented

[5]Slow Motion


[6]Fast Forward


[7]Frame Search (Low priority)

Not supported


[8]Key remapping


[9]Read-only Toggle


[10]Information Display


[11]Export To AVI


[12]Memory Search

Not relevant, since all useful information can be displayed directly

[13]Autofire (Low priority)


[14]Auto-hold (Low priority)


[15]Combos or macros (Low priority)


[16]Rewind (Low priority)


Emulation features

[20]Proper emulation of power cycling


[21]Disabling layers

Supported (fullbright, "all actors visible through walls" toggle).

[22]Accurate emulation of soft resets (Low priority)


Additional Emulator features

[23]Lua or Python Scripting

Not supported, and would be significant work.

[24]Lag Counter (Low priority)


[25]Option for frame advance to skip lag frames


LMP format

Things of note:
  1. Some sanitation is required by the parser to reject invalid movies. In terms of the LMPC tool:
    1. GF > 50 or GB > 50 is not allowed.
    2. SL > 50 or SR > 50 is not allowed.
    3. SL > 40 or SR > 40 when TL > 0 or TR > 0 is not allowed.
  2. 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.
  3. Is interesting?
  4. 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:

HomePages/natt/Doom last edited by natt on 7/29/2012 4:38 PM
Page History Latest diff List referrers View Source