Talk:Engine bug

A good source for all of these would be Lee Killough's Doom pages hosted on rome.ro. Bloodshedder 00:09, 11 Feb 2005 (GMT)

Bugs not in this list
I think the following two things are not yet listed in this article, but I don't quite understand what they're referring to, so I can't tell. Look at "Fast and respawn options not reloaded from savegames correctly" and "DR doors corrupt other actions".

Also, I keep hearing rumors that there are bugs in the vanilla stair-building algorithm (e.g. people "optimize" the algorithm while writing source ports and then TNT 30 demos don't work because of that weird circular staircase), and even incompatibilities across vanilla versions, but I can't find any technical details about it. Can anyone confirm this? Ryan W 00:35, 21 Jun 2005 (UTC)

Does anyone know why floor textures near doors sometimes appear to slide back and forth as the door opens and closes? [[Media:E1m4slid.lmp|Here is a demo of it]] (file info; the effect is much more obvious in PrBoom 640x400 than in Doom95 or vanilla).


 * Rounding errors in the BSP builder and the rendering engine. While the effect doesn't entirely disappear, it does become a lot less noticable on that level if you rebuild the BSP nodes. Fraggle 21:57, 3 March 2006 (UTC)


 * I tried this with DeePsea (i.e. Zennode), but it didn't seem to change anything.   Ryan W 16:33, 9 March 2006 (UTC)

One more big one: the general roundoff error when the engine tries to compute the location of an object. For example, monsters stuck in walls after being resurrected by an arch-vile, or here where Phipps says, "But if the DM starts are considered too close to the walls, how can the players move when they are first spawned?" Ryan W 01:43, 31 May 2006 (UTC)

Vanilla Doom does not support Sprite/Flat PWADs. That's a real nasty issue that should be listed since it is an EXE bug.


 * Good point. But wasn't that fixed in v1.9?    Ryan W 19:02, 29 October 2006 (UTC)

Bug.Wad
I found a I made long time ago to show several bugs. I can't remember how were they produced, all I have is a list of the bugs I found.

It could be interesting to include in this section an explanation for these bugs if they are new.

- The left door doesn't allow you to pass to the next room (now I don't know if that was an error of the engine, or a mistake on the editor).

- In the last room, the texture on the walls has a weird scroll.

- The door that can only be opened with a shoot causes some weird bugs:
 * By shooting it two times, one wall at next room will lose its texture.
 * Shooting many times from inside lowers the ceil of both the room and the door.
 * Shooting the door from outside causes the corridor to become impassable. Another shoot could be needed.
 * Shooting the door after the corridor is impassable closes the door.
 * Opening the door after that makes the corridor passable again.

What do you think? CarlosHoyos 15:38, 28 Jun 2005 (UTC)


 * AFAICT all of the anomalies in this map result from mismatched tags and missing textures/sidedefs, not bugs.  Ryan W 02:31, 28 Sep 2005 (UTC)

vague definition of bug? categorizing the bugs might help....
Per Talk:Dead player's line of sight tracks his killer, Talk:Rocket passes through the player who fired it and Talk:Commander Keen missing with -nomonsters it seems there are currently a variety of opinions on exactly what is considered a bug in the doom engine, versus what should be considered a a feature or simple map design error. Perhaps the page should be broken into subsections sort of like this:

Verified engine bugs
These have been verified by id software as bugs.

Undisputed engine bugs
These bugs are obviously bugs (confirmed in the source code) but not yet verified by id software.
 * Ouch face
 * Chaingun fires twice with only one bullet in it
 * Fast doors make two closing sounds
 * Ghost monsters
 * Sound effects behave differently on level 8
 * Sky never changes in Doom II

Advantageous bugs
These are obviously bugs, but possibly became regarded as features later.
 * Gamma correction resets palette
 * Straferunning
 * Wallrunning

Engine limitation bugs
Certain engine limitations are often considered bugs
 * Blast damage has unlimited vertical range
 * Hall of Mirrors effect
 * Map size limit (fatal)
 * Monster targets not preserved in saved games
 * Moving platforms limit (fatal)
 * Some game options not preserved in saved games
 * Turning resolution is lowered when recording demos
 * Visplane overflow (fatal)
 * Visible sprites limit

