Engine bug

There are numerous bugs, limitations and oddities present in the Doom engine. For errors in map design, even those related to a specific item below, see the article about that map.

Note that playing with an unmaintained source port introduces additional bugs not listed here.

Key
This table classifies anomalies in a very broad way; see the individual articles for details.


 * Canonicity &mdash; A bug is verified only when a current or former id Software employee has called it a bug in a public forum. An unverified bug may still be undisputed if it is generally accepted as an error by the source port community (after years of playtesting and a stable consensus as to how to interpret the relevant code).  If no existing secondary source labels the anomaly as verified or undisputed, then it is disputed.


 * Cause &mdash; The general category of underlying problem:
 * Most bugs are due to algorithms which fail to account for all possible inputs, apply conditional statements in an illogical sequence, or have unforeseen consequences in particular game situations.
 * A few of these arise from simple typos in the source code.
 * Improperly constructed linedefs, with orphaned tags or incorrectly placed textures, can also induce various strange behaviors.
 * The Doom engine includes few safeguards against overflow conditions.
 * Line-of-sight calculations, rendering algorithms, and the BSP tree are also susceptible to roundoff errors.
 * The engine imposes a number of static limits on Thing placement and map construction, which sometimes fix one problem by creating another.


 * Fatal bugs cause the engine to crash in vanilla Doom. Y* means that a crash is possible, but not inevitable.  N* means that no crash occurs, but that rendering or character behavior may be sufficiently compromised that meaningful gameplay becomes impossible.


 * Fixed in 1.9 &mdash; Some bugs appear only in versions of Doom prior to v1.9.


 * A bug has a workaround if it can be avoided by reasonable compromises in map design. (For example, matching every linedef tag to at least one sector is reasonable; removing invulnerabilities from every level containing a sky texture is not.) S means that the bug can be avoided by making one's map smaller or less complex; whether this is a reasonable compromise can be debated, especially in this era of graphics acceleration and limit-removing source ports.


 * A bug is a loophole if it can be abused to the player's advantage (especially during speedruns or deathmatches).