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 bugs, limitations and oddities 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 source 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).