Non-Reforged movement accuracy

The dash is a timed state, not a cap

Not present in 3.8.0 at all. Holding Run raises both the cap and the acceleration. Letting go does not bleed the speed off: the player keeps the full dash speed for 16 ticks (13.71 of ours) and the speed is then clamped straight back to the walk cap in a single tick — measured 16.0000 → 4.0000 in one tick, in mid-air exactly as on the ground. See Jazz2::Actors::Player::LegacyDashGraceTicks.

Applied-movement cap, the subtlest difference

The original caps applied movement at 8 px/tick on both axes. A dash reports an xSpeed of 16 but only ever travels 8. The excess is momentum, not motion, and it still counts wherever the speed is read — which is what makes a dashing jump launch at −14 while moving no faster than a capped run.

3.8.0 had this on the vertical axis only (LegacyRiseSpeedCap, already correct at 8). Adding the horizontal half was worth 300–570 px of error per dash scenario.

Slopes

Measured: slopes have no effect on horizontal speed or acceleration whatsoever. Walking downhill xs stays at exactly 4.0 and x advances exactly 4/tick while y drops 4/tick; uphill is identical, with no slowdown. The acceleration curve is unchanged on an incline (10.8032 at the same tick both ways). This engine already behaved correctly here — no change was needed.

Jumping into a slope, where 45 degrees is exactly the wrong number

Walking or dashing along a slope needed no change (see above), but jumping into one did, and the failure sat on an exact equality rather than anywhere near it.

Jazz2::Actors::ActorBase::TryMoveSubstep()'s airborne branch retries a blocked horizontal step with an increasing upward offset, which is what lets a mostly-horizontal move ride up a gentle incline instead of stopping at its foot. It was gated on abs(stepX) > abs(stepY). A dashing jump travels 8 px across while rising at the applied cap of 8, so against a 45-degree face those two are not merely close, they are equal — and a strict > switches the climb off at precisely the angle it exists for. What follows is automatic: the loop below grinds the horizontal step down until something fits, the leftover is under 30% of the step, HitWall is reported, and Jazz2::Actors::Player::OnHitWall() zeroes the horizontal speed.

Crossing a gap, and the "ledge hop" that never existed

This engine had an original-style ledge hop: running off a ledge gave a small upward boost so the player would clear a small gap instead of dropping into it. Measured over gaps of one, two, three and four tiles, the original gives no such boost. Running off the edge, ys goes straight into the fall gravity — 0, 0.125, 0.250, 0.375, … — and a four-tile gap is crossed having dropped under 10 px, landing on the far edge purely because 8 px of travel a tick outruns the fall. A walk drops far enough to miss the far edge of a three-tile gap and falls in, which is the same arithmetic rather than a separate rule. So gap clearing needs no code at all: the applied speed cap and the fall gravity already produce it, and both are measured exactly. The boost is gone, and with it the last two hand-tuned scale factors in the whole model.

That fix was worth two tiles of reach, and a sweep over gaps of one to six tiles - each with a full run-up, so every gap is met at true top speed - then exposed a second one. The engine was landing a whole gap short of the original at both speeds, because the fall matched tick for tick but the landing did not: how far below a ledge's surface the player may arrive and still be put on top of it, rather than caught by its side.

The original's allowance follows from its own four boundary cases. It clears a two-tile walk, arriving 6.25 px below the far edge, and a five-tile dash, arriving 18.1 px below; it fails a three-tile walk (20.25 px) and a six-tile dash (27.6 px). So the allowance sits between 18.1 and 20.25 px — five eighths of a tile, and Jazz2::Actors::Player::LegacyLandingTolerance takes the round 20.

This engine's reach was whatever the horizontal sub-step happened to be, about 6 px: the airborne branch of Jazz2::Actors::ActorBase::TryMoveSubstep() already climbs when a horizontal step is blocked - that is what lets a sidekick ride up a gentle slope - but only by abs(stepX) + 2.5. A descending actor was therefore caught by the ledge's side. The allowance is opt-in per actor (ActorBase::_landingTolerance, 0 by default) and only the non-Reforged player sets it, since that is the only thing it was measured on. With it, all twelve scenarios agree with the original:

One residual: after landing from a crossing, the original keeps more speed than this engine does, so a run that takes the four-tile gap and then meets the five-tile one clears it there and not here. Each gap approached with its own run-up matches.

The rise, tick by tick

Read off ap_r01..ap_r30 — thirty standing jumps released one tick apart, which is the only family that samples the apex on purpose rather than incidentally. In the original's own units, once per tick:

if (ys < 0) {                                   // still rising
    brake = held ? 0.25
                 : (abs(ys) > 1.0 ? 0.75        // ... and the released rate eases off
                                  : 0.5);       //     for the last pixel per tick
    if (ys + brake > 0.125) ys = 0;             // the rise ENDS rather than overshooting
    else                    ys += brake;
}
ys += 0.125;                                    // gravity, every tick, rising or falling
y  += max(ys, -8);                              // the applied rise cap

This reproduces all thirty peaks to 0.01 px — 58.87, 63.62, 68.00 … saturating at 132.00 from ap_r27, where the release comes later than the apex and stops mattering. Three things in it are worth naming, because each was wrong or missing before and none is visible in a single arc:

• The released rate is two rates. 0.875 while the rise is faster than one pixel per tick, 0.625 below it. Measured either side of that threshold: the step is 0.875 at ys = −1.125 and 0.625 at −1.000. The held rate has no such band, on 379 samples.
• The rise never overshoots by more than one tick of gravity. From −0.375 a released rise lands on +0.250 and keeps it, but from −0.250 and −0.125 it lands on +0.125, not the +0.375 and +0.500 the deceleration alone would give. This is not a one-tick detail: an overshoot becomes a fixed offset on the entire descent that follows.
• The applied cap is what makes the first six ticks flat. They travel exactly −8.0 while ys reads −10.000 down to −8.125, which is worth 6.375 px of the 132 — and a model without it overshoots every peak in the sweep by exactly that.

What it does not fix is the standing jump, still 128.0 px against 132.0. That residual is the time step, not the model: at 60 Hz a frame covers 7/6 of the original's ticks, so the flat capped part of the rise is sampled 6 times where the original samples it 7, and a coarser sample of the same capped ascent covers less ground. The sweep shows it plainly — the error follows the release tick between +3.0 and −4.0 px, and pairs of adjacent release ticks collapse onto one frame (ap_r03/ap_r04 both give 70.96, ap_r17/ap_r18 both 119.00) which no change to the rise rule can separate.

Air turn-around, the one that took five attempts

Since ground and air share one table, turning around in the air is symmetric and keeps its momentum, which is what makes it slow. Four different invented models were tried and rejected before measurement settled it.

Springs set the speed outright

No formula, no added external force, and only the colour matters — the same figure on both axes. 3.8.0 used one shared strength for every horizontal spring and a completely different scale for vertical ones; neither matched. The colours differ in how long they push, not how fast the player visibly moves, because the applied cap holds all three to 8 px/tick.

The first: a spring left under the player's feet fires during the settle. The probe removed the previous scenario's spawned object just before the run rather than at the reset, so the player was launched while the next scenario was still lining up, and that scenario's first logged tick was already 60 px up with a third of its speed spent. This affected the second and third spring in the row and both games — which is why green appeared to rise less than red despite the stronger launch, the figure that made the whole thing look impossible. Cleaned up at the reset, the original's rises come out 267.5, 438.4 and 609.0 px for red, green and blue: linear in launch speed, +170.7 px for each +8 of it. The numbers that had been quoted for green and blue, 326.8 and 377.9, were the contamination.

