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)


 * Yes, I think there are two separate compatibility issues with stairs. One concerns how multiple stairs are started from a single switch. MBF and PrBoom implemented it incorrectly, apparently failing to generate some of multiple staircases.


 * However, the TNT30 issue is another one. (It doesn't even have multiple staircases generated from a single switch.) The problem is that the original Doom code occasionally increments the step level of a staircase twice (maybe even more) while trying to find the next step to rise. TNT30 compensates this behaviour with a kind of duct tape fix: when it builds 24 unit high steps using the 8 unit action, it only has two stair sectors where a correctly behaving engine would need three. Original Doom acts incorrectly and builds 24 unit steps. A fixed engine (such as Doom Legacy) only makes them 16 high. As a result, the red key stairs become too low. So do the crucial stairs of the boss room. Ultimately the level cannot be completed (using the intended route, at least) if the engine has been fixed.


 * It becomes even more confusing because the same comp_stairs option of various ports may try to handle both of these bugs. To skip the messy parts (mostly concerning MBF), any good post-2001 port should have a comp_stairs option which makes stairs work precisely like in Doom.


 * It's a long story. I can try to explain it in detail, even though some parts of it are still hazy to me as well. If someone is interested, I'll create an account and discuss it somewhere...a bit later. Drop a line here or something.

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)


 * Addendum: I think wall textures can do something very similar. For instance, near the yellow key on E1M7, there is a shimmering effect on the technical walls as you move around: sometimes the narrow white strip is exactly on the corner, and sometimes it isn't, depending on where the renderer has rounded off the sidedef's length.    Ryan W 20:21, 26 January 2007 (UTC)


 * Further addendum: this post to the PrBoom listserv shows that I'm not just imagining the wall texture part.   Ryan W 21:00, 17 June 2008 (UTC)

>Author: entryway >Date: Sun Jun 8 15:32:55 2008 >New Revision: 2766 > >Modified: >   branches/prboom-plus-24/prboom2/src/r_main.c >    branches/prboom-plus-24/prboom2/src/r_main.h >    branches/prboom-plus-24/prboom2/src/r_plane.c > >Log: >Fix vanilla unprecise calculation (vibrations) of the texture >coordinates for flats in software renderer. Visplanes with the same >texture now match up far better than before. You can see this bug on >cchest2.wad\map02 in room with moving illumination around the room >with sector 265. The new algo is ~1% slower than the original and >will use only if render_precise is 1.

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)


 * Hmm, apparently not. Here is some recent discussion, including a hack you can do with a WAD editor to circumvent the problem.    Ryan W 05:19, 11 July 2007 (UTC)

A few more possible entries, mostly from the ZDoom and PrBoom changelogs:


 * Bizarre foreshortening of column sprites when viewed from a sector whose floor height is significantly above their base (e.g. the normal exit of E1M3).
 * Frame skipping during screen melt (easy to see in most UV speed demos of E1M1; also happens with weapon changes).
 * The same phenomenon that causes Mancubus fireball clipping sometimes allows you to grab objects through walls.
 * Memory "wastage" (?) by Z_FreeTags.
 * Monsters sometimes retaliate against wrong character in multiplayer mode.
 * Top of pistol sprite shown at bottom of screen.
 * Unused player death sound in Registered/Ultimate Doom.
 * Deleted thinkers referenced by monster targets, tracers, or soundtargets.
 * Voodoo dolls move along with player.
 * SSG neck not lit up correctly when SSG is fired in a dark room.
 * SSG shows reload frame while firing frame is still displayed.
 * "Raise to shortest texture" always fills in AASHITTY.
 * Flickering light not remembered across savegames.
 * MAP30 telefrag "inconsistency". (Not sure what this means -- is this just the standard MAP30 exception?)
 * Pain Elementals can spawn Lost Souls through monster-blocking linedefs.
 * Live monsters can't be pushed off ledges.

Ryan W 02:47, 4 November 2006 (UTC)


 * Saving a game and then re-loading causes all enemies that were not in-line-of-sight with the player to be "asleep" when the load resumes.
 * Punching the fist in the air, which causes no sound whatsoever, causes enemies around to wake-up the same as if a sound had been generated.


 * First item is already in the list. Second item has been discussed here, but apparently not everyone agrees that it is a bug.    Ryan W 16:35, 6 April 2008 (UTC)

