Difference between revisions of "Talk:Engine bug"

Revision as of 13:12, 14 August 2007

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?  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)

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)

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 — 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 — 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)

In ep1-2537.zip, 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)

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 <-> 190 --Splarka (talk) 22:11, 4 March 2007 (UTC)

Good heavens!  I would never have thought to check for Template:Ig2 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 — it looks right to put it that close to the wall, but it really isn't?    Ryan W 06:19, 11 July 2007 (UTC)

Bug.Wad

I found a File:BUG.WAD 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 [[Category:Bugs (known)]] 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 — 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.  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)

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)

Bugs not in list

Weapon stays fixed at last bobbing position when firing continuously.