With both fixed, and both sides measured clean:

The two ticks a spring holds its launch speed before gravity starts — which this engine does not reproduce — account for the blue deficit exactly: the simple model of a capped rise decaying at 0.375 predicts 256, 426.7 and 597.3, and the original sits about 11.5 px above all three while ours lands on the model precisely for blue. Adding the hold would therefore fix blue and make red and green worse by the same amount, so it is not the whole story and is deliberately not applied on its own. What is left is a couple of percent that grows as the launch weakens, which has the shape of integration detail near the apex rather than a missing rule.

Every scenario built out of props missed this, for a structural reason: they all walk into a horizontal spring, at the height it already sits at, where the midpoint of the two positions is the position. Only something falling onto one is affected, and it took a chain in shipped level geometry to produce that — Diamondus 3's west end, where a fall down a shaft lands on a horizontal spring and is thrown along a corridor. There the 10 px decided whether the player cleared a wall one tile up and escaped the chain, or hit it, dropped onto a horizontal pole with no speed left, and was thrown back to the spring for ever. That scenario scored 204.5 px/s before the fix and 0 after it. Reforged keeps the snap.

Float-up areas hold a speed, they do not push

An EventType::AreaFloatUp assigns ys = -8 every tick the player is inside it. Not an acceleration, not an external force, and no ceiling to accelerate towards: measured inside a solid ten-tile column of them, the original reads exactly −8.0000 on every one of the 43 ticks in the field and only starts decaying once the player leaves. It also needs no jump and lifts a grounded player straight off the floor — pressing nothing gives a trace identical to jumping, tick for tick.

The continuous force never assigns a real upward speed, so it oscillated around zero instead of lifting. Riding the test level's diagonal ladder of them gained 149.8 px against the original's 520.3 — the horizontal travel matched to 0.2 px the whole way, so the player crossed the ladder without climbing it. It is now 520.7.

A buttstomp is the one descent the field cannot simply overrule, because it re-asserts its own speed every tick and so never lets the rise be assigned at all. What the original does instead is hold the movement* down to Jazz2::Actors::Player::LegacyFloatUpFallCap while the speed goes on climbing underneath it:

Measured on fu_col_butt, a stomp dropped into the isolating column from clear air: the original covers exactly 4.00 px on every one of the 52 ticks it takes to cross, and the 176 px column takes it 44 ticks against this engine's 43. Three entry speeds land on the same figure — 6 on an ordinary fall, 12 and 16 on the stomp — which rules out the reading that the field's 8 px lift is simply subtracted, since 6 − 8 would carry the player upwards.

This engine skipped the whole field while a buttstomp was running and fell through at full speed, which is the reported "buttstomping a float-up event should slow the fall noticeably". The cap is applied to the buttstomp alone: an ordinary fall does touch it for the single tick before the rise assignment takes over, but capping that as well would put the tighter limit on every frame of a ladder ride where _inFloatUpArea is a frame stale, to reproduce one tick that the assignment overwrites anyway.

A double jump was measured at the same time and needs no change: inside a column it climbs 261.1 px against 257.2.

The copter is a different story, and the answer is that it is not a float-up question at all. It cannot be measured in the placed column, because a copter is only available after a real jump and a probe-placed mid-air drop never makes it so — neither a held key nor a tap train gets the original to engage one from there. fu_copter therefore rides the level's own ladder from the block west of it, which gives both games a jump to start one from, and there the original copters into the field and climbs 479.7 px where this engine climbs 174.6**.

None of that 305 px is the field. This engine never engages the copter at all: it models the original as spending its one chance per airtime on the first press, wherever that press lands, which is what refuses cp_tap55 and cp_tap60 for their whole airtime and is why they match. fu_copter's first tap lands at tick 20 while the player is still rising, so the chance is spent and every later tap refused — but the original, whose first tap is also rising, engages on the second pair at tick 27 with anim 56. So the one-chance rule is too strict somewhere, and the scenario is a knife edge for it.

It is left alone deliberately. The rule was fitted on the cp_* family, which currently matches, and moving it means re-measuring that family rather than trading one mismatch for another. Until then fu_copter is a copter** scenario that happens to run over float tiles, and its gap must not be read as a float-up defect.

And there is no gravity on a tick spent inside the field, which is a second rule and had to be implemented separately. The original travels exactly the 8.0 it assigns; ours travelled 7.79 of the original's units because the velocity-Verlet half-step is folded into the move before the applied rise cap gets to clamp it. Every other launch is immune to that by accident: they are all assigned above the cap, so the half-step is clamped straight back off and the travel comes out at the cap regardless. A float area is the one source whose assignment is equal to the cap — Jazz2::Actors::Player::LegacyFloatUpSpeed and Jazz2::Actors::Player::LegacyRiseSpeedCap are both 8 — so it has no headroom and loses the whole half-step. Jazz2::Actors::Player::GetGravityModifier() now returns zero while the player is inside one, which covers both the half-step before the move and the application after it.

A sucker tube re-arms while you are inside it

The tube assigns a speed on each axis outright, and both games agree on that number exactly — a tube set to 8 reads a flat 8.0000, one set to 20 reads 20.0000. What had to be worked out is how the hold ends, and a single tube tile cannot answer it: the player leaves the 32 px tile in four ticks whatever happens, so "a timer" and "still inside a tile" predict the same thing.

Two measurements separate them. A 30-tile row of tubes carries the player the whole length in both games, so the speed is re-assigned every tick they are inside one — not applied once. And the two single-tube scenarios hold for different lengths: 20 ticks at 8 px/tick, 18 at 20 px/tick. That difference is exactly the two extra ticks the slower tube keeps the player inside its own tile, which puts the window at Jazz2::Actors::Player::LegacyTubeControlTime = 16 ticks, re-armed while inside.

The window suppresses horizontal friction but not gravity: a tube firing straight up holds its speed only while the player is still in the tile, and the ascent decays at the ordinary rise gravity from there. That is why the vertical case looked like a 3-tick hold while the horizontal one looked like 19.

That last row is inert here and is stated anyway: a tube carries 8 px/tick, so a clamp to 16 never bites and the ride simply continues. It matters because the clamp is one rule shared with the accelerating belt and the sidekick — Jazz2::Actors::Player::LegacyCarryExitRunSpeed — and clamping to the walk cap regardless, which is what this engine did, cost tb_right_run a fifth of its distance: 166.4 px against the original's 222.9, for holding a key that should if anything help. It is 219.9 now.

The release clamp is the one that showed: a tube set to 20 px/tick carried the player 1066.9 px before, against the original's 407.5, because the whole tube speed was handed back instead of being cut to 4. Its Wait Time parameter is still a TODO, and at a value of 3 changes nothing in either game.

Where in the tile the tube holds the player was wrong by 7 px, reported as a centring problem and measured as one. Riding tb_row, the original sits at y = 1327.000 for the whole ride, unchanging — 15 px into the tile at row 41, a pixel above its centre. This engine snapped to 8, a quarter of the way down. The horizontal branch had always used the tile centre; only the vertical one was off. It is Jazz2::Actors::Player::LegacyTubeSnapY now and the ride matches to the digit.

The flying carrot is two accelerations

