I can't search for this because the 386 processor (anyone else remember having those?) that powers these forums isn't working at its peak.
If this is already known then ignore me.
So recently finding where the limit bar is filled during damage calculation made me stumble upon where damage is actually applied to the targets. That led to the line of code that causes the overflow "glitch".
The code is basically this:
newHP = CurrentHP - Damage;
if ( newHP > previousHP )
newHP = 0;
return newHP;
In a way this makes sense, but only when dealing with HUGE numbers that overflow. Damage is NEVER supposed to be greater than 9999.
Several steps prior to this code executing, this happens:
HPDamageLimit = 9999;
...
if( damage > HPDamageLimit )
damage = HPDamageLimit;
See where this is going? If damage is GREATER than 7FFFFFFFh. The program flow is then bypassed because 32-bit apps treat any value higher than that as negative. I've known about this snippet for a long time, but couldn't quite figure out why it was wrong. Just now I found out what the problem is:
The comparison jump is signed.
The jump that is used is JLE (jump if less or equal) which is a signed jump. Clearly no one was meant to exceed 2147473648 damage. Either they didn't test it enough or thought it so insignificant to be fixed.
Changing this to an unsigned comparison suddenly eliminates this check from operating undesirably. The UNSIGNED equivalent is JBE.
That should be a simple as changing 0x5DAAD0 (0x1D9ED0) from 7E to 76. Since I can't get my game running and can't test it, would someone else do the honors?