把一款 Xbox 360 的 Kinect 遊戲翻成原生程式：製作流程Turning an Xbox 360 Kinect game into a native program, step by step

An emulator (Xenia, for the Xbox 360) is like a live interpreter: each time the game runs a machine instruction, the emulator reads it and carries it out, one after another.

A recompilation is like translating the whole book in advance: before you play, the game's machine code (the Xbox 360 runs PowerPC instructions) is translated into C++, which your computer's own compiler turns into an ordinary program. While you play, nothing has to be read and understood again.

But a game is more than code. It calls on the console's system (to start threads, read files, get memory), asks the graphics chip to draw, and reads the body the Kinect sees. None of that can be translated; it needs a separate layer that plays the part of the Xbox 360. So this project is two halves: the translated game code, and a runtime that stands in for the console.

The translators are existing open-source projects: XenonRecomp for the CPU code and XenosRecomp for the shaders (the small programs that run on the graphics card). They were made for projects like Sonic Unleashed Recompiled.

A project like this can be public only if it ships nothing from the game itself. That decides how every tool is designed, so settle it on day one.

• Players use their own disc: the launcher reads the player's own disc image (ISO) and installs the game's data on their machine. It first checks that the disc's default.xex is the supported version (only the USA/Europe disc for now), and won't install anything else.
• The translated C++ stays local: disc images, game files and the code generated from the game are all in .gitignore. They never go into git or any cloud service.
• CI (the automatic tests on GitHub) never has the game, so it tests only what doesn't need it. Builds and tests that need the game run on the developer's own machine.
• Releases follow the Unleashed Recompiled model: the developer builds the program from their own disc and publishes it; not one byte of the game's data (pictures, sound, movies) goes with it.

An Xbox 360 disc has its own file system (XDVDFS). Taken apart, this disc's game partition holds 685 files. Most are pictures, sound and movies; the actual program is a single file, default.xex.

XEX is an encrypted, compressed program file. default.xex is 14,241,792 bytes, and the decoded program image is 34,209,792 bytes. It lists the 299 system functions the game borrows from the console (like "start a thread" or "read a file") and 13 system variables. That list is the job description for step 04, playing the console.

XenonRecomp turns each function in the program image into a piece of C++. The output isn't usable in one go: after the first run, 14,475 functions were marked "can't translate, disabled". The work that follows is finding out why, one cause at a time, and bringing that number down.

The rule here differs from an emulator's: never guess at what you don't recognise. A function that can't be translated becomes a named stop; when the game reaches it, it stops and says which function. Mistakes show up at once, instead of as a strange picture nobody can explain.

As soon as the translated game runs, it asks the "console" for things: memory, threads, events to wait on, files, the time, the system language, whether a Kinect is there. Our runtime has to answer all of it, and answer the way a real Xbox 360 would.

The method is plain: run until it stops, fill in what it stopped on. docs/progress.md, from 2026-09-10 on, is a long chain of "it now stops at this function, this was added, next it stops here". For example, the game asks twice whether a Kinect is connected; the runtime says no, and the game's own code handles that. It asks for the country; the runtime reads Windows' setting and turns it into the console's code.

On the console the game spreads many threads across three CPU cores. On a computer each becomes a real thread. For them to run safely at the same time, events, semaphores and critical sections (sections only one thread may be in at once) have to behave exactly as the console's do.

The Xbox 360's graphics chip is called Xenos. To draw, the game hands it commands and shaders. On a computer those become Direct3D 12 or Vulkan (the drawing interfaces of PCs and phones), and the shaders have to be translated first.

In races the game uses 1,182 shaders. At first 735 couldn't be translated, because this game does two things the translator didn't expect (vertex data for skeletal animation, and loop counts set only when drawing). With a step added before and after translation, 3 were left.

The shader translator only runs on Windows, so Linux and phones use shaders translated ahead of time on Windows and packed into shaders.pack. And because a graphics card has to compile each way of drawing the first time it meets it, which causes a hitch, the game prepares the known combinations (455 graphics pipelines) after you press Play, so races don't stall on it.

This is where this game differs most from other ports: it has no controller controls. Menus use a hand cursor and voice commands; races use your whole body: lean forward to speed up, crouch and stand to jump, kick back with one foot to dash.

On the console a Kinect reports "the player's skeleton" through a library called NUI: 20 joint positions per person. The game has about 25 gesture detectors of its own (jump, crouch, kick, lean…) that read that skeleton. So the simplest way, and the least likely to break the game, is to pretend there's a skeleton at the NUI layer, driven by a controller:

• Menus: the stick moves the cursor as a hand; buttons stand for voice commands the game already understands (START, A = ok, B = back).
• Races: hold A to crouch and charge, release to jump; X to kick dash; the left stick to lean, and to spin for tricks in the air; B to grab rails.

Since the game only cares where the skeleton comes from, a real body just replaces that one box from the last step:

• Webcam (v0.2.0): an ordinary webcam has no depth, so MediaPipe's pose model estimates the body's 3D pose from the picture. It can't measure how far you are from the camera, but it's enough for the game to read leaning, crouching and jumping.
• Kinect for Xbox 360 (v0.4.0): Microsoft's Kinect SDK 1.8 for Windows is the same NUI library brought to the PC: 20 joints, the same coordinates. So the body the sensor sees goes to the game almost untouched, and races go back to the game's own detectors reading the real body and depth image. Much of this was built by collaborator KnucklesLee.
• Kinect v2 (the Xbox One one): it reports 25 joints, which are turned into the first Kinect's 20 that the game knows. Nobody on the project has a Kinect v2; the work relies on logs one player attached, so it's still experimental and the reports about it are open (issue #165).
• Mac (in development, merged 2026-10-30): the Mac has no Microsoft Kinect runtime. The open-source libfreenect gives only the colour and depth pictures, so the skeleton is made here: the pose model finds the joints in the colour picture, and depth places them in metres. To be plain: this hasn't been tried with a real Kinect yet. What has been checked is that without one it falls back to the controller and races at full speed (1.000).

By v0.4.x the game was playable, but only about 24 fps on a phone. Early on the runtime had been built cautiously, for safety and easy debugging: every memory access was checked, all threads took turns holding a single "permit" to run, and everything was drawn on one 720p canvas.

On 2026-10-04 the project was compared, item by item, with two mature recompilations (Unleashed and Marathon), and the differences were moved over in five stages. Each stage was measured on the same phone with the same package, switching the change on and off in turn (A/B/A/B), and only went ahead once it was faster and the picture was right:

A bonus: once each surface had its own target, race shadows appeared for the first time. Before, the shadow map read stale bytes from memory.

A port earns its keep with things the original can't do. Over time this one added:

• Two players: each controller is a Kinect player of its own (v0.1.5; v0.6.1 made Relay Race work with controllers too).
• Online races: the original Xbox LIVE service closed long ago. From v0.7.0 the game connects to this project's own server instead, and Windows, Linux and Android players race together; one player's game can host the server itself.
• Mods: file-replacement mods in HedgeModManager's format (the one Unleashed and Marathon use), switched on and ordered in the launcher. The Traditional Chinese translation is such a mod.
• Your own VRM model: the in-game AVATAR rider can be your own 3D model, still animated by the game.
• Achievements (no Xbox Live needed), adjustable internal resolution, ultrawide, touch controls and tilt steering.

The rule: don't quietly change how the game itself behaves. When a phone can't reach 60 fps, for example, the race doesn't take bigger steps (that would change the physics); it keeps its fixed step and leaves some frames undrawn to keep up with real time (step 11).

The output is C++, so each platform builds it with its own compiler. Each still has its own traps, and a platform only counts once it has really run there:

The first whole Free Race on a PC (2026-09-21) ran at 1.6 fps, 620 milliseconds a frame. Measuring where the time went: the game's own work was 53 ms, and our drawing code took nine tenths. After fixing it piece by piece, the same day it reached about 60 fps, close to real time.

Phones were the bigger challenge. The method was the same each time: run the same stretch of a race on a real AYN Thor handheld, find the biggest cost, change it, then switch it on and off in turn (A/B/A/B) to make sure it really got faster and the picture didn't change.

One change in detail (v0.6.9): Android put the render thread, which mostly waits, on the one fastest core, while the main thread, which sets the frame rate, ran on slower ones. Moving the render thread off the fastest core took the start line from 52 to 60 fps.

Another (v0.9.0): when a phone couldn't reach 60 fps, races used to take longer steps to keep their speed. But this game's collisions are made for 1/60-second steps; with longer steps a fast racer could pass out through the side of a ramp (issue #123). Keeping the fixed step and leaving some frames undrawn to catch up got both the speed and the physics right.

This loop is a rule set by the project owner. Nobody can buy every phone, so phone problems are reproduced on Google's Firebase Test Lab (real phones in the cloud), or on a PC with that phone's limits forced on. Here is a complete real case.

1. The report (2026-10-17): a player's two phones wouldn't start the game. The Pixel 10a (Mali-G715) closed at the loading screen; the P30 Pro (Mali-G76) didn't even get that far. They attached diagnostics from both.
2. The Pixel 10a: the log showed the graphics driver crashing while compiling the first pipeline. The shaders wrote something (a clip distance) this chip itself says it doesn't support. On Firebase's Pixel 10a the old build crashed the same way; without it, all 455 pipelines compiled and frames drew correctly. Fixed in v0.10.2.
3. The P30 Pro, first layer: its Vulkan lacked two extensions the renderer required. They turned out to be unused, so they're no longer required; three more things old Mali GPUs need came after. v0.10.3.
4. The player said it still failed: preparing pipelines, the whole phone froze on the last 5. Their log showed the GPU lost on the very first draw.
5. The real cause: every draw declared 20 vertex inputs, but these Mali GPUs support 16. Now each shader declares only the inputs it reads (14 at most). On Firebase's closest old Mali (a Galaxy S9, Mali-G72), a new test draws once with each of the 455 pipelines: all correct with the fix, and a hang like the player's without it. v0.10.4, the same day.
6. The player confirmed: the P30 Pro got into the game. Later they ran a Magma Rift race on a newer build: 20 fps shown, but the race kept real time (0.998); the bottleneck is the GPU, so a lower Render size in the launcher helps most. Closed, with speed followed in issue #176.

Every release goes through this list; if any item fails, it doesn't ship (0.10.38 as the example):

The links above are pinned to commit eb16749 (main after 0.10.38, when the Mac Kinect work was merged), so they don't drift as the code changes. For the latest code: