← All articles

Mario's Jump Is Made of Odd Numbers

Everyone who has played Donkey Kong knows the jump. It is short and a little floaty, and once you leave the ground you are committed: no steering, no cutting it short, no second press. You learn exactly how far it goes because it always goes exactly that far.

The original arcade program builds that jump from a few dozen bytes of code. Inside them is a neat piece of arithmetic: the game draws a smooth curve through the air without ever multiplying, using nothing but a counter and a pattern you might remember from school. This article walks through the jump in the original 1981 code.

What you feel at the controls

Press jump and Mario rises 13 pixels, hangs at the top for a moment, and comes down 21 pixels ahead of where he started, a little more than two and a half of the tiles the screen is drawn from. The whole jump takes 42 frames, about seven tenths of a second at 60 frames a second.

Mario's jump, one dot per frame Forty-three dots trace Mario's jump at true scale: up 13 pixels at frames 20 and 21, then down to land 21 pixels forward on frame 42. top: 13 px, frames 20 and 21 takeoff lands, frame 42 21 PX FORWARD · ONE DOT PER FRAME
Mario's jump at true scale, one dot per frame. The dots bunch together at the top, where he moves slowest.

Look at how the dots bunch up at the top and spread out near the ground. That is what makes the jump feel like it has weight: Mario slows as he rises, lingers for two frames at the peak, and speeds up as he falls. It is the shape a thrown ball makes, a parabola.

No steering, by design

When the jump button goes down, the game reads the joystick once. Left, right or centered, that one reading sets Mario's sideways speed for the whole jump: half a pixel per frame left, half a pixel per frame right, or nothing. It never looks at the stick again until he lands.

Every number in this article comes from running the original program under a test script that pressed the buttons and logged Mario's position each frame. Three jumps to the right show the rule: one holding right the whole way, one letting go of the stick at takeoff, and one pulling hard left halfway through. All three traced exactly the same path, pixel for pixel.

It also does not matter whether Mario was walking or standing still. The takeoff code only cares which way the stick points on that one frame, so a running jump and a standing jump with the stick held are identical. And the jump is slower than walking: in the air Mario covers half a pixel a frame, on foot about two thirds.

A curve without multiplying

Here is the clever part. A physics textbook would give Mario an upward speed and take a little off it every frame for gravity. The Donkey Kong code does something that looks odder and works out the same.

Every frame in the air, it does two things to Mario's height:

  1. Lift him by the full launch speed, about 1.28 pixels. This never changes.
  2. Push him back down by a gravity amount that grows each frame: 1 step on the first frame, 3 on the second, 5 on the third, 7 on the fourth, and so on. A step is 1/32 of a pixel.

So gravity counts up through the odd numbers. Add those up and something tidy happens:

How odd numbers make the jump's curve A four by four square built from nested L shapes of 1, 3, 5 and 7 tiles. Gravity adds 1, 3, 5, 7 steps on successive frames, so the total after n frames is n squared. GRAVITY ADDS TOTAL frame 1 +1 1 frame 2 +3 4 frame 3 +5 9 frame 4 +7 16 Each new frame adds the next odd number, and the running total is always a square: after n frames, n × n steps of 1/32 px.
Gravity adds the next odd number each frame, and the running total is always a perfect square.

1, then 1 + 3 = 4, then 4 + 5 = 9, then 9 + 7 = 16. The total after n frames is always n × n. Each odd number is exactly the L-shaped border that grows one square into the next.

That means Mario's height after n frames is the launch speed times n, minus n × n thirty-seconds of a pixel. That is the formula for a parabola, and the game never computes n × n. It just keeps adding the next odd number, which it gets from the frame counter with a shift and an add:

ld   a,(ix+$14)    ; n, the frames since takeoff
...                ; turn it into (2n + 1) x 8, the next odd number
add  hl,bc         ; push the height back down by that much
inc  (ix+$14)      ; one more frame

The gravity part lives at $23AE in the program. The launch speed is set once at takeoff, at $1B6E, to $0148, which is 328/256 of a pixel per frame.

Frame by frame

These are jumps from the flat stretch of the bottom girder, with heights including the fraction of a pixel the game keeps alongside Mario's position. To keep him safe, the script cleared every barrel and fireball from memory as soon as it appeared.

FrameHeight by the formulaHeight measured
11.25 px1.25 px
109.69 px9.69 px
2013.13 px13.13 pxtop
2113.13 px13.13 pxstill the top
3010.31 px10.31 px
401.25 px1.25 px
4100back at takeoff height, still in the air
42lands

Every frame matched the formula exactly. One detail is easy to miss: Mario does not land when he gets back to his starting height. The code only notices the girder once his feet are a pixel into it, so he lands one frame later, on frame 42. Over those 42 frames he moves 21 pixels forward, half a pixel at a time.

On the sloped girders the curve is the same, but the ground arrives at a different moment. Jumping uphill, he meets the girder a pixel early and lands on frame 41, 20.5 pixels on. Jumping downhill he lands on frame 43 or 44, and travels up to 22 pixels.

The 15 pixel rule

Every Donkey Kong player has died from a fall that looked harmless. The rule behind it is simple, and slightly unfair.

When Mario takes off, or walks off the end of a girder, the game writes down how high he was. Once he is past the top of a jump, it checks every frame: is he now 15 pixels or more below that starting height? If so, it sets a "fell too far" flag and plays the falling sound. Nothing else happens yet. Mario keeps falling normally. The flag only matters on the frame he lands, when the code sets "alive" to the opposite of it. He does not die from the fall. He dies from landing.

To find the exact limit, the script put Mario a set distance above the bottom girder and let him drop, both as a walk-off and as a jump from a ledge:

DropWalk off the edgeJump from a ledge
13 pixelsliveslives
14 pixelsliveslives
15 pixelsdiesdies
16 to 20 pixelsdiesdies

Fourteen pixels is safe. Fifteen is fatal. The height Mario reaches at the top of his jump never counts, only how far below his starting point he ends up. On the first screen, walking off the right end of the second girder drops him 20 pixels to the bottom one, and he dies on landing every time.

Bouncing off the edge of the world

One last thing is the strangest. If Mario jumps into the edge of the screen, he bounces off it. The code flips his sideways speed, which you might expect. It also flips his vertical speed, exactly, so that the rest of the jump plays the curve backwards.

A jump into the screen edge comes back along its own path Mario jumps left from X 39 and reaches the screen edge on frame 35, still in the air. The bounce reverses his vertical speed, so he flies back along the same curve and lands half a pixel from where he took off, 70 frames after the jump began. SCREEN EDGE takeoff lands ½ px away out: 35 frames back: 35 frames, same path
Jumping into the screen edge: Mario flies back along the curve he just traced and lands half a pixel from where he started.

A jump to the left from 17 pixels away from the edge reached it on frame 35, on the way down. Mario then rose back to the top of the arc, came down the other side, and landed half a pixel from his takeoff spot, 70 frames after he left it. Every bounce tested did the same thing: the time in the air was always exactly twice the time it took to reach the edge.

After the landing

Mario does not move straight away when he lands. The game holds him still for the landing frame and four more, and during that pause it does not even read the controls. A jump pressed then is lost, not saved for later, and holding the button down never starts a second jump. The quickest you can jump again and again on flat ground is once every 47 frames.

Credits and further reading

  • Kef Schecter and contributors, furrykef/dkdasm, the annotated disassembly of Donkey Kong where the jump routines were first identified. Every address here was checked against the original ROM.