Added in Bizhawk 2.11

Might as well stop being completely useless and finally run Doom.

The core ported for this is DSDA-Doom, which focuses on speedrunning and compatibility for vanilla and modern features.

The only supported extension is .WAD, which may contain an IWAD or a PWAD inside. To run PWADs you need to load them alongside IWADs they're made for, by using a Multi-Disk Bundler XML file.

Example of contents:

<BizHawk-XMLGame System="Doom" Name="btsx">
  <LoadAssets>
    <Asset FileName=".\doom2.wad" />
    <Asset FileName=".\btsx_e1a.wad" />
    <Asset FileName=".\btsx_e1b.wad" />
  </LoadAssets>
</BizHawk-XMLGame>

Information about the loaded files can be seen by clicking the icon in the bottom right corner of the BizHawk window (dump status report).

Bizhawk always runs Doom in a demo recording mode, so you don't have access to startup screen or menu: it launches straight into the game. Initial level (and episode, among other things) can be specified in Doom -> Settings -> Sync Settings menu.

Default settings are configured to be as close to vanilla Doom as possible, but useful modern features are also available: increased internal resolution, secret reveal notice, all sorts of heads-up-displays, etc.

For maximum immersion you can capture mouse so its pointer is hidden and expand Bizhawk to fullscreen, using the corresponding hotkeys. Note that capturing mouse may glitch out if Bizhawk is covered by another window, and contents of the latter will become clickable. To avoid that, go to Config -> Display -> Window tab, and check Mouse Capture Forces Stay on Top. That way whenever mouse is captured, Bizhawk window will be set to Topmost, which minimizes the risk of its window getting covered (however OS Start menu will still appear above it).

Doom demo files store movement as analog axes (vertical movement, horizontal movement, turning), XDRE and DSDA-Doom's input display shows positive and negative speed (which defines direction) as 2 separate positive axes, but Bizhawk shows them both combined and signed.

Relative (raw) mouse input has to be mapped to mouse controls: RMouse Y to mouse running and RMouse X to mouse turning. That allows us to manipulate mouse movement to make it feel authentic, because the original game did that (as well as source ports). Direct access to run and turn speeds is only for precise editing, like in TAStudio.

Default binds for key-based turning look reversed: Q is Turn Right and E is Turn Left. But real-time players bind them that way to make "strafe50" feasible. Since "strafe50" requires pressing Forward, Directional Strafe, Turn, and Strafe Modifier keys all at once, the most practical way to press that combo is Q+W+D or A+W+E with the left hand and Strafe Modifier with the right hand. If turn direction keys weren't reversed, one would have to press A+Q+W for strafe50 to the left, which is too hard to do quickly and reliably.

Normally Doom demos reduce actual turning resolution (2-byte signed) to just the higher byte. At some point, an option to use full turning resolution in demos was added to some source ports, so Bizhawk has that option too.

Note that Doom counts angle values counterclockwise, so positive turn value turns you left, and negative turns you right. This can be tracked on the in-built coordinate display.

Since editing a 2-byte value in TAStudio would be a nightmare, Bizhawk splits longtic turning value into 2 values: higher byte (whole angle values) and lower byte (fractional angle values). Higher byte equals the shorttic angle input, therefore its range is [-128, 127] (sign indicates turning direction).

Lower byte has somewhat counter-intuitive range of [-255, 255]. Of course when the final value is composed and sent to the core, lower byte is actually only a value between 0 and 255. However for movie editing purposes, negative range is allowed so that "sub-angle" turning could be done in both directions. Without this feature, it'd be impossible to turn by -0.1 or -0.255, because sign would only be available for the higher byte and you can't set it to -0.

The ultimate value that's sent to the core is high_byte * 256 + low_byte. If the 2 values have different signs, low_byte is subtracted from high_byte, so the final turn value is reduced.

In order to make it work inside the Waterbox environment we had to remove all SDL2 from the code, which resulted in inability to load MIDI soundfonts or pre-recorded music. The only option currently is OPL3.

The core aims to be fully compatible with Doom demo files (.LMP), and those that can run on vanilla Doom can be imported into Bizhawk and automatically converted into .bk2 format. Newer formats (Boom and above) will be supported in the near future, as well as .LMP export.

Wipe/melt effect screen is automatically disabled for them, because Doom doesn't process inputs during it but does render frames. In Bizhawk those 2 concepts can't be separated: for some frame to be rendered it has to be an input frame too, but demo files don't have those extra blank frames in them.

If you make a movie in BizHawk with the melt effect on, beware that in different resolutions it will take different amount of frames, so you may have to resync.

There are no traditional memory domains to expose for Doom source ports, because all the memory is allocated right inside the host machine. Instead we expose 2 arrays that XDRE exposes, but with a little bit more details: Things and Lines.

Their layout in memory is the same as in source ports, all the struct fields are exposed. A Lua script that showcases them and serves as a usage example can be found in Lua\Doom folder, it's called things-lines.lua. Also available online in BizHawk repo.

The core is ported using Waterbox, which means all the memory that the core changes after init will be serialized to savestates to guarantee determinism. But for big WADs with hundreds of enemies in the same room this can be a problem, because when enemies are fighting and shooting projectiles, extra memory is being changed, and serialized by Waterbox. Uncompressed savestate in nuts.wad can reach several hundred megabytes in size, in bigger slaughtermaps it would be even bigger. Some of them will even crash the core because they require several gigabytes of memory to function and Waterbox limit is 4GB. And even if they don't crash, savestates being that huge makes TASing a nightmare because it's very slow (especially with TAStudio).

Internal savestates might be used at some point, but they have determinism problems.