Skip to content

The car physics, every step of a race ​

2026-10-24, the pod-physics session.

The eight cars' paths in the recorded race on Beltane, top view; rings where the port stopped following each computer car

The eight cars of the recorded Beltane race (derived/physics/beltane-3), seen from above. The rings mark where each computer car first touched another car. Up to there, the port carried each car on its own, step by step, and matched the recording. The player's car (red, which stayed apart) was followed through the whole race.

Recording every step ​

Porting physics to the bit needs the game's own state at every step, and at points inside the step. The recorder used so far reads memory from outside ten times a second, so it sees about one frame in eight. Breakpoints through ptrace looked like the answer, but under Wine they left every thread of the game stopped within a few steps. When the recorder was killed, the game crashed.

So the game records itself. A code cave of 400 bytes, patched into the VM's copy of WINPOD.EXE, writes a record at the start of each simulation step, another right after each car's controller, and another right after its physics. It runs at full speed and stays silent until a word in memory turns it on (run/vm/steplog.s; how it works). The first log already said something new: the game thread runs the FPU at 53-bit precision. Watcom's start-up code sets 64 bits, but the game runs in a second thread, which starts with the Windows default. At 53 bits every x87 operation rounds as a plain f64 does, so the port can use f64 in the same order and get the same bits.

The original, on its own states ​

One snapshot of the whole process gives the track and the tables. The step log gives everything that changes. Under Unicorn the original's physics step ran on each recorded car, and at first 40 of 140 matched. The misses showed what the log was missing: a counter that makes the chassis look for the ground every 17th call, race records that earlier cars change within the same step, and the time scale each computer car gets for catching up. With those in the log, the original reproduced every one of the race's 20,488 car steps. Then the whole simulation step, with collisions and zones, reproduced each next step.

The port ​

From there each function was read from the disassembly and ported, then checked against its own calls captured inside those runs. The drivetrain came first, then air, grip, springs, tyres, the body, wall impacts and contact with the track's faces and sectors. Every one matched on the first or second try. Then the whole step matched too, all 20,488 car steps, every word.

A few things the code does that a rewrite would not:

  • Yaw. 15/16 of all the torque about the car's up axis is taken away again each step.
  • Grip. The tyres take a quarter of the car's weight as the load for the slip curve, not the wheel's own load. At low speed they test the skid flags against a value left on the stack by an earlier wheel.
  • Wall contact. When a point touches a second wall, its push-out depth becomes the length of the sum of both pushes, but its direction stays the first wall's.
  • Catch-up. Computer cars catch up through time, not force. A car behind the one it chases gets up to 1.008 times the real step (more on harder levels), and one ahead as little as 0.90.

Next ​

Car-to-car collisions are next: a box test of each car's collision hull, an impulse, damage to the body parts, and the beacon test for the pushed cars. Then putting a car back on the track, a track world built from the disc rather than read from a snapshot, and recordings with jumps and a joystick for the branches this race did not reach. The project's reference moved to POD Gold 2.8 today. This work was measured on the first edition, so the physics will be checked again on Gold.

Prose CC0 1.0, code Apache 2.0. POD: Planet of Death is © Ubi Soft; none of its files are on this site.