There was a bug in v1.0 (I think) where there were really only four save slots, but it looked like there were six. Slots 4 and 5 always looked blank, but if you tried to use them, it would instead save in slot 0 or 1 respectively, overwriting whatever was there. Setting up a white box to verify this would be a bit painful at the moment, so I'm posting here in case someone else can do it easily. Ryan W 19:04, 6 December 2006 (UTC)

Two additional and rather obscure LOS problems are described here. The first one might be Hitscan attacks hit invisible barriers in large open areas. Ryan W 10:20, 22 January 2007 (UTC)

This chaingun sprite clipping problem is in fact quite general &mdash; on any level with a lot of zombies, it's pretty easy to get corpses and/or dropped weapons to appear on the wrong side of a door or curb &mdash; but I do not know whether this is already included in one of the phenomena we have listed here. Sprites flickering across ledges or lifts, possibly? Ryan W 00:15, 27 January 2007 (UTC)

This rendering anomaly may or may not be the same as Sprites flickering across ledges or lifts. I can't tell, so I'm listing it here. Ryan W 21:41, 21 February 2007 (UTC)

On E1M3, when I look out of the inviso room to the south, why can I see the sky through the top edge of the grate texture? It's as though there's a horizontal slime trail, though I've never heard of that. I think that it isn't tutti-frutti: when I "zoetrope" by walk backing and forth a bit, the mountain is clearly there. (Or is this simply what happens instead of the day-glo colors when a middle texture has undefined pixels on a 2S wall?)   Ryan W 07:05, 2 March 2007 (UTC)


 * Addendum: this also happens when walking toward the yellow key on E1M9 (if you're close enough, you can see the flashing lights through the "solid" boundary between the grate and the floor).   Ryan W 14:53, 14 April 2008 (UTC)

In, around the 19:40 mark, the player fires a rocket into a solid wall (supercharger courtyard on E1M6). It hits the wall and disappears without exploding. Huh? Ryan W 10:46, 4 March 2007 (UTC)


 * Be nice if I had actually linked to the article that explained this! It is here.    Ryan W 16:58, 27 December 2007 (UTC)

Also on E1M6, when I stand in sector 190, why on earth can't monsters in sector 145 see me? The interposing linedefs don't seem to be doing anything weird. Ryan W 14:31, 4 March 2007 (UTC)


 * The Central Processing Reject is set true for sectors 145 &lt;-&gt; 190 --Splarka (talk) 22:11, 4 March 2007 (UTC)


 * Good heavens! I would never have thought to check for  in an id map.  :>   (Maybe I should rebuild all the tables and look for more, hmmm.)  Thank you once again for helping to educate me.    Ryan W 15:27, 5 March 2007 (UTC)

A few more from Doom change log (hopefully, somebody else recognizes these and can at least suggest a title):


 * "Sound problems" fixed in v1.4.
 * Are the SERSETUP changes in v1.5 considered a bug fix?
 * "Response file bug" fixed in v1.5.
 * "Bug when using a baud rate greater than 38,400 bps in null-modem/modem games" fixed in v1.5.

Ryan W 01:07, 26 May 2007 (UTC)

A thread on the Doomworld forums has just reminded me that objects can be grabbed through walls due to run-of-the-mill roundoff error (e.g. the armor bonuses behind the steel lift on MAP06), not just by mancubus fireball clipping. Or does that happen merely because the sprite is so much smaller than the object's radius &mdash; it looks right to put it that close to the wall, but it really isn't?   Ryan W 06:19, 11 July 2007 (UTC)

Weapon stays fixed at last bobbing position when firing continuously.

A possible bug with the intermission screens is described here. We all know it doesn't work quite right in Doom95, but the way Fraggle describes it, the DOS version of Ultimate Doom (for instance) should also be affected. Ryan W 04:26, 17 September 2007 (UTC)
 * That is a bug that existed in an older version of Chocolate Doom. Vanilla Doom's source contains the correct code. Zack 04:41, 25 December 2007 (UTC)

More static limits which might or might not be intrusive enough to be considered bugs: MAXLINEANIMS, MAXOPENINGS, MAXBUTTONS, MAXSLIDEDOORS, MAXEVENTS, MAXANIMS, MAXCEILINGS, MAXSWITCHES. Hmmmm-m, I thought the linedef specials limit was a Boom issue, not a vanilla issue. Ryan W 18:52, 26 January 2008 (UTC)


 * Oh yeah; as a recent post on the PrBoom listserv reminds me, there is also a static limit of 100 on the number of WADs/DEHs/etc. that can be loaded at once. Is it called MAXARGVS or MAXWADFILES?    Ryan W 17:27, 1 June 2008 (UTC) Now included in the Static limits article.    Ryan W 04:14, 25 February 2013 (UTC)

Ryan W 19:20, 26 January 2008 (UTC)
 * "why is it that if you give a non-flying monster the lost soul attack, sometimes it starts bouncing up and down strangely?"
 * "the bizarre map24 trick, where the player is able to make use of a narrow ledge that is the other side of an impassable linedef."
 * "[Invalid values of sector type] cause an error and exit to DOS. This includes these two values which were developed and are quoted by id as being available, but are not actually implemented in DOOM.EXE (as of version 1.666): 6 06 - crushing ceiling, 15 0f - ammo creator"

This bug in rendering logic seems to be present in the original source release (r_things.c), but I don't know anything about pointer arithmetic, so I'm not certain enough to create a stub about it. Could it actually cause a crash, for example? Ryan W 21:46, 20 October 2008 (UTC)

According to a reliable source, a monster is immune to hitscan attacks that don't cross its diagonal. (!)   Ryan W 18:28, 11 November 2008 (UTC)

Andrey Budko says:

>+ // Do not exit if corresponding demo lump is not found. >+ // It makes sense for Plutonia and TNT IWADs, which have no DEMO4 lump, >+ // but DEMO4 should be in a demo cycle as real Plutonia and TNT have. >+ // >+  // Plutonia/Tnt executables exit with "W_GetNumForName: DEMO4 not found" >+ // message after playing of DEMO3, because DEMO4 is not present >+ // in the corresponding IWADs.

Is this truly a bug in the original application, or is it something that can't really happen unless you try to run a mismatched IWAD + release version (trivial with the command line in PrBoom, but would require moving files from folder to folder in DOS, which is usually assumed to be unsafe)? Ryan W 00:27, 20 January 2009 (UTC)

" [A peculiar bug in the Doom 1.666 engine which does not allow multiple sector tagging for raised floors."]   Ryan W 00:58, February 5, 2010 (UTC)