Reported as the mechanic this engine had least of, and that was right. It is also the second thing on this page that scripted input cannot reach: with the carrot collected and jjPLAYER.fly reading FLYCARROT for a whole run, eighty ticks of scripted Jump move the original's player not at all — not even an ordinary jump — while Left and Right get through normally. The flight reads the raw key, exactly as the rev-up does, so it was measured from a hand-played recording of 3871 ticks of continuous flying.

The travel is capped at 8 px/tick throughout, the same applied cap a spring or a dash gets, so the speed number running on to 32 buys height only in how long the climb sustains itself — the trace shows ys reading −27 while y still moves exactly 8 px a tick. That cap was already in place here and needed nothing; it is what makes the climb rate match at 8.035 against 8.000.

The accelerations are as clean as measurements on this page get: 934 ticks of the first recording step by exactly −0.25 and 1243 by exactly +0.0625.

The brake has a held and a released form, exactly as an ordinary jump does and with its own two numbers: 0.25 with Jump down against 0.75 with nothing. The second recording shows both inside one manoeuvre — a jump taken from the ground into the carrot decays at the ordinary 0.375 for the six ticks it is still a jump, and at 0.25 from the tick the flight animation takes over, for thirty ticks with Jump held throughout. Jumping while already flying launches at −10 as usual.

And Down is a fourth rate that is not an acceleration at all: it assigns 1.0625 px/tick and holds it. The recording snaps from a 3.3125 px/tick fall straight to it on the tick Down goes down, then reads 1.0625 for 734 consecutive ticks without varying; letting go resumes the ordinary fall acceleration from wherever the speed had got to. That is what "descends slowly on Down at a rate that is not the copter's" turns out to mean — Jazz2::Actors::Player::LegacyCopterDescentSpeed is 1.0078, close enough to sound alike and far enough apart to measure.

Ours now reproduces all four: 0.2502 against 0.25 with Jump held, 0.7507 against 0.75 with nothing, 0.0625 exactly for the fall, a flat 1.0625 on Down, and the crossing from rise to fall clamping to exactly zero rather than overshooting, as the original's does.

The slide tile swaps the brake

A MODIFIER_SLIDE tile adds nothing to the movement and changes no speed. It replaces the deceleration that applies with no direction held, so a player who lets go coasts further — which is the whole of what it does, and why it was missed: EventType::ModifierSlide was converted from the JJ2 event and then read by nothing at all.

Its 2-bit Strength parameter scales both brakes, linearly, and all four values were measured:

All in 65536ths of a pixel per tick squared, and both columns are straight lines: 4000 - 800*s and 12000 - 2500*s. Note that strength 0 halves the walk brake but takes the dash brake to 3/7 rather than 1/2, so a single "slide factor" applied to both would be wrong — and measuring only strengths 0 and 3 would have given ratios of 2.5 and 2.67 and fitted no divisor at all. Four points for a four-value table.

Travel after letting go, against the original:

The residual ~1.2% is the same discretisation the ordinary deceleration carries; a walk that ends in a stop matches to 2%. See Jazz2::Actors::Player::LegacySlideWalkDecel.

Wind and belts move the player, the accelerating belt drives them

Three event families push the player sideways without being touched, and none of them had ever been measured. Two of the three move the player by position — the original's xs reads 0.0000 for the whole time a player is being blown or carried along — and the third works on the speed instead.

Each figure is fitted on two strengths, not one — the mistake Poles obey two different laws was recorded with. Wind at 8 gives 4.0 px/tick and at 4 gives 2.0, so it is linear through the origin. A belt at 8 gives 8.0 and a parameterless one 2.0, which is what pins its default at 2 rather than 3: a single point would have fitted "strength 4 × 0.5" just as well and been wrong everywhere else. Wind and belts share an event type in this engine but not a strength — a belt pulls exactly twice as hard as a wind of the same number.

Steady speed and cap are now exact at both strengths measured, and travel is within 1.4-3.7%. What is left is the first two or three ticks of the ramp, where a per-frame reading is being compared against a per-tick one and the acceleration conversion makes ours a third of a tick ahead.

The belt is also the one carry fast enough to show that the exit clamp has two targets rather than being skipped while Run is held: both strengths snap from 18 and 24 to exactly 16 and then decay at the dash brake, where with nothing held they snap from 6 and 12 to 4 and decay at the walk brake. A tube carries 8 px/tick and Spaz's kick leaves at 15.88, so the 16 clamp is inert at both — which is why the sidekick's measurement read as "Run skips the snap" and could not be generalised. See Jazz2::Actors::Player::LegacyCarryExitRunSpeed, which all three sites now share.

Riding the belt with Run held, the original also travels less than the speed it reports — 10 px/tick while reporting 18, and 16 while reporting 24 — which was recorded here for a long time as unfittable, because those two points alone cannot tell a cap from a subtraction of 8. The ramp is what tells them apart, and it was in the trace all along: on bl_acc_right_run the travel follows xs exactly while it climbs, 5.145, 6.719, 8.291, 9.863, and only then flattens at 10 while xs carries on to 18. A subtraction would have started at 10 and it does not, so it is a ceiling.

One ceiling then fits all four combinations — the belt's own strength plus the walk cap, with the Run bonus left out:

So Run raises what the belt drives to by twelve and what it actually moves the player by four. Ours was fully exempt from the applied cap and travelled the whole reported speed.

A one-way floor is passable to the body and solid to the jump

Nearly all of this was already right. Both games let a rising player straight through a one-way platform and both catch a falling one on it, frame for frame: on ow_hop, a hop from the platform at row 33 that peaks just above the one at row 31, the two pass through at the same tick and come to rest 2 px apart. Holding Down on one does not drop the player through in either game, and neither does holding it through the whole fall onto one — ow_down and ow_down_fall both land and stay.

What differs is what the jump test makes of the tile. In the original the platform's own mask still answers "is there ground under the feet", so crossing one with the jump key held launches a fresh jump. A ladder of them can therefore be climbed by simply holding the key, and that is measurable: on ow_jump the original's rise resets to exactly −10 as the feet cross rows 31 and 29, two extra launches where this engine took one and stopped four tiles up.

The last row is ow_hold, and it is the scenario the rule should be read off. Every other one here releases the jump key at a fixed tick, and a release that falls within a tick or two of a crossing is worth a whole jump's height — while this engine's scripted input runs about two ticks behind the original's throughout, which is exactly that margin. An earlier ow_jump let go at tick 50 with the original crossing at 49 and this engine at 52, and read as a 50 px error that was nothing of the kind. Both releases are now kept well clear of a crossing, and with the key never released at all the two climbs agree to 2 px over seven rungs.

Two things about the implementation are deliberate and neither is obvious.

Jazz2::Actors::ActorState::CanJump cannot carry this. It is cleared outright for any actor with _speed.Y < 0, and it is also what selects the ground-bound slope path in Jazz2::Actors::ActorBase::TryMoveSubstep(), so setting it while rising would have the slope search snap the player back down onto the platform they are passing through. The question is asked separately, by Jazz2::Actors::Player::IsOnLegacyOneWayFloor(), and only the relaunch reads it. That probe asks the same box the grounded test uses — just below the feet — twice, once with Downwards and once without, and a surface that is solid only in the first answer is a one-way and nothing else. Asking once would also catch the real floor a jump has just left, whose feet are still inside that box for a frame or two, and relaunch every frame: an unbounded rise from any ordinary standing jump.

