Physics reference

Optimal (TAS) window. Preserve exactly.

Standard input window to regain height during flight.

Identical to ground: the same MarioAccel_ row 0 is used airborne. PlayerInAir only gates the ice-table substitution at $00D753 (ice accel applies on the ground only). IMPORTANT companion fact: releasing the d-pad in mid-air applies NO deceleration - CODE_00D764 drains the P-meter then returns early when PlayerInAir != 0. Air friction of -1.0 applies only while holding a direction at or past the target.

INC SpriteMisc1570 / CMP #$05. Eating any powerup ($74-$77) grows it in one bite instead ($01A2AD).

YoshiGrowingTimer := $40. SpriteLock and PlayerIsFrozen are both held non-zero for the whole window - the world stops. Pose from GrowingAniSequence ($01EBC2), index (timer-1)>>3.

SpriteYPos -= $10 when the baby becomes sprite $35.

A 9-bit angle in $1602 + $151C stepped by +2 or -2 depending on bit4 of the anchor's X position.

InitBallNChain: $187B = $38. The grey chained platform $A3 uses $30 = 48.

InitGreyChainPlat: $187B = $30.

512 angle units at 2 per frame. Position = anchor + (CircleCoords[angle] * radius) >> 8 on each axis.

InitBanzai erases the sprite unless SubHorizPos returns Y = 1, i.e. unless the player is to its LEFT.

LDA #$E8 every frame; no gravity, no level collision. Drawn as a 4x4 tile block (64 x 64 px).