Donut linedef special can apparently fail depending on the map slot. Ryan W 01:01, June 10, 2010 (UTC)

Catastrophic memory corruption can occur with more than ~4000 lumps. Ryan W 20:25, 24 September 2011 (UTC) Whoops, didn't notice this had been added to the table. Ryan W 04:18, 25 February 2013 (UTC)

From Retur_na.txt: "And I now confirm the old v`.2 bug: recording is truly a PITA as your player keeps constantly getting pulled to a side."  He does? Ryan W 15:12, 7 March 2012 (UTC)

Recent dwforums thread focusing on Heretic glitches, most of which appear not to be in this list:. Ryan W (talk) 16:42, 5 July 2014 (UTC)


 * Given that you feel this article's already too long I believe that Heretic and Hexen glitches should be started as new articles, as I did for Engine bugs in Strife. --Quasar (talk) 20:27, 5 July 2014 (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)

Table
I'm not really sure I like the table, I kind of preferred the article when it was just a big list of bugs. Couldn't the table options be better represented through categories? ie. have categories like Category:Algorithm bugs, Category:Bugs fixed in Doom 1.9, Category:Exploitable bugs (for loopholes). I'm not sure what advantage the whole "bug canonicity" concept brings: bugs exist whether Id has confirmed them or not, and it can often be proved by examination of the source code. Fraggle 00:25, 23 February 2007 (UTC)


 * That would presumably be wikipedia's approach (e.g. every biographical article seems to be in 12-15 categories), and certainly I do not know the code well enough to have a really strong opinion. The more conversations I have about bugs, however, the more I believe that identifying and classifying bugs is a subtle procedure, involving not only id's intentions (was Long wall error left in on purpose as a compromise, or did they just not think through every consequence of their algorithm?) but also the likelihood of a mapper's causing trouble by trying things that id didn't anticipate.  See, for instance, this argument, wherein Splarka asserts that Monsters open locked doors is not a bug.


 * Many of our current bug articles are very POV, and/or insinuate that the exact nature of the problem is so obvious that code excerpts are unnecessary. The distinction between "undisputed" and "disputed" (as defined in this article), especially, tends to be ill-documented.  I think it was Quasar who added the only "verified" entry to the table, but I'll be damned if I have ever heard id admit to any slipshod coding practices, anywhere; I can't wait to see the bibliography for that one. (EDIT: actually that one is in the changelog.  Bad example.)  Perhaps some of the columns in the table are reactions to such (what I believe to be) omissions.


 * If the individual articles were fleshed out to the point where they duplicated (or rendered irrelevant) all the information in the table, however, then your method would probably be simpler... In any case I think the list itself should be retained, for the reasons described in the preceding section.   Ryan W 04:22, 23 February 2007 (UTC)


 * The verified category can be expanded by checking release changelogs (for bugs that have been fixed), interviews, or forums. I'm certain that on his forums Romero said something like "oh, yeah, that was a rare bug..." when asked about the Archvile ghosts glitch, so that one at least can be considered "verified". Even if the table were eliminated in sake of categories, comments by present or past id people about bugs could still be cited in the specific bug articles, as reference. Who is like God? 16:48, 28 February 2008 (UTC)


 * by checking release changelogs  Geez, why didn't I think of that?


 * Searching for "bug" on the rome.ro discussions (excluding forums which are probably unrelated, like Daikatana) only returns 400 and some odd results. Good idea!  I'm packing for a trip right now, but I'll add this to my list in case no one else picks it up.    Ryan W 01:03, 29 February 2008 (UTC)