And the relaunch runs from the end of the update rather than from Jazz2::Actors::Player::HandleJump(), because the original asks the question of the position its move ended on. There is no _jumpTime gate on it: the original's gaps between successive launches are 7, 9 and 12 ticks, and that cooldown is 10 frames — 11.7 ticks — so honouring it would swallow the first two. A cooldown is not what limits this in the original; the spacing of the platforms is.

Poles obey two different laws

• Vertical: additive. 15.625 + abs(entry), slope exactly 1.0, fitted over entry speeds 6.6 → 24.5. A pole hands back everything it was given plus a fixed bonus.
• Horizontal: multiplicative, floored and clamped. clamp(3 * abs(entry), 8, 20), fitted on 0 → 8, 4 → 12, 9.34 → 20, 16 → 20.

This is why poles compound, which is what exposed the earlier flat-value model as a regression. Measured heights against a single pole's 268.6 px:

A pole takes ~140 ticks from grab to launch, which is why chains take so long to play out — and why the probe gives pole scenarios a much longer window than the rest.

The case that separates them is an entry speed of exactly zero — a player who drops onto a pole rather than running into one — and no scenario made of props ever produced it, because every one of them approaches a pole by moving towards it. It turned up the first time the probe was pointed at a hand-built spring-and-pole chain in the test level, where a fall lands on a horizontal pole with the horizontal speed already spent against a wall. Measured on both sides, three ways round (dropped in from the chain, and jumping straight up into an overhead pole facing each way):

So the launch never returns less than 8, and at zero it goes left — not in the direction the entry speed's sign suggests, and not the way the player is facing either: facing right, having arrived from the right, the original still launches left. Both halves matter, and they are one line each: Jazz2::Actors::Player::LegacyHPoleLaunchBonus and a strictly-greater comparison on the entry force.

Without them the engine sticks on the pole for ever. A launch of zero leaves the player inside the pole's own tile; _lastPoleTime excludes that tile for 10 ticks, the player has not moved by then, and it re-grabs — one grab every 70 ticks, indefinitely. That is exactly what a player reported, and the same layout in the original runs the chain through without ever sticking.

What a pole launch decays at

Porting the chain scenarios turned up a difference that had been hiding in plain sight: the ascent off a pole was nearly three times too long, so a two-pole chain rose 772 px against the original's 440. Reading the original's trace tick by tick settles it — the launch is −22.25 and the rise decays by exactly 0.875 a tick over 25 consecutive ticks, which is the released rise gravity, even though jump is held for the whole scenario. Applied travel sits at 8.00 a tick throughout, the cap doing its usual job.

This engine used 0.375, the held rate. Since a chained pole is entered with whatever survives the previous ascent, the error compounded down the chain. The pole launch now hands the ascent over in the released state:

The spring-fed case is the one the arrival fix above settles — it was a third short and is now within 0.2%. The five-pole chain is the residual: every individual launch matches, and the entry speeds converge to 0.85% by the fifth pole, so the 6.1% is accumulated grab timing rather than a wrong figure. Note the earlier 1011.2 px reference for it was contaminated by a pole-attached start; 951.4 is the clean one.

And it is not even per launch type: the same pole gives 0.875 reached by jumping and 0.375 reached off a spring, so what a pole hands back depends on how the player arrived at it. Four sources measured, three answers, one of them conditional — there is no rule here to infer, and every attempt to state one has been wrong. Read the decay off the trace tick by tick; the differences are exact multiples of 0.125 and show up immediately, while the height they produce takes 20 ticks to diverge visibly.

The clean reference is 951.4 px, not the 1011.2 that had been quoted. And once both sides are read launch by launch rather than as a total height, the chain turns out to agree closely — the earlier "17% shortfall" was the same contamination on this engine's side, in a trace captured before its own settle check was tightened, where the five-pole scenario began 98.5 px above the ground:

The original's launches grow by exactly +1.125 a pole; ours by +1.319, so the two converge and by the fifth pole they are 0.85% apart. The pole-to-pole spacing is identical at 160 px, and the final free ascent measures 205 px here against 204 there, decaying at the same 0.875 with the same 8 px applied cap. So the law, the bonus and the ascent are all right.

What is left is when the pole is grabbed, and it is visible on the very first one. The original jumps at −10, rises with the held gravity of 0.375 and the usual 8 px applied cap, and at the tick before the grab it is at y = 1253.75 doing −6.625; the next tick it is snapped to y = 1231.00, the pole tile's centre, and 6.625 is the entry speed that goes into the launch. This engine grabs about a tick later — 5.7 px higher up the pole and at 5.62 rather than 6.625 — so a single pole launches 4.5% weak. Each further link then recovers a little of it, which is why a five-chain ends up much closer than one pole does. Correcting it means moving when the pole event is detected relative to the player's hitbox, which is shared event-detection geometry rather than a movement constant.

Push speed was frame-rate dependent

3.8.0 computed pushSpeedX * 1.2 * timeMult — scaling a speed by the frame delta. That made pushing 2.5× faster at 24 FPS than at 60. Measured: a flat 0.375, player and object together, and Run makes no difference (walking into a box and dashing into a rock push at exactly the same rate). This was the one genuine frame-rate bug the whole exercise turned up.

Buttstomp drift bypasses the speed entirely

The original moves the position directly and leaves xSpeed at zero for the whole stomp. There is also a distinct hold phase at the top (ys = 0.0625 for ~30 ticks) before the descent begins.

What the two games do with a powerup monitor

Written once the test level grew a section holding them — two weapon monitors and a morph monitor, none of which _pt contained before, which is the whole reason these had never been measured rather than any difficulty in measuring them.

Most of it agrees, which is worth stating as plainly as a gap would be:

• Walking into a monitor pushes it along the floor in both games rather than breaking it or collecting anything. pu_walk moves the weapon monitor 289.6 px here against 290.6 there — one pixel over a push of nine tiles.
• A buttstomp landing on one breaks it in neither. The player ends up standing on top of it in both.
• An uppercut beside one does nothing to it in either.

Two differences, both about the object rather than the player:

• A monitor at rest sits at y 1968.9 here and 1975.0 there, a consistent 6 px higher. The floor's surface is at 1984, so both are resting on it and the gap is in how tall the object is taken to be.
• A monitor that spawns above the player stays there in the original. mb_stomp puts the player directly under the morph box's tile: the original's box holds at y 1903 — the row it was authored on, two tiles up — for the whole scenario, resting on the player's head, while the player stands at 1970. Ours drops to 1968.9 and ends up overlapping the player, who is at 1968.5. That is the closest thing the harness has found to the reported "morph box floating", and it is a real difference; whether it is the reported one is not established.

A warp hands control back almost at once

The original lands on tick 73, shows one frame of its warp-out pose on 74, and is walking again on 75. Ours waited for the whole Jazz2::AnimState::TransitionWarpOut animation to finish before restoring control, which is 38 ticks — most of a second of standing still that the original never charges, and the reported delay after a warp.

The fix is not to shorten the animation but to stop control waiting on it: the pose still plays and its callback still runs, and a timeout armed alongside simply gets there first. Everything that callback does is idempotent, so the two cannot disagree. Invulnerability and gravity come back with control rather than after it, because the original is plainly subject to both the moment it starts moving. See Jazz2::Actors::Player::LegacyWarpOutControlTime.

One ordering trap, and it cost a build to find: Jazz2::Actors::Player::SetPlayerTransition() with removeControl zeroes _controllableTimeout on its way past, so a timeout armed before the transition is wiped without trace. It has to be armed after.