Incorrectly titled bugs
These bugs should probably be renamed to reflect the correct aspect of the bug.
 * Lost Soul limit -> Pain Elemental helpess with more than 20 lost souls

Bugs fixed before 1.9 releases
These should no longer be considered bugs as they were fixed at some point
 * Projectiles triggering linedefs
 * Loading a saved game under an open door causes crash

Disputed bug
These bugs have a high probability of being actual features or simply mapping errors. They should eventually be moved or removed once consensus is reached.
 * Commander Keen missing with -nomonsters
 * Dead player's line of sight tracks his killer
 * Invulnerability colormap bug

These are just some rough suggestions for division of the bugs (and I only included a few examples, not all of the bugs). Thoughts? --Splarka (talk) 22:47, 19 September 2006 (UTC)


 * I like it. Colin Phipps does something similar on his MBF bug page (sorry I keep citing that, but it's so cool).


 * I don't think classification can ever be entirely straightforward unless John Carmack writes in and tells us which things were intentional and which were not, but this method would at least make sure that nothing important got left out.   Ryan W 14:58, 18 October 2006 (UTC)


 * Fair point, but that is why it is on a wiki. If it is a glaring mistake, it can be fixed or argued about *grin*. So, what do you think, headers or category tags? If we used categories, it'd probaby be better to remove this page and replace it with a list of the categories, and put the description of the type of bug on each category. For example, on Ouch face categorize it as   and on the Category:Bugs (known) page put in "These bugs are obviously bugs (confirmed in the source code) but not yet verified by id software.". This might be confusing, but would remove the redundant listing of bugs on this page and the bugs category, at least. --Splarka (talk) 21:49, 18 October 2006 (UTC)


 * Some people have suggested replacing List of Doom community people with category tags. It didn't happen, because that list is a central location for articles people think should exist but haven't written yet.  I think this article serves a similar purpose, at least for now.


 * Until these articles are pretty much complete, why can't we do both? After all, we add each new map article to 3-4 categories as well as List of WADs.    Ryan W 23:15, 18 October 2006 (UTC)


 * True, it is hard to categorize non-existant articles. Shall we re-do this page in sections (similar to above) then? Or wait for more opinions... (As you have over half the edits on this article, you should probably make that call). --Splarka (talk) 23:34, 18 October 2006 (UTC)


 * I have a feeling that our founders just jotted down whatever they could remember from the source ports they'd worked on, then moved on to topics they enjoyed more. (That's not an insult &mdash; 350 articles like that is a ton of work, and I'm amazed it happened as quickly as it did.)  Since I personally don't know much about WAD resources or C, I get to help out with the unglamorous empirical stuff.  :>   In fact, aside from formatting fixes, almost all of my changes here come from secondary sources which I was reading for other reasons, so they don't even establish that I'm an expert on bugs.


 * Also, while I appreciate your civility in asking my opinion, such behavior is usually inefficient on this wiki. If it's a global policy change, or if it would set a precedent for hundreds of other pages, or if only a few people can revert it (e.g. deleting a page), then by all means get consensus, but in every other case it can take months to do so.  If one of our veteran contributors objects to your edit after the fact, then a discussion becomes much easier to initiate.  :>


 * Ryan W 19:11, 19 October 2006 (UTC)


 * It was more laziness than civility. Fine, I'll do it *grumble*. --Splarka (talk) 22:26, 19 October 2006 (UTC)


 * *L*  My mistake.


 * Seriously, though, I would have done it myself except that I don't have strong opinions about where a lot of them would be categorized. I would have had to read up on the consensus of the source port community, and that might take a long time.  What you wrote above was at least available now as a draft.    Ryan W 17:19, 20 October 2006 (UTC)


 * This categorization seems confusing, because you are applying several different taxonomies in parallel. I think maybe it would work better as a table, with separate columns for severity, chronology, consensus (verified, undisputed, disputed), relevant "resources" (overflow conditions, tags, AI), etc.


 * If a description of a bug, with demos, is hosted on John Romero's web page, shouldn't that count as "verified"?  :>    Ryan W 04:11, 31 October 2006 (UTC)


 * Assuming that the final list might contain hundreds of entries, this method is also somewhat easier on the non-technical reader, since they stay in alphabetical order.   Ryan W 05:22, 31 October 2006 (UTC)