There is no such thing as "an arbitrarily large number" in a computer program! :> But I haven't got a working DOS box at the moment, so...
Does it wrap around to zero when it gets to 999%? If so, is that really zero, or are the high digits just cut off? If the high digits are just cut off, what's the actual limit? 32767%? 2147483647%? Ryan W 06:15, 2 November 2006 (UTC)
- It wraps to zero when you go above 999, but it's just showing the last three digits, you're actually at 1000. I wasn't able to find a max, but it's at least 33019. Looking at the released source, it's probably just the max created by the data type used (signed 32bit integer). So you'd hit 2147483648, then it'd look back to negative armor (Not sure what would happen then)
- I do know that's not realistically possible. Getting the 32k armor took nearly 10 minutes, and I only had to cross the beginning room. I was getting about one frame every 30 seconds. Travis Wells 20:59, 4 November 2006 (UTC)
- It depends what you mean by "realistically". :> You could make the helmets invisible with DeHackEd (although you'd need an older version for v1.1 compatibility, right?). Invisible sprites don't slow down the rendering engine, as can be seen in any COMPET-N demo with fast monsters and pain elementals. You would probably also need some kind of palette hack so you could see where you were going (while picking up helmets in LARGE bunches so that this test could be completed within a reasonable time). I forget whether NORED.WAD does this out of the box. The problem would be overflow on the list of Things, period — you can get around the memory ceiling of DOS itself, but it seems like all the arrays in the executable have hard limits also. Perhaps we just have to wait until PrBoom reverse engineers a v1.1 configuration? :D
- I can certainly picture it wrapping around all the way back to zero, then refusing to go below zero when you are subsequently damaged. Like getting more than 127 lives in Super Mario Bros. (although that is slightly different because there is an explicit check for a negative number, eventually). Ryan W 03:03, 5 November 2006 (UTC)
- Well, assuming the in-memory representation of a thing is the same as the on-disk representation (unlikely, but it works as a minimum), that's 10 bytes times 2 billion objects... 20 gigs of RAM.
- So... still "realisticly unlimited".
- (Unless you can find a way to hack helmets to give you more than one armor point per pickup)
- Travis Wells 04:10, 5 November 2006 (UTC)
- Mm, good point. Just designing the level would require a shitload of page flipping.
- Maybe when the Doom engine is as old as the Infocom "P" interpreter, someone will feel reverent enough to try this on a Beowulf cluster or something, and report the results below. :D Ryan W 04:24, 5 November 2006 (UTC)
An obscure hardcoded variable in the original executable *may* affect DeHackEd patches (but I can't tell for sure, so I'm not adding it to the list at Talk:Bugs yet). The following are copied from the PrBoom listserv. Ryan W 21:00, 17 June 2008 (UTC)
>Author: entryway >Date: Mon Jun 9 15:57:17 2008 >New Revision: 2767 > >Modified: > branches/prboom-plus-24/prboom2/src/p_inter.c > >Log: >Fix wrong processing of the "Blue Armor Class" string from a DEH > >Description: >P_GiveArmor(player, armortype) is inlined in doom2.exe. There are >two entries of GiveArmor(*,blue_armor_class) in the sources. >The first is for MegaArmor and the second is for Supercharge. If you >change the "Blue Armor Class" value in a DEH, then dehacked replaces >only the first entry in the EXE (MegaArmor entrie). So for the >second (Supercharge entrie) we must always use armortype=2 instead >of blue_armor_class value from a DEH >Author: entryway >Date: Tue Jun 10 11:37:35 2008 >New Revision: 2768 > >Modified: > branches/prboom-plus-24/prboom2/src/p_inter.c > >Log: >Fix wrong processing of the "Green Armor Class" string from a DEH. > >We must always set armor class to 1 when picking up an armor bonus. >deh_green_armor_class must be applied only for Green Armor