Integer physics and recovery

The fighter model uses signed integer positions and velocities. Horizontal movement is two pixels per update while a direction is held; an accepted jump assigns vertical velocity -9. Negative vertical velocity moves upward because screen Y grows downward.

Executable reading aid

Jump trajectory lab

Step through the same integer rules used for a fighter: an accepted jump sets vy = -9; gravity adds one every second game frame until vy = 6. This is an explanatory trace, not ROM execution.

Experiment starting vertical speed (ROM jump starts at -9)

-9

Reset traceAdvance one updateRun 40 updates

frame 0 · y 143 · vy -9Ground contact: y 143

Try it: count the arc.

Reset with vy = -9, advance a few updates, then compare the every-other-frame gravity change with the trace.

Gravity is deliberately coarse

apply_fighter_physics() adds one to vertical velocity on every other global frame, capped at 6, then adds velocity to Y. That yields a deterministic arc without fixed-point math. The lab above traces the stated rule from the code, including its even-frame gravity condition; it does not read emulator memory or predict every practical jump, because frame_counter phase and platform contact matter.

The platform is a crossing test

A fighter lands only when all of these are true: their 16-pixel body overlaps the platform horizontally, vertical velocity is non-negative, the prior Y is at or above ground Y, and the new Y has reached it. The runtime then fixes Y to 143, clears vertical velocity, marks ground state, and replenishes jumps. Passing under the platform cannot trigger a landing because it fails the downward-crossing requirement.

The system accepts two rising-edge Up presses before a landing. Holding Up cannot spend both: the input code compares current and previous controller bits. Hitstun prevents input processing, but physics still runs, so knockback and falling continue.

Knockback is damage-dependent, then decays

Each successful hit adds damage with saturation at 255. Its initial horizontal magnitude is 4 + (damage >> 4), capped at 14, and then moves one unit toward zero every update. At 64 accumulated damage, the formula produces 8. Knockback also assigns a vertical velocity: -5 for bullet/fireball hits, -6 for a jab, and -8 for axe or Tommy’s kick.

This is a compact tuning curve, not a full fighting-game launch system. There is no directional influence, hitlag, wall collision, ledge grab, or upper blast zone in the current runtime.

Try it

How far does a hit send you?

Set the fighter’s total damage after the hit, then step through the push.

Damage after hit

0%

0%64%160% cap

INITIAL PUSH 4 px/updateUPDATE 0TRAVELED 0 px

Horizontal knockback only. Each step moves the fighter, then reduces the push. Gravity, controls, and KOs are left out.

Step one updateReset trace

At every complete 16 damage, the starting push gains one pixel per update. The runtime caps it at 14.

Why does 64 damage launch at 8?

4 + (64 >> 4) is 4 + 4. The resulting horizontal speed then decays by one each update.

KO is a reset, not a stock transition

Crossing left, right, or bottom bounds increments the other fighter’s KO counter, clears the fallen fighter’s damage and transient action state, then restores a fixed spawn. The HUD shows damage; it does not show the counters. The exact reset follows the source’s BLAST_* checks.

Read combat implementation for how contact enters this physics loop.