Author Topic: Hypothetical overflow glitch fix (PC)  (Read 3628 times)

nfitc1

  • *
  • Posts: 3011
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Hypothetical overflow glitch fix (PC)
« on: 2014-02-17 18:59:03 »
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:
Code: [Select]
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:

Code: [Select]
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?

Aali

  • *
  • Posts: 1196
    • View Profile
Re: Hypothetical overflow glitch fix (PC)
« Reply #1 on: 2014-02-18 03:09:46 »
Is it possible to trigger this overflow by any other (easier) means than the death penalty glitch? I figure if you spend that much time grinding you can have your instakill attack :P

And of course, even if you were to fix that particular check you could still overflow it to 0 and do no damage whatsoever instead.

nfitc1

  • *
  • Posts: 3011
  • I just don't know what went wrong.
    • View Profile
    • WM/PrC Blog
Re: Hypothetical overflow glitch fix (PC)
« Reply #2 on: 2014-02-18 07:55:40 »
I think Barret is capable of overflowing as well. You just have to find an enemy with a weak enough defense for it to happen.
Also, it order for it to overflow back to 0 you'd have to do over 4.2 billion damage to wrap around. Given the equations we're talking about that seems impossible to achieve. Still, 4.2 billion damage cap is harder to achieve than 2.1 billion. In that case, however, the damage will still be positive and not insta-kill like it does now.

Tenko Kuugen

  • Public Enemy
  • *
  • Posts: 1416
    • View Profile
    • Twitter
Re: Hypothetical overflow glitch fix (PC)
« Reply #3 on: 2014-02-18 08:10:27 »
Barret can overflow with 8 mastered KOTR materia in his ultimate weapon

Both of them can't overflow anymore (Kills only stack up to 65535 for Vincent and even if you take 8 mastered KOTR from my mod, it wouldn't be enough for Barret to overflow) with the raised overflow cap
I have no save to test this though but the math sounds.... sound.