A frozen exit is left alone — there control is meant to stay away, and Freeze() in the callback is what takes it. The checkpoint respawn goes through the same path and so also returns control promptly, which is deliberate.

Result: 5 ticks against the original's 3, the remainder being frame quantisation (two original ticks is 1.7 of ours). End-to-end travel on wp_walk went from 305 px adrift to 90.

A special move wants the player stopped; the crouch does not

These two rules are easy to read as one and they are not. The crouch engages the moment no direction is held, carrying whatever speed is left — that is what makes a run end in a slide, and it is why the crouched gunspot can put shots out low and moving. The move the crouch leads to does not follow while that slide is still running. Asking for one mid-slide gets a buttstomp on the spot instead, which is exactly how it was reported and exactly what the traces show.

Measured on all three characters with Down held through a dash and Jump four ticks later. The original's specialMove never leaves 0, and what happens instead is an ordinary jump: it launches at −13.08 with 12.33 px/tick still under it, which is Jazz2::Actors::Player::LegacyJumpSpeed plus the usual quarter-of-the-horizontal-speed boost and nothing else. Down is still held when that jump leaves the ground, so the buttstomp follows by itself and runs its ordinary course — the hold at 0.0625, the descent at 10, the landing, and the crouch again on top of it, since Down never went up.

We fired the full move: 201 px of uppercut for Jazz and a 700 px sidekick for Spaz, against 48 px of travel and an 8 px hop. All this needed was to hand over to the standard jump and re-arm the Down edge — _wasDownPressed would otherwise swallow the stomp, having been set when the crouch engaged four ticks earlier and never cleared, because Down is held throughout.

The boundary is Jazz2::Actors::Player::StopSettleSpeed rather than a literal zero. The original tests its own speed against exactly 0, but ours decays on a 60 Hz curve and reaches 0 on a different frame, so a strict comparison would decide this on frame timing across a band about a pixel per tick wide.

One residual: the hop comes out at 3.5 px against 8, and the travel at 39.6 against 48. The sequence is right — crouch, jump, stomp, hold, descend, land, crouch — and the descent matches at 10 px/tick; what is short is the single tick of rise between the jump and the stomp taking hold.

Spaz's double jump

A straight speed assignment, exactly like the first jump. 3.8.0's small speed plus a sustained internal force is why it felt far too weak. Height is then governed by how long the key is held, through the same released-gravity switch as an ordinary jump.

The horizontal speed is thrown away: a dashing double jump leaves at zero and has to build its speed up again from the air acceleration, which makes the move a way to stop as well as a way to climb. Measured directly — sp_dj_a_dash reads xs = 16.0000 the tick before the press and 0.3662, exactly one dash acceleration step, the tick after; the walking cases the same with a 0.1831 step. 3.8.0 only damped it (clamp(_speed.X * 0.4, -1, 1)) and this page previously recorded the speed as carrying over untouched, because every earlier measurement of it was a travel to a wall that both games reach either way.

There is a trigger window, and it is a timer, not a band of fall speeds. Two conditions, both necessary:

• The player must be falling, read from the vertical speed at the start of the frame rather than the live one — the original applies its gravity after the test, so a press at the exact apex reads ys = 0.0000 there and is refused, where the live value has already crossed zero and accepts it.

• The press must land within Jazz2::Actors::Player::LegacyDoubleJumpWindowTime — 30 ticks — of the jump key being let go. Counted the way the original counts it: set on the tick of the release, decremented at the top of every tick after it, tested for "still above zero", so a press 29 ticks later is the last one accepted.

sp_dj_r60_d28 is accepted at a fall speed of 3.00 while sp_dj_hold is refused at the same 3.00, differing only in a delay of 28 against 35 — so the speed cannot be what decides it. The release-at-85 row then retires the speed cap outright: it holds the key well past the apex, so the timer opens twelve ticks into the fall, and delays of 20 and 25 fire at about 4.0 and 4.6 px/tick. Height above ground (accepts at 81 px, refuses at 85) and time since the apex (accepts at 27, refuses at 20) are ruled out the same way.

Watch for this in the probe itself: a scenario that holds jump to its last tick arms the timer when the harness clears the input at the reset, and the next scenario inherits an open window. A first version of those two pressed at ticks 5 and 20 and both games double jumped off exactly that.

Pinball paddles and bumpers

Gating it exposed a second one: the paddle had ActorState::IsSolidObject cleared, so with the launch removed the player simply fell through it. That never showed while it launched on contact, because they were always thrown clear before they could drop past.

So the paddle carries the player itself: each frame it places whoever is over it on surfaceY = pos.Y + 0.3 * (distance - 16) and takes their vertical speed out. That reproduces the slope to within a pixel across the whole paddle, and it is also how the original's from below behaviour falls out for free — driven up into a paddle the player is not blocked at the underside but appears on the surface in one tick, 27 px above where they were, and stays there. The carry pauses while a launch is in flight, or it would snap the player straight back down onto the surface on the very next frame and undo it.

The launch is a straight speed assignment, linear in the distance from the mounted end on both axes, with a floor near the mount. Measured eight pixels at a time across both paddles, in the original's units:

So ys = -max(4, d - 16) and xs = ±max(0.5, (d - 8) / 32), directed away from the mount. The two paddles come out a constant two units apart vertically and a sixteenth apart horizontally — a mirrored pivot landing on a different pixel rather than a different rule — so one mirrored formula sits within a unit of either, which is where ours now is at every measured distance.

The player is held in the sucker tube's curled-up ball the whole time they are standing on one, not just during the launch — the original's trace shows that pose several ticks before the jump press that fires it. It is chosen in UpdateAnimation() alongside the lift poses, because anything the paddle assigns directly is overwritten on the next frame.

speed = (playerPos - bumperPos + 1) / 4      // both axes

Every hit measured fits it to four decimal places: a drop through the centre caught 36 px up leaves at −8.75; one 16 px to the side caught 28 px up leaves at (−3.75, −6.75); an approach from below caught 47.25 px down is driven back down at +12.0625; and a later bounce at an offset of (0.134, −38.12) leaves at (0.2834, −9.2803). 3.8.0 used a normalised radial impulse times a blind 15, which is the wrong shape as well as 35% weak — normalising throws the distance away, and the distance is what the original scales with.

That +1 is why a player ever escapes a bumper. A drop through the exact centre is otherwise a perfect fixed point: no horizontal component, straight back up, for ever. That is what ours did — thirteen bounces on the spot in 800 ticks and still going — while the original's offset grows every bounce, because the rule is linear in it, and throws the player clear after about eight. Ours now escapes in six.

What is left is where the catch happens, which now sets the strength: the original catches 36 px above the centre and ours 30, worth −8.75 against −7.25. Much of that is which tick the overlap first lands on, since the player is falling about 8 px a tick there, and the rest is the trigger being a radius where the original's is not quite one — it catches at 36 px directly above but only 28 px up when 16 px to the side. Pinning it needs a scenario that drifts into a bumper slowly rather than dropping past it.

Hitting your head on a ceiling

Measured against a staircase of 2-tile-wide bays over one floor, clearing 2, 3, 4, 5 and 6 tiles. A standing jump rises ~132 px, so the first three are struck and the last two are cleared — which is the whole interesting range in one place. The strike stops the ascent where the head meets the tile and the fall begins from there; nothing else about the arc changes.