Hexen?
This bug list tends to revolve round a Doom.

A vanilla Hexen bug that I have noticed is: 1. Play level Necropolis or Castle of Grief 2. It is dark but every now and then lighting flashes, illuminating 3. If you can arrange that the main menu comes up and you save the game on restoration of the game, it is no longer dark, the light level is whatever it was during the lighting flash.

Stephen Howe


 * But this also occurs in Doom. See above list (under "ZDoom and PrBoom changelogs").    Ryan W 23:54, 25 May 2007 (UTC)

Anyone ever encounter the "Arch-Vile Save Bug" ????
I can only confirm this glitch in Doom 95. This glitch occurs after you save your game while an arch-vile is attacking you (or another creature). While your being attacked (the yellow flame is visible) go to the menu and save your game. If you try to load that save file back up, the game will lock up causing a fatal error. Has anyone else ever encountered this or know if the glitch is prevalent on any other versions of doom? Simdoom 04:16, 9 March 2008 (UTC)
 * This is related to the "... not preserved in save games" bugs listed on the page here. Doom 95 behaves differently to Vanilla Doom in that it just crashes instead. Fraggle 04:33, 9 March 2008 (UTC)


 * In vanilla saving and loading the game while an Arch-Vile attacks cancels the attack (apart from the flame animation). This is actually an extremely useful strategy against Arch-Viles, since it basically makes them totally unable to hurt a wary player using the trick. Even though it's one of the most lame vanilla exploits in existence, we should probably mention it in the Arch-Vile article (plus of course in the related bug article(s) as well). -- Janizdreg 05:46, 9 March 2008 (UTC)

Canonicity
I have edited the definitions of canonicity since:


 * "Source code community" can be interpreted as source port users and coders, when other people are also involved (such as wad designers, players, or speedrunners that examine bugs through their years of involvement with the games).


 * The source code is not the only source of research; you can reverse engineer the executable and some bugs involve characteristics of the DOS builds (such as sound related code or overflows), which might not necessarily be explained with the source.


 * The disputed part was worded as if extra sourcing and verification were required, but it's part of the same process that finds bugs (already including testing and research).


 * Changed id employee to programmer as this is about the engine, and in any case if Donna Jackson (aka id mom) or an employed security guard were to talk about a Doom engine bug it wouldn't be too relevant ;p Who is like God? 21:39, 22 April 2008 (UTC)

joyb_speed 31
There should be an entry for what was probably the best Doom "bug" ever: joyb_speed 31 (or 29, or whatever)

I was wondering why that worked just now and when I googled it I found out that I had actually asked that same question like 6 years ago: http://www.doomworld.com/vb/doom-general/12823-joyb-speed-31/ --Linguica 03:26, 6 January 2009 (UTC)


 * Looks like some of the big brains had already written it up. I added a link to that.    Ryan W 18:05, 6 January 2009 (UTC)

