Talk:Armor percentage rollover

I Got A Demo
But I can't upload it ("The file is corrupt or has an incorrect extension. Please check the file and upload again.") GhostlyDeath 06:51, January 26, 2010 (UTC)

Too Much Memory Is Required
This is entirely impossible. It would take 20GB of memory just to store the THINGS structures for the 2 billion things needed to cause a rollover, and there is no item respawn in 1.1. The dos extender that doom runs under could never possibly present to its program the existance of more than 4GB of memory space, as it uses 32 bit unsigned values as memory pointers. This is enough alone to conclusively prove that this bug would never trigger. An undesired behavior that can never ever happen is not a bug, just something that's been adequately guarded against. I could see the case for calling some of the size limits that come into play here bugs (like maybe the 2GB per lump wad size limit, which would be the first one you'd hit trying to reproduce this), but this simply cannot happen. 71.58.109.233 01:33, 20 September 2007 (UTC)


 * I was all ready to scream at you for erasing this, only it wasn't actually on this page. :>   As the person who started this article (the only other edit was to fix a typo which was present in the primary source IIRC), maybe I can respond anyway.  I think that


 * the second paragraph could indeed be chopped considerably if (as you and the other discussion argue persuasively) such an overflow is impossible rather than unlikely.
 * the article itself should remain, because although a mild anomaly, it has historical importance (it affected the design of WADs at the time and the fix was widely discussed) and arguably should have been noticed before the registered version was released.
 * the size limits that come into play here should all have articles.


 * The second and third points are based on the opening sentence in the Bugs article (written long before I arrived), which says that we are documenting "bugs, limitations and oddities", not just bugs. For example, Visible sprites limit is included even though (so I'm told) it was implemented intentionally to prevent massive rendering slowdowns.  People have questioned how broad this is, and rightly so, but so far no one has pushed for a formal, detailed notability guideline.  (Maybe Quasar would draft one, if he didn't have 2,147,483,647 other items on his to-do list already.)    Ryan W 05:16, 20 September 2007 (UTC)


 * Addendum: it's "entirely impossible" except by poking, I would say.  :D     Ryan W 00:10, 2 January 2008 (UTC)


 * Ryan, I can't find anything in that thread about poking, but now that you mention in there are a few questions brought up here and there that could be answered by being able to view and modify Doom.exe while it is loaded into RAM. DOSBox can reproduce the All-ghosts overflow bug, so if tools were available it might be possible to pinpoint its exact cause. And of course one could quickly see how extreme amounts of armor might affect gameplay in vanilla Doom. Do you know of any such tools that could work in conjunction with DOSBox? Zack 03:39, 3 January 2008 (UTC)


 * While such a pursuit would be far beyond my own technical abilities, I'm sure many people are interested in that question, since Doom is only one of many DOS programs which could be studied as you suggest. Maybe you should look through the DOSBox forums at sourceforge.    Ryan W 01:34, 4 January 2008 (UTC)


 * All-ghosts isn't a mystery; as far as I know it chiefly results from corruption of the intercept_p pointer, which keeps track of the most recent intercept added to the intercepts list. Because it's declared immediately below the intercepts array, Watcom placed these items consecutively in the BSS data segment, meaning it's one of the first items to get trashed by an intercepts overflow. But there may be more to it than that, admittedly, as intercepts overflows are not always all-ghosts bugs - though in instances they are not, they often crash the game instead due to more drastic corruption. But as far as the problem with this article goes, during normal execution it is not possible to overflow the armor count. A single WAD lump is limited to 2 GB in size, and considering the fact that the maximum file offset may also be no greater than INT_MAX, and that the other lumps have to be present in a valid map, the actual limit on armor items is not even at that theoretical limit. Personally I don't think that the remote possibility of something being done via an extremely malformed DeHackEd patch (such as with entryway's visplane count viewer) warrants mention in every single article on the wiki. Quasar 02:33, January 25, 2010 (UTC)
 * Well, armor is carried over by levels! What you could do is create a sizeable level with shit loads of armor powerups to where it doesn't crash the game or screw it up. Once a level is created, all you gotta do is hard link the wad entries! Simple! GhostlyDeath 05:55, January 26, 2010 (UTC)
 * Did you even do the calculation? Even divided by 9, the number of armor items that would have be contained on the map to cause an overflow in the armor percentage count is 238609295. Each thing entry requires 10 bytes of memory, meaning the THINGS lump, considering ONLY the armor bonuses, and not the player start that is ALSO required, is 2386092950 bytes. That's 2.2 GiB, which is still too large. Sorry! It simply cannot be done, at least not without item respawn enabled, which AFAIK, didn't exist in this version of DOOM and is therefore irrelevant to the discussion. --Quasar 19:57, February 2, 2010 (UTC)

Am I missing something? The article talks about a graphical rollover once you reach 1000 armor (displayed as 000 armor), not about a memory overflow; yet people are talking about billions of armor bonuses... Player start, plus armor, and 800 bonus, that's 802 things, or 8020 bytes, a size that seems well under the limits. --Gez 23:47, February 2, 2010 (UTC)