On flat ground, Sonic the Hedgehog tops out at six pixels per frame. On an NTSC Mega Drive running at 60 frames per second, that is 360 pixels a second, a little more than one screen width (320 pixels) every second. When the game shipped in North America on June 23, 1991, two months before the Super Nintendo reached US stores, that unremarkable number made Sega's console feel like a different class of machine. Thirty-five years on, the community disassembly of the game and the Sonic Physics Guide on Sonic Retro let us read the arithmetic itself. It shows that the speed was less raw velocity than a set of decisions about slopes, angles, momentum and what the screen could redraw in a sixtieth of a second. ## The numbers under the spin: Sonic 1's ground physics Start with the constants, because everything else hangs off them. The engine stores speeds as 16-bit signed integers with eight fractional bits, so the value 256 means exactly one pixel per frame. There are no floating-point numbers anywhere, because the Mega Drive's Motorola 68000, clocked at about 7.67 MHz, doesn't have the hardware for them. The values below are the ones documented in the community physics guide, converted to pixels per frame: - **Acceleration on the ground:** 0.046875 (12/256) - **Deceleration when braking against your direction:** 0.5 - **Friction with no input:** 0.046875 - **Top running speed:** 6 - **Gravity, per frame while airborne:** 0.21875 (56/256) - **Jump launch speed:** 6.5 - **Air acceleration:** 0.09375 - **Slope factor while running:** 0.125 (32/256) - **Rolling friction:** 0.0234375, half the running friction - **Hard cap on speed from slopes and rolling:** 16 Do the division and something odd shows up. Going from a standstill to top speed at 0.046875 per frame takes 128 frames, just over two seconds. Sonic is not fast off the line, and in my view that is the most misunderstood fact about the game. The speed in "Sonic speed" is something you earn over a couple of seconds, and the game is built to let you lose it just as readily, which is why a wall, a spring or an uphill stretch feels like a punishment. Compare that with the other benchmark Sega was chasing. Super Mario Bros. on the NES tops out at a hair over 2.5 pixels per frame when you hold the run button, on a screen 256 pixels wide. Mario needs roughly 100 frames to cross a screen. Sonic needs about 53. The ratio is not dramatic on paper, a bit over two to one, yet it reads as a different sport. Speed on a screen is relative to how much world you can see ahead of you, and Sonic's wider view, faster scroll and long uninterrupted terrain turn a modest multiple into something that feels like a rush. The speed shoes in Sonic 1 simply double the top speed, to 12, which is also roughly where Sonic 2's spin dash tops out. So even the games' "super fast" states live well inside that 16-pixel ceiling. ## One number to rule the ground: how inertia drives everything Here is the design choice that makes the engine tick. On the ground, Sonic doesn't really have an X velocity and a Y velocity. He has one number, a ground speed (the disassembly labels it inertia), and the game derives the horizontal and vertical components from it every frame using the angle of the surface under his feet. Angles in Sonic's world are not degrees. A full circle is 256 units, so a single byte describes any slope, and a lookup table holds sine values scaled so that 256 stands for 1.0. The routine is old-fashioned and tidy. Fetch sine and cosine for the current angle, multiply ground speed by each with the 68000's signed multiply instruction, shift the result right by eight bits, and you have X and Y velocity. The position update then shifts those velocities left to line up with a 16.16 position and adds them in. That cost was not trivial. A frame at 60 Hz gives the CPU roughly 127,000 cycles, and a single multiply can burn dozens of them. Sonic's physics runs this for the player every frame, but only for the player, while dozens of badniks, rings and platforms wait their turn. The engine spends its budget where the player's attention is. The payoff is slopes. While running, the game nudges ground speed by the sine of the slope angle times 0.125 each frame. Downhill adds speed, uphill subtracts it, flat ground does nothing. No special-case code decides that a hill is a hill, because the angle does the work. And if ground speed drops below 2.5 on a steep enough slope, the game locks your controls for 30 frames and lets you slide off. That one rule is behind the heartbreaking moment when you creep up the inside of a loop with too little speed and slump back down. ## How the ground knows its own shape Numbers need terrain to act on, and Sonic's terrain is more clever than it looks. Levels are built from 256×256-pixel chunks, which are built from 16×16 blocks, which reference 8×8 tiles. Every block also points to a collision entry holding a height map, one value per pixel column, plus a separate angle value that tells the engine which way the surface tilts there. Sonic himself is a pair of sensors. Two foot sensors, roughly 9 pixels either side of centre, probe downward and read how far away the surface is. The game snaps him to the nearer one and takes the angle from the tile underneath. Wall sensors do the equivalent sideways, and ceiling sensors cover the top. When Sonic rolls into a ball his height radius shrinks from 19 pixels to 14, which is why rolling lets him slip under things that a standing Sonic can't. Loops are where this gets sly. A block can only carry one collision shape, but a loop needs the same space to be solid on the way in and not in the way on the way out. Sonic 1's answer is two collision layers per level and some logic that flips Sonic between them depending on where he crosses a special chunk. In Sonic 1 that switching is tied to specific chunks, a rather blunt solution compared with the dedicated plane-switcher objects Sonic 2 introduced. It worked because Green Hill's designers laid out the loops with that mechanism in mind. ## Jumping along the surface, and why a held button matters A Sonic jump is not straight up. It launches along the surface normal, so jumping off a slope sends you away from it, and the sine-and-cosine pair is reused to split that 6.5 launch speed into components. Once airborne, two small rules do a lot of work for feel. Horizontal air control is weak (0.09375 per frame, about double the ground acceleration), and while rising slowly the game applies a tiny air drag that bleeds X speed by about 1/32 per frame. And if you release the jump button while still rising faster than 4 pixels per frame, the game clamps your upward speed to 4. That clamp is the entire difference between a hop and a full jump, and almost nobody consciously registers it. ## Speed is a rendering budget Most explainers stop at the physics, but the other half of the story is the picture, because a character that moves faster than the screen can scroll is not fast, it's broken. The Mega Drive's video chip draws from tile maps rather than a framebuffer. Scrolling a level means shifting hardware scroll registers, and only the strip of tiles entering at the screen edge needs to be rewritten into video memory. The nametable the VDP reads from is 64 tiles wide by 32 tall, wrapping around, so the engine always has to prepare the next column or row before the camera reaches it. Sonic's camera is capped at 16 pixels of scroll per frame, which happens to be exactly one 16×16 block. The explanation most people reading the disassembly land on is that one block column per frame is about what the level drawing code can keep up with. I haven't seen Sega staff confirm that reasoning, so treat it as an informed reading and not gospel. Either way, the cap on Sonic's speed from rolling downhill and the cap on the camera agree, and that is not a coincidence. Naoto Ohshima could draw the fastest hedgehog he liked, but the hardware set the limit. Even the sprite art follows this logic. Sonic's animation frames are copied into video memory by DMA only when the frame changes, rather than keeping every pose resident, which frees tile space for backgrounds and enemies. Parallax in Green Hill Zone, with its clouds and water bands scrolling at different rates, comes from per-line scroll data. Both tricks serve one purpose: keeping the world moving smoothly while Sonic moves quickly through it. ## The PAL penalty Here is a gap in most retrospectives that I think deserves more attention. Every constant above is per frame, not per second. The European Mega Drive runs at 50 Hz, so the same game with the same code moves roughly 17 percent slower in real time. A European player's Sonic tops out at about 300 pixels per second, not 360, and a jump arc that takes a given number of frames simply takes longer on the clock. Sega didn't retune the physics for PAL territories, and the music dragged with it. An entire continent grew up with a Sonic that was slightly heavier and slower than the one the designers tuned. The game still felt fast, which tells you how much of the feeling comes from relative speed, not absolute numbers. ## Why other Sonic engines feel wrong Fan games and clones are a good natural experiment. In my experience the ones that feel off nearly always share a root cause: they treat Sonic as a rigid body in a general-purpose physics engine, with velocity vectors and gravity acting on a collider. Sonic 1 does the opposite. It treats Sonic as a point on a surface with a scalar speed, and the surface's angle decides everything. That is why loops work, why a stationary Sonic can stand on a 45-degree slope until a threshold gives way, and why slope speed gain is so predictable that speedrunners can plan routes around it. I'd argue this is why the 2D games' feel has survived successive remakes better than the 3D games' feel has. The scalar-speed model is simple enough to port exactly, and the constants are public. Modern recreations can copy the 16.8 values, the angle-driven slope factor and the 30-frame control lock without needing the original hardware. The part I keep coming back to is the history. Yuji Naka's early work, before the hedgehog existed, was a tech demo of a ball moving smoothly along a long curved line. The character art and the level themes came after. If the thing Sega was really selling in 1991 was that ball, a way of making a curve feel like momentum, then the hedgehog was the wrapping and the physics was the product. So when we call Sonic fast, are we describing his speed, or how convincingly the ground pushes back?