The two that clear differ by the ordinary standing-jump residual (132 against 128, the same figure sp_jazz_dj shows) rather than anything to do with the ceiling. Walking and dashing through the section agree as well — apex 345.1 against 347.4 walking, 366.5 against 366.3 dashing — read heading west, so the ceiling drops ahead of the player: going east runs out of the section entirely and into a 17-tile wall, which the player then climbs.

Spaz's double jump in the same bays agrees at 2, 3 and 4 tiles and diverged at 5 and 6, which is what uncovered the trigger window in the first place — see Spaz's double jump.

Lori's kick accelerates

Its speed is exactly (n/2)² px per original tick — 6.25, 9, 12.25, 16, 20.25, 25, 30.25, 36, 42.25 — a quadratic ramp over 13 ticks summing to 204.75 px. It is also the only move exempt from the applied cap (its last tick alone travels 42 px). Spaz's is the opposite: a flat 16 while he visibly travels 8, the cap doing its job. Matching her distance while starting at the 42.25 peak covered the same ground in a third of the time, which is what "endpoints hide a wrong curve" means in practice.

She also kicks over and over while Down and Jump are worked, unlike Spaz. The repeats come 45 ticks apart (kicks logged at t48, 93, 138, 183, …) against a jump press every 15, so at first this looked like a cadence the game itself paced. It is not: 45 ticks is simply how long the move runs. Holding control for its own length and needing the crouch back before the next press counts produces exactly that spacing — ours lands at t42, 86, 131, 176, gaps of 44/45/45. An explicit cooldown on top of that was tried and made it worse, stretching the gaps to 75, because arming it in the launch callback (a third of the way in, at the end of the wind-up) pushed every repeat a whole input period further out.

Spaz's sidekick drives, then coasts

His 504 px total was first read as a decaying dash, 81 ticks of falling speed, and written off as unreproducible. That was a misreading: the burst detector counting those 81 ticks had swallowed the wind-up. He actually holds a flat 16.0 (8.00 px of travel per tick, the applied cap doing its job) from t56 to t110, then drops to about 4 and decays at ~0.122/tick, which is the plain walk deceleration. In other words the dash ends after a fixed driven distance and the ordinary walk model takes over.

So the constant is the driven part only, 440 px, and the coast that follows is ordinary ground physics rather than anything special. Terminating the move snaps him to the walk cap instead of zeroing his speed (Lori zeroes, because her ramp ends at 42.25 and coasting from there would carry her tiles too far), and the countdown ends the move on the same tick it runs out rather than a frame later. Total travel comes out at 503.2 px against 504.5, 0.3% off, and he coasts through 4.17 → 3.34 → 2.84 → 1.67 → 0.84 → 0 exactly as the original does.

With Run held he does not coast from the walk cap: sp_side_run leaves the kick at 15.88 px/tick and decays at a flat 0.4273, the ordinary dash brake, for 664 px against the snap's 456 — and with a direction held as well he simply carries on as a dash at 16 for ever. That was first written up as "the snap belongs to letting go of Run", which is not what it is: the snap has two targets, the walk cap and 16, and his kick leaves at 15.88, so the second one is inert. The accelerating belt is where the difference shows, because its carry reaches 18 and 24. All three sites now clamp to Jazz2::Actors::Player::LegacyCarryExitRunSpeed and the kick is unmoved by it, at 660.0 px.

A kick shoves a pushable, at walking pace

Both characters' kicks push a pushable rock in the original and neither did here. The push is not a special one: it is the ordinary Jazz2::Actors::Player::LegacyPushSpeed, 0.375 px per original tick, and the player creeps along with the object at that same rate while the speed column reads a flat zero — position-driven, like the buttstomp drift, so only the positions show it happened at all.

Two gates kept it out, and neither could ever have opened: _controllable is false for the whole of a special move, and _isActivelyPushing wants a direction key that a kick does not use. What is allowed instead is the kick while it still has budget — what remains of a move after that is a recovery the player stands still through, and it shoves nothing. That one condition is the entire difference between the two characters:

• Lori spends her 204.75 px in twelve ticks and then waits out twenty-odd of recovery, so each kick nudges the rock 4.5 px and stops. Over a held-down run of 22 kicks that is 96 px.
• Spaz runs out exactly as his move ends, so he pushes the whole time: 4 ticks of drive and then 51 of pushing, 19 px in one kick. His 440 px at the capped 8 px/tick is 55 ticks, and 4 + 51 is 55.

A blocked kick therefore spends its budget on what it meant to travel rather than on the crawl it manages. Billing it for the crawl instead is not a small error — the budget outlasts any plausible push, so a kick that meets a rock never ends at all.

Three things then had to agree that had never been compared with each other:

• The object coasts for Jazz2::Actors::SolidObjectBase::PushDecayTime after the last shove, which is what keeps an ordinary push looking smooth across frames where the contact probe misses. The original has no such coast; its rock stops on the same tick the kick does. Left in, it added exactly those 6 frames — 7 original ticks — to every kick, 19 ticks of travel where there should be 12.
• The object's own rate was a per-frame 0.5, which is 0.4286 px per original tick against the player's measured 0.375. The two are supposed to move as one, so the rock crept ahead of whoever was pushing it. This one was never a kick bug at all — it is every push, and it went unnoticed because no scenario had ever compared the object's position with the player's.
• Her ramp summed frame-wise does not reach her budget in the same elapsed time: 60 Hz needs twelve frames where 70 Hz needs twelve ticks, which is fourteen. The distance is what shows in an unobstructed kick and is already right, so the ramp stands there; the duration only shows when something holds the kick up, and there the budget drains at the flat rate the two numbers imply — Jazz2::Actors::Player::LegacyLoriKickPushDrain.

With all three, 22 bursts against 22, starting on the same ticks (76, 111, 146, …, 741, 776 on both sides), 12-tick bursts of 4.7 px against 4.5, and the rock ends the run at 2891 against 2882.

One thing here is deliberately not reproduced. The original drives the player into the object — Spaz lunges 21 px inside it and stays there, and Lori ends a long kick 4.7 px from the rock's own centre, which is inside it too. That is a collision bug in the original rather than anything the movement is supposed to feel like, so our collision goes on stopping the player outside. It is why the single-kick scenarios still come up a few tiles short on distance while the push itself matches, and that gap is expected: do not close it.

Bouncing off a wall onto a ledge

Dash at the wall closing the right end of the test level's upper floor, jump, and turn back in mid-air to land on the platform above and to the left. Everything this needs is already covered by the air-turn and launch-bonus constants, so it is a check on all of them at once rather than a mechanic of its own — and a demanding one, because the platform is six tiles up and only a dashing jump reaches it.

How far out the jump happens decides it. Pressed flat against the wall the player has no horizontal speed left, the launch gets no speed bonus, and the jump reaches 132 px instead of 209 — not even close. Both games agree on all of that:

The one disagreement is the 5-tile jump, where the two land within 2 px of each other on the platform's left edge and then differ on whether the player walks off it — a knife-edge outcome rather than a different arc.

Jazz's uppercut is nearly weightless

The move resisted several attempts at a model, because ys never reads below −7.5 and yet it climbs 228 px — so it looked like neither an impulse nor a constant force. It is an impulse; what hides that is the gravity. Three clean phases:

• A wind-up of about 14 ticks during which the player does not move at all.
• A driven climb of exactly 30 ticks under a gravity of 2048/65536 = 0.03125 — a twelfth of the ordinary rise gravity, which keeps the rise almost linear for its whole length.
• Then ordinary gravity, from the tick the move ends, with the rise still at about 5.7 to spend.

