# hells-gate-recomp: a static recompilation port of Dante's Inferno for PC

> The repository ports the Xbox 360 release of Dante's Inferno to native Windows and Linux builds using the ReXGlue SDK. The game is reported playable, but the build path is long, the releases are betas, and you supply the game files.

**florinp93/hells-gate-recomp** — Xbox 360 to PC port of Dante's Inferno using ReXGlue (static recompilation)

- Repository: https://github.com/florinp93/hells-gate-recomp
- Stars: 375 · Forks: 15
- Language: C++
- License: not declared
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/florinp93-hells-gate-recomp

## What hells-gate-recomp actually is, and who it is built for

The repository is a static recompilation port of Dante's Inferno from Xbox 360 to native PC. The README describes it as a port built with the ReXGlue SDK, which converts Xbox 360 PowerPC XEX executables into portable C++ that runs natively on Windows through D3D12 and on Linux through Vulkan. The stated design goal is no emulation and no JIT at runtime, which is the opposite of how an emulator such as Xenia works: an emulator interprets or translates console instructions while the game runs, while a static recompiler translates the executable ahead of time into C++ that is compiled like any other program.

The audience is narrow. You need an Xbox 360 copy of the game to produce the XEX the toolchain consumes, and the README's Linux instructions assume familiarity with CMake, Ninja, Clang, and shell scripting. The progress tracker reports the game boots, runs, and is fully playable, with graphics and input configured, so the project is past the proof-of-concept stage. That said, the newest releases are tagged v0.6.6-beta, v0.6.5-beta, and v0.6.4-beta, so the shipped artifacts are still labelled beta.

One detail worth noticing is the AI usage disclosure near the top of the README. The project states that AI tools assisted with documentation drafts, API research, and routine Git workflow tasks, and that architectural decisions, problem solving, code implementation, and final reviews were human-driven. That kind of disclosure is still uncommon in port projects, and it tells you where to aim your scrutiny: the prose may be tidier than the code, so read src/, patches/, and scripts/ rather than trusting the summary.

## How static recompilation works in this repository

The data flow visible in the README runs in one direction. You place the game executable at game/default.xex. The rexglue CLI, built from thirdparty/rexglue-sdk, reads that XEX and generates a project skeleton plus recompiled C++ sources. A codegen target named dantes_inferno_codegen produces those sources, and a Python script at patches/generated/apply_generated_patches.py applies project-specific fixes to them. Only then does the dantes_inferno CMake target compile the final executable.

The manifest file dantes_inferno_manifest.toml sits in the middle of this flow. The Linux instructions tell you to back it up before the dependency installer runs, restore it before codegen, and restore it again before the final build. That is a strong signal: the setup and codegen steps rewrite the manifest, and the project needs the original contents when it compiles the game. If you skip a restore, you are building against a manifest the scripts replaced, and the README does not describe what breaks in that case.

The progress tracker lists the concrete engineering that made the port work: VMX/AltiVec PowerPC instruction support, a fix for VP6/Bink FMV corruption, and a save system fix involving fiber/setjmp/longjmp plus an XUserFindUsers handler. Those are the kinds of problems a static recompiler has to solve per game, and their presence in the tracker is more informative than any general claim about compatibility.

## Building hells-gate-recomp on Ubuntu with Clang 22

The README documents a nine-step Linux build. It is explicit that the commands use Clang 22 and the same ReXGlue workflow as the Windows build, with an extra Linux GPU plugin and a generated-code patch step. Start by backing up the manifest and running the provided dependency installer, which the README says installs the compiler toolchain and the development libraries ReXGlue needs on Ubuntu:

```bash
cp dantes_inferno_manifest.toml dantes_inferno_manifest.toml.back
chmod +x ./scripts/install_dantes_min.sh
./scripts/install_dantes_min.sh
```

Next, run the project setup script through PowerShell, then configure and build the ReXGlue CLI with CMake and Ninja:

```bash
pwsh ./setup.ps1

cmake -B out/build/linux-release \
  -G Ninja \
  -DCMAKE_C_COMPILER=/usr/bin/clang-22 \
  -DCMAKE_CXX_COMPILER=/usr/bin/clang++-22 \
  -DCMAKE_CXX_FLAGS="-stdlib=libstdc++ -I$(pwd)/thirdparty/rexglue-sdk/thirdparty/imgui -mssse3 -mavx2" \
  -DREXSDK_DIR=thirdparty/rexglue-sdk

cmake --build out/build/linux-release --target rexglue
```

After that, build the Xenos GPU plugin and copy the resulting shared libraries into the build directory. The README notes that game/default.xex must be present before the next command, which initialises the SDK-managed project files:

```bash
cmake --build out/build/linux-release --target rexgpu-xenos

cp thirdparty/rexglue-sdk/out/linux-amd64/lib*.so \
  ./out/build/linux-release/

thirdparty/rexglue-sdk/out/linux-amd64/rexglue init \
  --force \
  --project-name dantes_inferno \
  --project-root . \
  --xex-path game/default.xex \
  --game-root game
```

The remaining steps reconfigure the project, restore the manifest backup, build the dantes_inferno_codegen target, run the patch script, restore the manifest again, and build the dantes_inferno target. The README gives the resulting Linux executable as out/build/linux-release/dantes_inferno. To run it from the repository root, use the provided script:

```bash
./scripts/dantes_inferno_exe.sh
```