Needs More Articles
I've noticed a lot of new bugs have been added to the table, but there are no articles for some of these, which really makes it kind of hard for anyone to actually start an article about them. What does the bug do? How can it be recreated? Why is it disputed/undisputed/verified? Are there any sources if it's verified? Even a short one-liner stub would be better than nothing. At least it would give someone enough information to do some research into the topic at hand and get the article going. User:EarthQuake 15:26, 10 February 2009 (UTC)


 * Partial answer: If an entry says "verified" but gives no source, that's because it's listed in the official change log as a bug fix.  Providing explicit citations for "undisputed" is very difficult because it's meant to reflect the consensus of the port programming community, which tends to be documented only by infinitesimal shreds of discussion across 12 years of newsgroup posts, forum threads, and chat logs.    Ryan W 07:35, 11 February 2009 (UTC)

Disputed, Undisputed are essentially POV
I hate to open up old sores just for the sake of argumentation, but I really wish that we could move this list away from the use of "disputed" and "undisputed" terminology, because these inherently violate NPOV. I don't believe there's a firm enough consensus on what a bug, glitch, etc. is being defined as, and I don't believe there's actually a broad agreement on some of these things. For instance a quick scan revealed the following items that I personally disagree with: Between all these points, I think it would be better to come up with some other method of classification that's more satisfactory and less dependent on POV. --Quasar 19:36, October 31, 2009 (UTC)
 * Fast doors make double-close sounds - No way id didn't notice this. It was left intentionally IMO.
 * Lost soul limit - Have you actually tried playing the game with this disabled? God it's annoying. This was an intentional limitation made for game play balance and memory usage purposes.
 * Blast damage range is vertically unlimited - It may seem odd, but it's coded that way deliberately. By no definition does it "accidentally" fail to account for vertical range - more like it acts like the entire concept of vertical range is non-existent.


 * IMHO it would be wonderful if this article reflected the classification(s) actually used by port programmers. On the other hand, everyone knows how often programmers write documentation for free.  :>   I assumed that we non-programmers had to pitch in and do the best we could.  I personally would be OK including only the Obvious BugsTM, as long as the other information is still listed somewhere on the wiki (without "bug" in the title).


 * FWIW, the "disputed"/"undisputed" terminology is an attempt to *avoid* POV, by basing it as much as possible on acknowledged expert specialists (the port programmers) whose judgments might actually be on record somewhere for us to cite. Quasar, I share the community's respect for your intelligence and your programming skill, but statements such as "No way id didn't notice this" are conjectural.  None of us was there during the alpha testing.    Ryan W 06:16, November 1, 2009 (UTC)


 * I actually have no issue with this list's contents. Some of the things it lists are not "bugs," but they are engine oddities and poorly programmed limitations (malloc WAS available in 1993, despite whatever id seemed to think...), and to the end user there is no real distinguishing factor between something like a Z_ChangeTag error due to random memory corruption, or a savegame buffer overflow (one unintentional, the other sadly intentional) - they're both negative behaviors. I would like for this list to continue to list such things. I am just not comfortable with it calling them "undisputed bugs," when many of them are not really "bugs" in the first place. Hope that clarifies my point.


 * As for the doors, well, you don't have to go beyond the first room of MAP02 to hear the behavior of those suckers, and it persisted all the way from 1.666 to 1.9, and was copied into the Ultimate and Final codebases without being addressed. It stretches belief to suggest nobody listened to blazing doors closing in all that time and didn't say "hmm you know that is odd," or "I actually like it that way, let's leave it be." But I'm not here to really argue about that stuff. It's just one of the things that was an example of something that is not in my eyes worthy of being called "undisputed." --Quasar 02:11, November 4, 2009 (UTC)

