Difference between revisions of "Engine bug"
From DoomWiki.org
[checked revision] | [checked revision] |
m (in some circumstances, positive offsets are ignored as well) |
m |
||
Line 561: | Line 561: | ||
! N | ! N | ||
! | ! | ||
+ | |- | ||
+ | | [[Monsters may target players without ever seeing or hearing them]] | ||
+ | | Disputed | ||
+ | | Algorithm | ||
+ | ! N | ||
+ | ! N | ||
+ | ! N | ||
+ | ! N | ||
|- | |- | ||
| [[Monsters open locked doors]] | | [[Monsters open locked doors]] |
Revision as of 21:54, 11 June 2015
A Doom engine bug is a limitation or an oddity 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 a source port may, while removing some or even the majority of the bugs listed below, introduce other bugs which are not listed here (although details may be present in the article about the source port in question).
Key
This table classifies anomalies in a very broad way; see the individual articles for details.
- Canonicity — A bug is verified only when a current or former id Software programmer has called it a bug in a public medium. An unverified bug may still be undisputed if it is generally accepted as an error or issue by the fan community under a consensus involving thorough playtesting and research on the corresponding phenomenon and any associated binaries or source code. A bug is disputed if it can be argued to be a harmless and possibly intentional feature.
- Cause — 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) or sectors, 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.
- 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.
- Fatal bugs are those where the engine crashes (often with the Venetian blind effect) or else exits the game in a controlled fashion, usually with an error message. Y* means that termination is possible, but not inevitable. N* means that the program keeps running, but that rendering or character behavior may be sufficiently compromised that meaningful gameplay becomes impossible.
- A bug has a workaround if it can be avoided by reasonable compromises in map design, such as when matching every linedef tag to at least one sector, but not when removing invulnerabilities from every level containing a sky texture, or also by convenient precautions and other measures taken by the program user, such as when increasing the mouse sensitivity through the configuration file directly, instead of using the menu. S means that the bug can be avoided only by making one's map smaller or less complex.
- A bug is a loophole if it can be abused to the player's advantage (especially during speedruns or deathmatches).