3.8.0 instead gave it a small speed plus a sustained external force and ended it once the rise had decayed to −2, which came out 16% short. With the measured model the height is 228.5 px against 228.3.

One oddity, recorded rather than resolved: the original reports ys = −7.5 decaying to −6.59 while the position advances 6.59/tick decaying to 5.69 — a constant offset of about 0.84 that the applied rise cap cannot explain, since every value involved is already under it. The constant is taken from the travel, because that is what the player sees and nothing reads this move's vertical speed. See Jazz2::Actors::Player::LegacyUppercutSpeed.

Bouncing off an enemy you buttstomped

Measured against the test level's own tube turtle, dropped onto from 420 px up. The stomp arrives at its governed 10 px/tick and leaves at a flat −13, then decays at exactly 0.875 a tick with travel held to the usual 8 px cap:

The bounce is faster than the fall that caused it, which is what rules out the old model on its own: no factor applied to a 10 px/tick impact yields 13, and since the descent is governed at a constant 10 the impact never varies anyway. The remaining 4.8% on the rise is discretisation, not a constant — ours lands on the analytic 82.3 px while the original's discrete stepping loses about four pixels of it.

Two things had to be got right besides the number:

• The enemy has to be one the level contains. An enemy spawned with jjAddObject is inert in the original: the stomp descends straight through a tube turtle sitting exactly where it was aimed and lands on the floor beyond it, with the turtle still alive afterwards. This is the same limitation that defeated the pushable scenarios, and the same fix — both probes now locate the level's own object by scanning the event map at prime.
• The ascent decays at the released rate. Like a pole launch and unlike a spring, so _jumpReleased is set here too. Three launch sources, three different answers, and the only way to know which is to read the trace — see What a pole launch decays at.

Blasting yourself off a wall with an RF shot

Firing an RF into a nearby wall throws the player off it, and the throw is not the ordinary knockback: the horizontal speed snaps to exactly 8.0 — the applied-movement cap, so every pixel of it is travelled — and is then held for 30 ticks with friction and the direction keys both suppressed, even standing on the ground, where nothing else in the game slides at a constant speed. When the hold ends the speed snaps to the walk cap and decelerates at the walking rate, exactly as Spaz's sidekick does, for about 302 px in all. Off the ground the blast also assigns ys = −12, and the rise that follows decays at the released-jump rate even with jump still held. See Jazz2::Actors::Player::LegacyRFBlastSpeed and Jazz2::Actors::Player::ApplyBlastKnockback().

3.8.0 had a one-off external force of 4 here, which moved the player a few pixels. Ours now reproduces the whole shape, 304.9 px against ~302. Three things had to be got right for it to work at all:

• The direction cannot come from the positions. Point blank the shot comes to rest within a pixel of the player and can easily end up marginally behind them, which threw the player into the wall instead of off it. Which way the shot was travelling is what decides it at that range.
• The reach is one tile. Parked 24 and 36 px from the wall the original throws the player; parked 48 and 64 px away nothing happens. The engine's own search tests the player's box rather than their centre, which reached about 52 px and blasted in cases the original ignores, so the distance is now re-tested against Jazz2::Actors::Player::LegacyRFBlastReach.
• Fire from a standstill to measure any of this. Fired while dashing the shot inherits the player's speed and reaches the wall long before they do, so the distance at detonation is not the distance that was set up — a sweep done that way looks like a reach measurement and is not one.

The reach was later re-run at whole tiles, one to six, with the ammo count logged alongside so a trace showing no blast could be told from one where the shot was never fired. It holds up exactly:

So the cut-off is real and sits inside the first tile, the speed is exact, and the travel is 2.2% long.

The airborne kick is exact too, which took a tick-by-tick read to establish because the totals disagree badly. Fired point blank from a jump (wb_rf_j0) the original peaks 168.6 px up against our 101.4 — but every constant in it matches: the blast assigns ys = −12.0 there (−14.0 here) and the ascent then decays at 0.875 a tick (1.1921 here), both read off the two traces directly, and the jump before it decays at the held 0.375 on both sides. The ammo column pins the firing to tick 169 on both sides as well.

What differed is when the shot goes off: ours detonated on the very tick it was fired, the original's takes nine more ticks. So the blast replaced the ascent nine ticks earlier here, and the 67 px was the jump the player did not get to finish. That is shot flight time, not knockback, and it lives in RFShot rather than anywhere in this document's model — which is why it sat here as a note for as long as it did.

Features the original does not have must not read the legacy constants

The ledge climb is this engine's own addition. It rises on one assigned speed with gravity off for the whole transition, so the height is simply that speed times the animation's length. The old code wrote -1.4 and then had a frame of gravity added to it by the movement tail, which is why the climb was frame-rate dependent — at 24 FPS barely a third of the 60 Hz rise survived.

Folding that frame in fixed the frame-rate dependency but introduced a worse bug, because it was folded in as GetGravityModifier() rather than as the level gravity. In non-Reforged mode that returns the original's rise gravity, which is three to five times heavier than the engine's:

The released case is the one that mattered: _jumpReleased is set by any approach that involved letting go of jump, which is nearly all of them, so in practice the climb lifted the player 8 px instead of 44 and never reached the ledge. It now reads the level gravity, giving −1.16 in non-Reforged and −1.10 in Reforged, both exactly what they were before this work, and 44 px at 24, 60 and 144 FPS alike.

The lead is aimed by the input, not by the speed

This is the finding the other three follow from. Reforged computes its lead from GetSpeed(); the original aims it at whichever direction is being held. Both readings fit an ordinary run, and two scenarios separate them:

• g_dash_rel releases the direction while the player is still coasting at 9.6 px/tick, and the original's lead collapses to zero anyway.
• g_dash_relrun releases only Run, keeping the direction. The lead keeps growing past the walk value to 65 px and only starts closing once Jazz2::Actors::Player::UpdateDashState() clamps the speed back to the walk cap — so the size of the target does follow the dash, even though its existence follows the key.

Reading the speed is what produces the forward lurch at the start of a sidekick, which was reported separately and is not a separate defect: a sidekick carries 16 px/tick with nothing pressed, so the original pans not at all — sp_spaz_side_rel reads a flat -8.00 for the whole move, the camera sitting one tick's travel behind the player — while reading the speed runs the lead out to 117 px and back. The same rule covers every other move that carries speed the player did not ask for.

It has to be read as travel, not as a speed, because the two disagree at exactly this point. The original's xs is 0.0000 against the wall, but ours keeps a phantom 0.4989: the collision stops the movement without clearing the speed. Any threshold low enough to leave a genuine crawl alone — the lead is already growing at 0.1831 px/tick on the tick a run starts — would be far too low to catch that. What separates the two cases is not how fast the player is going but whether they are moving at all.

Note the target follows the dash state rather than the speed continuously: the two measured points are the two speed caps, and Jazz2::Actors::Player::IsDashActive() is exactly the window in which the speed is the dash cap, since the grace that outlives the Run key and the clamp back to the walk cap end together by construction.

How the lead gets there

Once per tick, in the original's own units:

step = (target - lead) * 0.5;        // half the remaining gap...
lead += clamp(step, -1.0, +1.0);     // ...but never more than a pixel