BaseballSpeed db $18,$E8, spawned as extended sprite $0D at x + $10 (facing right) / x - $08 (left) from BaseballTileDispX ($02C460, db $10,$F8) with DATA_02C462 (db $00,$FF) as the high bytes, same Y. Baseball ($02A254) calls ONLY the X integrator - no Y integration and no gravity - so the ball flies perfectly horizontally until the screen-edge erase. snesrev ExtSpr0D_Baseball (// 02a254) agrees.

BigBoo's alternate entry point loads $20 instead of $10.

The $77 bit the head sensor sets; tryJump and the rising-Vy cancel both read it.

The $77 bit the foot sensors set. Separate arm of RunPlayerBlockCode_EB77 from the side bits.

DATA_00E90A db $01,$02 — the $77 PlayerBlockedDirs bit a left-side sensor sets.

DATA_00E90A db $01,$02 — the $77 PlayerBlockedDirs bit a right-side sensor sets. Engine-native grouping; SMW never names the set.

bounce_spr_timer ($16C5) = 8 at spawn; the replacement tile is written when it reaches 0.

DATA_0290DA db $80,$E0,$20,$80; $80 is the sentinel for 'do not touch the player'. Direction 3 sets player yspeed to 0 via DATA_0290D6.

DATA_00F05C. Value 6 spawns bounce-sprite id 7 (spinning turn block); value 7 short-circuits to the brick-shatter path.

BlockBounceXSpeed db $00,$40,$C0,$00.

kBounceSpr01_TurnBlock_YAcceleration db $10,$00,$00,$F0.

BlockBounceYSpeed db $C0,$00,$00,$40 indexed by hit direction.

DATA_00F080. item = v>>1, powerup-dependent = v&1. Negative values index DATA_00F100 by block X position. item 1=mushroom $74, 2=flower $75, 3=star $76, 4=feather $77, 5=1-up $78, 6=coin, 7=multi-coin, 8=vine $79, 10=P-switch $3E.

TileToGeneratePg0, generate indices 0-8. Index 2 = erase ($25), index 3 = vine ($06), index 5 = the spinning-turn-block tile ($48).

TileToGeneratePg1, generate indices 9-23. Index 9 = invisible solid ($52), 10 = multi-coin ($1B), 12 = turn block ($1E), 13 and 22 = used block ($32), 19 = ON/OFF block ($12).

DATA_00F0EC indexed by hit direction j: 0 = from below, 1 = from the right, 2 = from the left, 3 = from above. ANDed with DATA_00F0A4[block].

DATA_00F0C8; index into TileToGeneratePg1 ($00C0E4 = $52,$1B,$23,$1E,$32,$13,$15,$16,$2B,$2C,$12,$68,$69,$32,$5E) offset by 9. Generate-index 13 -> tile $32, the used block.

DATA_00F0A4, 36 entries indexed by (tile_lo - $11). Index 33 (mask 4 = from above only) is the spin-jump turn-block break.

Derived: 8 speed steps x 4 frames each way. Peak-to-peak excursion is 4 px.

db $08,$F8. Direction fixed at spawn by FaceMario; Blurp never re-reads Mario's position.

db $01,$FF, applied when EffFrame & 3 == 0.

db $04,$FC. Direction flips on exact equality.

$1534 = 1 and $1540 = 64 at fuse end; BobOmbExplosion runs until $1540 reaches 0, then status 0.

RESOLVED: $1662 is forced to $11 for the whole explosion, and clipping group $11 is (dispX -24, width 64, dispY -24, height 64) - a 64x64 px box centred on the sprite. Previous [VERIFY] cleared.

The player check additionally requires (uint8)($1540 - 16) < $20, so only 8 of the 16 sprite-hit frames can hurt Mario.

Sprites are killed on the frames where (($1540 >> 1) & 3) == 3.

$15F6 ^= (2*$1540) & $0E once $1540 < $40.

At $1540 == 1 the handler plays SFX_KAPOW, sets $1534 = 1, $1540 = $40 and SpriteStatus = 8 (back to NORMAL), and clears $1686 bit3 so the blast can hit other sprites. The Bobomb main ($0189D8) then sees $1534 and jumps to BobOmbExplosion ($02808A). Because the carried-sprite handler also calls CODE_019624 every frame, this happens identically in the player's hands - the status change to 8 drops it out of the carry state. Below $1540 == $40 the sprite flashes by XOR-ing (($1540 << 1) & $0E) into SpriteOBJAttribute ($15F6).

The Bob-omb branch of the status-9 handler returns before CODE_01969C, so it never runs IncrmntStunTimer (++$1540 every 2 frames) or UnstunSprite. $1540 is only ever decremented, by the generic per-slot timer block CODE_0180D2 ($0180D2), which runs for every non-zero status when sprites are not locked - so the fuse ticks 1 per frame, in status 9 and while carried alike.

When the walk timer expires the Bob-omb sets status 9 and $1540 = $40.

SetStunnedTimer gives sprite $0D the 255 value, and the id-13 branch of $019624 skips IncrmntStunTimer, so it ticks 1 per FRAME rather than 1 per 2 frames.

InitBomb sets $1540 = $FF. An untouched Bob-omb walks 255 frames then sits down by itself.

$1528 advances once per two frames (odd frames only) and wraps at 256, arming $1540 = $A0 each wrap.

SBC #$08 / CMP #$60 - while $1540 is in [8,104) a stomp HURTS instead of crumbling. 96 frames of exposed spikes per 512-frame cycle.

Sprite $B0 negates Xspeed on $1588 & $03 and Yspeed on $1588 & $0C - a perfect reflection with no gravity or acceleration. The ring layout routine CODE_039020 (called every 8 frames, phase = (slot ^ EffFrame) & 7) is [VERIFY].

TileGenerateTrackB ($18C1) is subtracted from the player's Y before the vertical distance test. $10 for the Boo $37 and Boo Block $AF, $20 for the Big Boo $28.

TrueFrame & 7 == 0 gates the +-1 step on each axis, so 64 frames from rest to full speed.

DATA_01F8CF db $08,$F8. Applies to both axes and to $37, $28 and $AF alike.

TrueFrame mask for [Boo $37, Big Boo $28, Boo Block $AF]; the shy Boo sheds 1 subpx per axis on each unmasked frame. 16 / 32 / 8 frames to stop from full speed.

CORRECTED NOTE. ADC #$0A / CMP #$14 is a +-10 px horizontal window, but it does NOT make a near Boo keep moving. Both range tests branch to CODE_01F92F, which freezes when the shy latch $C2 is set. The window's real jobs are (a) at $01F906, to keep an already-shy Boo shy without re-evaluating the player's facing on its 32-frame beat, and (b) at $01F914, to bypass the turn logic. A shy Boo freezes at ANY distance once it faces the player; only a far Boo that still has to turn keeps chasing during the turn.

$1540 = $20. The 'is Mario facing me' test is SAMPLED, not continuous - turning around does not stop a Boo until the next multiple of 32 frames.

$C2 = 1 (shy) iff SubHorizPos's Y equals PlayerDirection ($76), i.e. the player is facing the Boo. Re-evaluated only when $1540 hits 0, then reset to $20 (32 frames). Decision matrix: $C2 == 0 -> always chase; $C2 == 1 and near -> freeze; $C2 == 1, far, already facing the player -> freeze; $C2 == 1, far, not yet facing -> set $15AC = $1F and chase while turning.

CODE_039020 is a TRAIL EMITTER, not a ring re-form. Every 8 frames (per-slot phase, ((slot ^ EffFrame) & 7) == 0) sprite $B0 spawns MINOR extended sprite $0A at its own position with MinExtSpriteTimer = $30 (48 frames) and its own X speed. There are 12 minor slots, round-robined via MinExtSpriteSlotIdx when full. The stream Boo itself is a billiard ball: no gravity, XSpeed negated on horizontal tile contact, YSpeed negated on vertical.

$15AC = $1F; the facing actually flips at $15AC == $10, half-way through.

Searched 3 down to 0; overwrites via $18CD when all four are busy.

BounceSpriteNumber = DATA_00F05C value + 1 ($02882A). The dispatch table at $02904D names each.

Bounce type 7 (spin-jump break of tile $1E): player_yspeed = -48, 50 points, brick pieces spawned, tile blanked via generate index 2.

BulletSpeedX, indexed by $C2. No gravity, no acceleration, no wall reaction.

BulletSpeedY, same index.

No shot when the blaster is within 16 px of the camera's left edge.

ShooterTimer = $60 after every attempt, whether or not the shot happened.

ADC #$11 / CMP #$22 - no shot while |playerX - shooterX| <= 17. This is what lets the player stand on a blaster.

DiagonalBulletTimer advances on odd frames only and fires at $A0 = 160 counts.

GenerateBullet: EffFrame & $7F == 0. Y = (camY + (rand & $7F) + $20) & $F0, side and direction from bit0 of the same random byte.

Platforms2 ($01B563, reached from FloatingSpikeBall $01B559; the brief's $01B99F is not this code) uses if (YSpeed < $40) ++YSpeed - gravity +1, not the shared +3. Shared by $5C, $5D, $A4 and $C4.

While $164A SpriteInLiquid is set, YSpeed -= 2 each frame until it reaches the cap: $F8 (-8) for ids below $5D (the falling checkerboard $5C) and $FC (-4) for $5D and above (orange water platform $5D, floating spike ball $A4, falling grey platform $C4). Net in-liquid acceleration is -1/frame. Only $A4 integrates X; the platforms are vertical-only.

CameraLeftBuffer = trigger - $0C, CameraRightBuffer = trigger + $0C. Total window 24 px, not the 16 px commonly quoted from RGME.

DATA_00F6B3 dw $0090,$0060 indexed by $13FF = PlayerDirection*2. Facing left keeps the player right-of-centre.

Second entry of DATA_00F6B3.

LDA #$0080 / STA CameraMoveTrigger ($142A) on level init.

DATA_00F6BF entries at +8/+10 are dw $FFFE/$0002; applied in HandleLRScrolling ($00CE4C) when $1400 CameraProperMove is set. 144->96 takes 24 frames.

DATA_00F6CF entries dw $0001/$FFFF reduce the camera's horizontal move by 1 px while the trigger is sliding toward its target.

LDA #$00C0 passed into CODE_00F7F4 for non-vertical levels; vertical levels pass (LastScreenVert-1)<<8.

DATA_00F6AD dw $0000,$0000,$00C0, indexed by the same scroll-direction index.

Index 1. Downward scroll is never gated by the grounded check.

Index 2, used when VerticalScrollEnabled ($13F1) is 0 and the level's vertical setting is not 1.

DATA_00F6A7 dw $FFFD,$0005,$FFFA. Index 0 = normal upward scroll.

Second entry. Screen-Y above 124 scrolls the camera down.

CMP #$0070 selects which of the two window edges is used.

DATA_00F69F dw $0064,$007C. Screen-Y below 100 scrolls the camera up.

Indexed by (falling Vy >> 3); signed minimum is retained in MaxStageOfFlight while FlightPhase >= 2. Table entries 9-10 are unreachable.

STX PlayerYSpeed+1 at $00D8B4 is overwritten by the STA at $00D94C in the same frame. Only the STZ MaxStageOfFlight matters. Do not model the write.

back / neutral / back. The neutral frame changes NextFlightPhase so the second press bypasses CapePumpTimer. This is an input PATTERN, not a tolerance window - the spec's phrase '3-frame window' is a mis-framing.

Used at phase 1 once the budget is spent or the X-speed sign disagrees with facing.

114.75 px over 62 rising frames, from budget -56 (requires sustained flight phase 6, Vy >= 64).

34.75 px over 34 rising frames. Budgets -8, -12 and -16 all give this because the -12/frame ramp overshoots them on the same frame.

Frames from the first backward input to the first rising frame when the input is HELD: 1 immediate step + 8 timer frames + 2 frames for the phase-1 clamp/gravity to turn Vy negative. Not a tolerance window.

MarioAccel_ row 14 L columns; only applied on frames with a NEW B press (see CAPE_FLIGHT_BACKWARD_NEEDS_B_PRESS).

Backward d-pad during flight falls through to $00D764 (no friction while airborne) unless byetudlrFrame bit7 is set. TASVideos: 'pressing left and B will slow Mario down; press B repeatedly to slow down more'.

Attractor of accel -6.0 / target -8 / friction +1.0; cycle -13,-12,-11,-10,-9,-8,-7.

Rising + PlayerBlockedDir & $08 zeroes Vy at the top of the player update, before integration. Flight is not cancelled.

The flight branch never writes PlayerDirection and skips the skid/turnaround block entirely.

MarioAccel_ row 14 R-walk/R-run = $0400. With target 48 and friction -1.0 this produces the 51,50,49,48,47 cycle.

DATA_00D535 row 14; identical for all four run levels.

DATA_00D7A5[phase+3] for phase 1..6. Phase 1 uses +1 instead of -12 when MaxStageOfFlight==0, when PlayerXSpeed+1==0, or when X-speed sign disagrees with facing.

Phases 0-6; phase 0 means not in the dive/swoop cycle.