That script is documented as setting LD_LIBRARY_PATH to include thirdparty/rexglue-sdk/out/linux-amd64 before launching the binary. If the executable starts and the game reaches its menus, the toolchain worked end to end.

## Where hells-gate-recomp falls short

The first limitation is legal and practical rather than technical: the port needs game/default.xex, and the repository does not ship the game. You have to produce that file from your own copy of the Xbox 360 release. Without it, the rexglue init step has nothing to consume, and the whole build stops.

The second is that the project is mid-flight. The README's in-progress list includes a DLC auto-install hook that scans STFS packages in OnPostSetup, timing polish for 120 Hz and high-refresh displays, and a migration to a native DiligentCore/Vulkan renderer that is described as working but not fully implemented. The roadmap marks the native renderer migration as in progress and not final, and button glyph replacement as planned. High-refresh timing is the most user-visible of these: the tracker says gameplay is fine, but menu and minigame timing are still under reverse engineering. If you play at 120 Hz and care about menu behaviour, expect rough edges.

The third is the build itself. Nine documented steps, three separate CMake reconfigurations, a manifest that must be backed up and restored twice, and a Python patch script that must run between codegen and the final build. There is no documented one-command build, and the README does not describe rollback if a step fails halfway. A failed build leaves you with a modified manifest, a half-generated source tree, and no stated recovery path beyond restoring the backup by hand.

## How this differs from emulating the game instead

The obvious alternative is an Xbox 360 emulator, and the difference is architectural rather than cosmetic. An emulator loads the original XEX and translates or interprets PowerPC instructions as the game runs, which means compatibility work happens at runtime and the emulator carries the overhead of that translation. ReXGlue, as used here, converts the XEX into C++ ahead of time; the generated sources are then compiled by Clang into a native binary. The README states the result runs without emulation or a JIT at runtime.

That trade has consequences. A native binary can call host graphics APIs directly, which is why the README can talk about resolution scaling, anisotropic override, aspect-ratio control across 4:3, 16:9, 16:10, 21:9 and 32:9, and post-effect cvars. Emulators reach similar settings through their own configuration layers. On the other side, a static recompilation is per game. Every title needs its own codegen pass and its own patches, and this repository exists because someone did that work for Dante's Inferno specifically. An emulator covers a library; this covers one game, and the patches under patches/generated/ are the price of that focus.

## Maintenance, releases and licensing questions

The repository is not archived, and the last push was on 2026-09-16, the same day as the v0.6.6-beta release. Three beta releases landed within roughly two days, which indicates a fast iteration cadence rather than a settled product. The version string in the README's progress tracker refers to ReXGlue SDK v0.10.0 for codegen and the native build, so the port tracks an upstream SDK; a change in that SDK is a change in this project's build inputs.

Upgrade cost is therefore not just pulling a new tag. The build consumes thirdparty/rexglue-sdk, and the codegen target regenerates sources that the patch script then modifies. If upstream codegen output shifts, patches/generated/apply_generated_patches.py may need updating, and the README does not document how patches are authored or versioned against SDK releases. Budget time for that whenever the SDK moves.

On licensing, the README does not state a licence for this repository. The top-level entries include .github/, docs/, and thirdparty/, but no licence file is named among them. The README also credits fan artwork to POOTERMAN via a DeviantArt link and issue #12, so at least one asset in assets/ has a separate provenance. Treat the licence status as unresolved and check the repository and its third-party directories directly before redistributing binaries or assets.

## Conclusion

This repository is for developers and technically confident players who already own an Xbox 360 copy of Dante's Inferno, can supply game/default.xex, and are willing to run a Clang 22 plus CMake plus Ninja toolchain through the documented Linux sequence. It is not for anyone who wants a double-click install, and it is not a substitute for the console release. Before committing time, verify that game/default.xex is present, that Clang 22 is available at the paths the README uses, and that the bundled rexglue-sdk version matches what the project expects. The README does not state a licence for this repository, so check the licence files under .github/, docs/ and thirdparty/rexglue-sdk before redistributing anything.

## FAQ

### What is hells-gate-recomp?

It is a static recompilation port of Dante's Inferno from Xbox 360 to native PC, built with the ReXGlue SDK. According to the README, ReXGlue converts Xbox 360 PowerPC XEX executables into portable C++ that runs natively on Windows through D3D12 and on Linux through Vulkan.

### Why do they call it Hell's Gate?

The repository name hells-gate-recomp is not explained in the README, which refers to the project as a Dante's Inferno Xbox 360 to PC port. The README gives no stated reason for the Hell's Gate wording, so the naming intent cannot be confirmed from the documentation.

### How much is hells-gate-recomp?

The README does not state a price for the port. It links to a Ko-fi page for donations and to a Discord server, but no paid tier or licence fee is documented. The repository also does not ship the game files, so you need your own copy of Dante's Inferno for Xbox 360 to produce game/default.xex.

### What is the legend of Hell's Gate?

The README does not discuss any legend or folklore behind the name. It describes the project as a static recompilation port of Dante's Inferno built with the ReXGlue SDK, and the progress tracker covers technical work such as VMX/AltiVec instruction support and a save system fix.

## Sources

- [florinp93/hells-gate-recomp on GitHub](https://github.com/florinp93/hells-gate-recomp)
- [Issues](https://github.com/florinp93/hells-gate-recomp/issues)
- [README](https://github.com/florinp93/hells-gate-recomp/blob/main/README.md)
- [Releases](https://github.com/florinp93/hells-gate-recomp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/florinp93-hells-gate-recomp