The 0.5 is read straight off the end of the approach, where the steps go 1.000, 0.500, 0.250, 0.125, 0.0625 — halving exactly. The clamp is what turns the first and longest part into a straight 1 px/tick ramp, and it is active from the first tick of a walk as well as of a dash, which is how the target is known to be a flat distance rather than anything proportional to the speed.

Vertically the camera simply is the player

Measured through a standing jump, the original's camy reaches +7.75 px on the tick of the launch and is back to zero by the apex, tracking the player's own Y to within one tick of its vertical movement for the whole arc. There is no deadzone, no lead and nothing to hold: the vertical camera is the player's position.

Reforged's ±24 px deadzone is a different mechanism rather than a mistuned one, and it does not merely desensitise the follow — it holds a stale offset, because an offset acquired anywhere inside the band is never corrected below Jazz2::Rendering::PlayerViewport::VerticalRecenterThreshold. A probe scenario begins with 21 px of leftover offset from the one before it and keeps it, and through a jump the offset swings from +21 to −22. That is the opposite of the "camera is always vertically fixed to the player" it was meant to produce, and the original is the thing that actually is fixed.

Replaying the recording

The twenty tap offsets of one recorded burst are replayed verbatim by the rt_rec scenario, each press held the five ticks the recording shows, which is what makes the two traces comparable tick for tick rather than merely similar in shape:

The three animations are the original's own revup_start / revup / revup_end, which were already exported for all three characters and simply had no Jazz2::AnimState to hang on. Note both transitions must be non-cancellable: Jazz2::Actors::Player::UpdateAnimation() changes the base state on the very next frame, and changing it cancels whatever transition is playing over it, which cut each of them to a single frame and made them look as though they never played.

Speeding up

Starting a run is the mirror image, and this one really is chosen by speed: the spinning-feet animation between walking and dashing is a band, not a transition. Measured on an_run_start, with Right and Run pressed at tick 20:

This engine issued dash_start as Jazz2::AnimState::TransitionRunToDash on the change into Jazz2::AnimState::Dash, and a transition plays all of its frames whatever the player is doing: eight frames at the sprite's own cadence is 34 ticks, so the dash pose arrived 47 ticks after the key instead of 23, with the player already at top speed for half of it. The band is Jazz2::Actors::Player::LegacyDashAnimSpeed, and the transition is now Reforged-only.

The run animations are played at the speed of the player

Which band is showing is one question; how fast it is playing is another, and that one had never been asked. The original does not play the run animations at a rate of their own — a frame lasts max(1, 12 - |speed|) of its ticks, so the feet go round faster the faster the player moves and saturate at one frame per tick, which is all a 70 Hz game can draw.

The assets say nothing about this. run.aura, dash_start.aura and dash.aura all carry a flat 0.5 s for Jazz and Spaz and 0.4531 for Lori — the converter's fallback, not a per-animation rate — so the rate is in the game's code and nowhere else. This engine used the duration from the metadata, with no speed term at all. Measured across every scenario in the committed original traces, and both characters agree:

The two ends can be checked against a whole loop rather than a single frame, and both land exactly: walking is 8 frames at 8 ticks, which is the 63-tick loop g_walk shows, and dashing is 4 frames at 1 tick, which is the 4-tick loop g_dash shows. Ours were 42.0 and 17.1 — the walk half again too fast and the dash 4.3 times too slow. It is Jazz2::Actors::Player::UpdateLegacyRunAnimSpeed(), and it is the whole of the mechanic: Jazz2::Actors::Player::LegacyRunAnimFrameTicks with Jazz2::Actors::Player::LegacyRunAnimMinFrameTicks under it.

Two things are worth knowing about it.

The duration is rescaled, not assigned. Which frame is on screen is AnimTime / AnimDuration of the way through the loop, so changing the duration on its own teleports the animation — accelerating from the walk cap to the dash cap shortens the loop sixteenfold and would jump the feet by three frames on the tick it happened. Scaling the time by the same factor keeps the phase and changes only the rate.

Reforged had a rule of its own in the same place and it has to be turned off, not merely overridden. Jazz2::Actors::Player::OnHandleMovement() ends with an "adjust walking animation speed" line that stamps AnimDuration for Jazz2::AnimState::Walk from the player's speed, and it runs later in the frame than Jazz2::Actors::Player::UpdateAnimation(). Leaving it in place did not simply cancel the new rule out: the duration reverted there every frame while AnimTime kept the value scaled to the other one, so the phase compounded by 46% a frame and the walk ran nine times too fast — worse than before the fix, and reported as such. The dash was untouched because that line only ever looked at the walk.

At 60 FPS this engine cannot reproduce the top of the curve, and that is arithmetic rather than a defect: one frame there is 1.167 of the original's ticks, so a one-tick cadence is not available at all and g_dash measures a 4.69-tick loop against the original's 4.00. At 144 it is.

The double-jump pose lasts the rise, not the animation

The same mistake, in the other direction. Spaz's double jump shows spring for 11 ticks in the original (an_dj_len, ticks 63 to 73) and gives way to the falling pose on the very tick the vertical speed turns positive — the pose is the rise, and the rise is all it is. Ours issued it as a non-cancellable transition, which ran the whole eight-frame animation over 34 ticks, so the player was still spinning a third of the way back down. The animation's own cadence was never wrong (4 ticks per frame on both sides); only its end was, so it is cut where the original cuts it rather than being sped up.

Down and Jump on the same tick, which was read as a shooting rule

Reported as a pose problem — uppercutting or sidekicking straight after a shot looked wrong — and it is not one. It is also not what this page said for one revision, which was that the original refuses the move while the shooting pose is up. That reading came from one bad control and is worth keeping on the page, because the bad control looked airtight.

Read down the "Down pressed" column rather than the "Shot first" one. Every null result is a scenario that presses Down and Jump on the same tick, shot or no shot, and the two shooting rows are identical to their shotless twins to the pixel. What the original wants is the crouch established before Jump.

The real difference is in the gaps table as Down and Jump pressed on the same tick, and is deliberately not implemented yet: three of its four cases are partial rather than absent — 201.5, 132, 8 px of a 226 px uppercut — so it is a strength curve rather than a gate, and fitting it needs the same sweep run with Jump held for a range of lengths.

Hanging on a vine is not a static pose

The same shape as the sliding stop, and found the same way — by noticing a sprite the converter exports for all three characters that nothing in this engine reads. vine_idle_flavor is a flourish the original plays while the player hangs still, alternating with the one-frame vine_idle 70 ticks each, for ever. Measured on ob_vine_low, which hangs for 800 ticks and goes round six times, changing at ticks 28, 96, 165, 236, 305, 376, 445, 516, 585, 656 and 725. Ours now changes at 30, 100, 170, 240, 310, 380, 450, 520, 590, 660 and 730 — the two ticks are the grab landing later, and every half after it is the same 70.

The flourish loops inside its half: Jazz's is five frames at 8 ticks, so 40 ticks, and it goes round nearly twice before the static pose takes over mid-loop. That rules out the obvious alternative, which is that the animation's own length decides the half. Frame for frame against the original in one window: 7 ticks on the first frame (the phase it was already at) then 8, 8, 8, 8, 8, 8, 8, and 6 as it is cut. It loops through the finish callback for the same reason the stopping poses do.

Shared with Reforged, like the stop chain and for the same reason: there is no Reforged behaviour to preserve, because nothing read the sprite at all. Spaz's flourish is seven frames and Lori's twenty-eight, so neither completes in its 70 ticks; only Jazz's cadence is measured and the other two are given the same 8 ticks per frame.