RBR Next Generation

A living game on a frozen file

Twenty years on, Richard Burns Rally is still the reference for rally driving. That is the community's work: NGP physics, the RSF platform, hundreds of stages, plugins for HUD, controls, pacenotes and VR. All of it rests on one closed 32-bit executable from 2004 whose source was never published. Every plugin reaches into that file at fixed addresses, beside the official plugin SDK.

This makes the game frozen. The executable cannot be recompiled. So it cannot go 64-bit and cannot change inside: every improvement is a patch on top of patches, with the addresses as the contract. Graphics can be wrapped from outside, as the d3d9 proxies do, but the game underneath stays the 2004 code.

The rally-ng project rebuilds the executable as C++ source, function by function. Today 6,691 of 16,492 functions compile back to the original bytes; the rest stays original bytes at its place, so the whole file still relinks byte for byte. That would turn the frozen file into parts that can be changed safely: rebuild a block, prove it against the original, and only then replace it. The proofs on this page: the whole executable relinks byte for byte, a recorded run re-simulates bit-exact on the rebuilt executable's own physics, and the project's own renderer draws the live game, yes, with 3D trees. The trees are a nod to the community's running gag, not the point. The point is room for stage authors: today a stage can only hold what the 2004 renderer, collision and physics understand. A sidecar would let an author go beyond that, with real 3D models, weather zones, surface and collision data, authored in the same Blender workflow, while the stage still loads in the old game. The demo uses an existing stage only as a test bed.

The rest of the page lays out the proposal: what the executable is made of, where each plugin plugs in, the phases to RBR Next Generation, and the phase at which each plugin needs its source.

Five proposed phases, block by block, the game playable after each

Every block below is a part of RichardBurnsRally_SSE.exe. Step through the phases to see each block change from original code to rebuilt code to a new implementation. Which plugins reach into which block follows in the explorer below.

The small letters after a fact say how it is known: O observed in bytes, files or runs; I inferred from observations; D documentation or community claim, not checked here; H hypothesis. Hover a letter for the same text.

Block phases are the plan, not measured per block.

One executable, its DLLs, and the plugins

The executable loads the graphics engine as a separate DLL, takes the system DLLs from Windows and carries original Microsoft libraries linked in. Plugins come in through the official SDK door, and through needles. A needle is a call, jump, patch or write from a plugin into a fixed address of the executable. It keeps working only while the code at that address stays where it is.

Where each plugin reaches in

Pick a plugin. The card says what it does, where its source stands and from which phase it would need it. The bars count its needles per block of the executable.

“Not tied to a block yet” is not a part of the executable. It holds the needles the scan cannot yet tie to a block, because their target has no name or class yet (an unnamed function, a plain global, or a number that only looks like an address). Each name recovered in the rebuild moves needles out of it. Third-party libraries in the install (OpenSSL, FMOD, OpenXR) are left out: they cannot reference the executable, so their hits are number coincidences.

C++ that compiles back to the original bytes

Each function below was written as C++ and compiled with the original compiler, Microsoft cl.exe 13.10 from Visual Studio .NET 2003. The output is byte-identical to the 2004 executable, verified by relinking the whole image. Names are the project's reconstruction, except where the published plugin SDK gives them.

Each example is a function NGP patches today. Above the source sits what a plugin author works from now: a few instructions around the patch site, under the disassembler's name for the function. The highlighted lines are the same place in both.

The ground query NGP redirects

The best way to see what the rebuild changes for a plugin author is one concrete patch. CGround::QuerySegment is how the 2004 physics asks the world: “a line from here to there, where does it hit the ground, with which normal and which material?” NGP wants that question answered by its own collision system.

// sketch, to be designed with the NGP author
void RBR_RegisterCollisionSystem(ICollisionSystem *system);

Multiply this by NGP's 40 patch sites and 50 virtual-table slots, and the gain is clear. Every patch NGP maintains today can become a documented call, designed from what NGP already uses. With that, NGP could follow the game to newer compilers, 64 bit and new platforms.

The redirect reading of the patch is inferred from the patch map: the patch site and the instruction are observed in the bytes, the effect is not traced at run time. The registration call is a sketch, no code exists.

Where each plugin needs its source

Under this proposal, every plugin runs unchanged through phase 1, because every address it touches stays put. From the phase on its card, a block the plugin reaches into would get a new implementation. From then on the plugin could only move forward with its source. What it would get in return: a documented interface instead of patched addresses in a 2004 binary, an interface that does not break when the executable changes, and a place in the new game.

Old stages keep loading, new stages can do more

The proposal grows the stage format by sidecars: extra files next to the unchanged .lbs. A game without the sidecar sees the old stage. A game with it sees more. The first sidecar replaces the flat tree cards of a stage with real 3D trees in glTF, written either from a shipped stage or from Blender through an extension of the RBR track exporter. Yes, 3D trees, the running gag of rally game announcements. They are here for a different reason: this is more than another shader, it replaces a part of the stage itself. The aim is not to rework other people's stages. It is to free stage authors from the limits of the 2004 engine: whatever the old renderer, collision or physics cannot express, an author could put into a sidecar and decide how the stage looks and drives in the new game.

Numbers, each with its source

Labels: O observed in bytes, files or runs; I inferred from observations; D documentation or community claim, not checked here; H hypothesis. The live frame rate is the game's own pace, which the rally-ng renderer keeps up with. The throughput card is a separate off-screen measurement of the renderer alone. An unnamed read is not an unused read: a run-time trace covers only part of them.

What this project does not do