I am still, and increasingly so, unsatisfied with this. Expect me to come up with an alternate proposal for categorization that doesn't include "dispute" as part of the factors. There are a number of categories that can be used such as "bug" where something is clearly coded incorrectly, "inconsistency" for things that create an incoherency in game play but aren't harmful, "deliberate limit" for things that are just lazily implemented, etc. There is just simply zero need to bring the concept of dispute into this article as if to suggest that the community of port authors have descended upon this article and individually decided which of these entries they do or do not agree with. While I'd love for that to happen it clearly will not after almost 10 years of existence. --Quasar (talk) 14:49, 30 May 2014 (UTC)


 * I have to agree with Quasar on this:
 * * Fast door double closing sound is obviously an intentional environmental effect, this also exists in Doom 64 except with a different sound effect.
 * * The lost soul limit is also not a bug because other old and new games also have these limits for the sake of performance and memory requirements, eg limiting the number of corpses
 * * Unlimited vertical damage is an after thought, damage done this way was lousily implemented. Similar to how the player cannot go over/under monsters and decorations
 * Russell (talk) 22:50, 31 May 2014 (UTC)


 * Most of those columns were added by me, after a few threads involving other interested editors who were also not port programmers. This is not a secret; several discussions can be seen above.  I have never claimed definitive knowledge of anything beyond the id changelogs.


 * That said, I now understand that our readers assume every article to be written and lorded over by involved parties. Therefore, they think my edits represent programmers' views.  This seems insane to me, but apparently it is the norm.


 * If a programmer is reading this and it will help them sleep better, please rip the categories out, or tell me how to replace them with something more correct (if that's even possible). I don't care.    Ryan W (talk) 18:45, 4 July 2014 (UTC)


 * It feels to me like you're taking it the wrong way. The only column that is problematic to me is the one that uses Disputed/Undisputed as a value and only because it seems to represent a consensus that does not exist. In my opinion, it doesn't add any informational value to the table. It'd be better to use something that explains what kind of issue it is more thoroughly and let readers come to their own conclusions on whether something is a pure bug (by the "dictionary" definition of a mistake in the programming) or an intentional but quirky/deleterious behavior. Nobody expressed a lack of appreciation for the work that has gone into this article; it's a critical part of the wiki. --Quasar (talk) 14:29, 5 July 2014 (UTC)

Lack of random sound pitch
I vaguely remember reading somewhere that Doom was originally meant to have random pitch changes to the sounds, to give some variety to the cries and shouts. This was broken because of DMX being buggy, though. However, when Id Software rewrote their old code (having access to the full source, including the sound API that had been cleaned out by Bernd Kreimeier) to port it to the Xbox 360, they restored this feature. It can be heard here for example. Should this count as a bug? --Gez 21:27, February 20, 2010 (UTC)


 * Maybe- But despite anything, random sound pitched worked in 1.2 and I believe that is the last one that has it. GhostlyDeath 05:48, February 21, 2010 (UTC)


 * The pitch shifting that IS in the XBox 360 version could itself be considered a glitch in my opinion, as they obviously did no tweaking to it to get an output range that's anywhere close to authentic. Instead the range used is wider even than those that were employed in Heretic and Hexen and sounds pretty terrible in my opinion. This is similar to how they somehow never noticed that the 22050 Hz SSG sounds are playing at the wrong sample rate. How can all these devs have never actually played Doom? It's probably some kind of revelation about what's actually wrong with the game industry these days - no respect for what came before. --Quasar 13:15, 26 February 2013 (UTC)

Lower unpeg + sky hack
There is in Doom a hack that, according to the comment, is needed for height changes. This all happens in. First, two values are defined, at separate places in the code but I'll put them together here: worldtop = frontsector->ceilingheight - viewz; worldhigh = backsector->ceilingheight - viewz; So, worldtop is the front sector's height, and worldhigh is the back sector's.

// hack to allow height changes in outdoor areas if (frontsector->ceilingpic == skyflatnum 	    && backsector->ceilingpic == skyflatnum) { 	   worldtop = worldhigh; } But it has a side-effect for lower-unpegged textures: if (worldlow > worldbottom) { 	   // bottom texture bottomtexture = texturetranslation[sidedef->bottomtexture]; if (linedef->flags & ML_DONTPEGBOTTOM ) { 		// bottom of texture at bottom // top of texture at top rw_bottomtexturemid = worldtop; } 	   else	// top of texture at top rw_bottomtexturemid = worldlow; } Lower-unpegged textures use the "worldtop" (front) value, and this hack has set it to "worldhigh" (back) instead of what it should be without the hack. So in an outside area, lower-unpegged textures are aligned according to their back sector instead of their front sector. To me, this looks like a bug as I don't believe "allowing height changes in outdoor areas" translates to "changing the way lower unpegged textures work" and it can break texture alignment. Some source ports with a renderer not derived from Doom's original software renderer may also miss this entirely (this is notably the case for GLBoom+ and Eternity), while others like GZDoom take it into account and imitate vanilla's discrepancy.

Questions: 1. How to call it, "Lower-unpegged inconsistency in outside sectors"? 2. Would this be disputed or undisputed as a bug? 3. Why do height changes require this hack exactly? --Gez (talk) 22:01, 9 May 2015 (UTC)