CodingWalaXD Squeezes a Playable Hill Climb Racing Into Exactly 1024 Bytes of Assembly

Most games that recreate Hill Climb Racing borrow libraries, engines, or at least a full operating system. CodingWalaXD went the other direction and wrote the whole thing in raw x86 assembly that starts the moment a computer powers on. The finished binary occupies precisely 1,024 bytes, two ordinary disk sectors, and boots straight into a scrolling side-view race with a car, rising hills, fuel cans, coins, and the familiar risk of flipping over.

After the BIOS has completed its tests, it loads the game’s initial 512 byte sector into memory, which is the section that eventually launches the game, and hands control over to it. Nineteen of those 512 bytes are spent loading the second sector, leaving 493 bytes for the game code. From then on, the code never asks Windows, Linux, or any other layer of the operating system for assistance, instead handling everything itself. It communicates with the old PC’s timer, allowing it to run the animation loop at 122 frames per second. It employs the floating point unit for a few quick mathematical shortcuts and, either because it’s the simplest thing to do or because that’s how things were done back then, draws the visuals directly into a 320×200 video buffer, which every early PC is already familiar with.

The car in the game is really just three points in space: the left wheel, the right wheel, and the center of the body. Each point remembers where it was in the previous frame, adds a small bit of gravity, and then the code checks three invisible “springs” that keep them in place at specific distances. Stretching one of those springs draws the points closer, while compressing it pushes them away. Four quick passes through that routine each frame are enough to maintain the wheels roughly circular and the body seeming like it’s jumping around all over the place, as the body tilts and bounces and occasionally performs a flip when you land poorly. None of these motions are hand-coded as a special case; they just fall out of the physics because the distance restrictions contradict with the motion. This is how the complete physics code, which is 158 bytes in size, works.

The hill environment in the background is generated on the fly using two simple sine waves, one slow and one quick and choppy. Their sum is multiplied by a rising scale factor derived from an arctangent curve, so the starting slopes are gentle and gradually become steeper until they reach approximately 31 degrees, at which time you’re looking at a vertical wall. You could use the same short formula anywhere in the game to determine the height of the ground, therefore it is reused. The terrain calculation itself is 29 bytes long. You measure distance in 9 pixel steps because it is the same as the wheel radius, therefore there is no need to maintain any additional constants.

When you press the right arrow key, the code nudges the wheels slightly along the slope of the ground underneath them if they are contacting the ground. If the car is in the air, the same button will tip the nose up and the left arrow will tip it back down, same like in the original game. Then there’s a 76-byte function that simply lifts any wheel that has fallen below the estimated ground line.

Drawing is done column by column, one vertical column at a time. The code determines where the far hill and the near ground begin, paints a little of sky above each of them, and then displays a lighter band to represent the distant hills, which are scrolling at half speed. Then it adds six pixels of grass and the remainder is dirt, with a darker line every sixteen pixels. That particular portion of code takes up 115 bytes. Cars, coins, and fuel cans, on the other hand, are represented as short lists of five-byte forms. There is one shared procedure, which is the longest single block of code at 169 bytes, and it handles rotating any of those lists and dumping them into the column. A crash is identified when the driver’s hair color begins to encroach on the grass color, which happens to be in the same low range on the palette, making that specific test nearly free.

>

Fuel begins at a level that lasts around twenty-one seconds before dropping with each tick of the timer. Red cans, on the other hand, reset the counter and begin appearing at ever-wider intervals. Coins, on the other hand, simply sit there in short rows on the ground. Numbers on the screen are generated by a single floating point instruction, which takes the binary sum and converts it to decimal digits at the conclusion. The original program began with just 1340 bytes. Through frequent reuse of existing constants, some tidying up to remove redundant computations, and two modest bug fixes, it was whittled down to the very limit, with only one unused byte remaining in the initial sector.

You can boot up the finished image in an emulator and simply drive until the fuel runs out or the driver lands on his head. The hills keep growing steeper and steeper, the cans get farther and further apart, and the car continues to flip and bounce around exactly as the physics rules suggest. For anyone interested in seeing how little a program may be, the source code for both the 512-byte prototype and the full 1,024-byte version is available on GitHub under the name “hill-climb-1024”.