TRX, one decompiled engine standing in for three classic Tomb Raiders

Decompilation, and one engine for three rule sets

TRX is described as an open source reimplementation of Tomb Raider 1, 2 and 3, and the README explains the method in one line: it aims to enhance the classic games through decompilation and the implementation of open-source alternatives to proprietary components.

Those two halves of the method have very different characters. Decompilation is a research activity. You take a shipped binary, work out what the original source did, and rewrite it as source you can read, and the value is that the resulting code is inspectable, modifiable and legally independent of the original implementation. Writing open source alternatives to the proprietary components is an engineering activity: the original games shipped with parts that were not open, and those parts have to be reimplemented from scratch.

The structural decision is in the next sentence, and it is the one that makes the project more than a patch. TRX is a single engine capable of running TR1, TR2 and TR3 and custom levels, while respecting the distinct mechanics of each of the classic engines.

That is a hard thing to do, because the three games do not feel the same. They have different movement rules, different enemy behaviour, different inventory semantics and different level formats, and a fan project could have shipped three separate reimplementations. One engine with three sets of rules means a fix to the renderer or the sound system or the input layer lands in all three games at once, and a new feature can be enabled per game where it makes sense. The cost is that the engine has to carry the differences explicitly, and every shared subsystem has to be written so that a TR1 mechanic can coexist with a TR3 one.

The default branch is develop, and the site at lostartefacts.dev hosts the project documentation.

The showcase is really a list of engine-level work

The README presents the project with a gallery of screenshots, and reading the captions is more informative than it first appears.

There is a restored braid in TR1, which is a specific piece of game logic rather than a visual change. There is an enemy health bar and UI scaling, which is a user interface that was not in the original games at all. There is a photo mode, which is a screenshot system with camera control. There are 3D pickups, meaning that items the original rendered as flat sprites can be shown as volumetric objects. There is skybox support, so the world has a sky rather than a flat background. There is an updated moveset including sprint. There is a customisable draw distance. There is a developer console. There are detailed level stats, in the style of a compass and a statistics readout. And there is a PS1 user interface with expanded options, which is the opposite of a visual update and is instead a deliberate presentation of the original hardware's look.

Put together, those captions describe an engine that has been taken apart and put back together with modern conveniences added at the engine level rather than patched on. A health bar and a developer console are features of a runtime, not of a level file, and the fact that they are there tells you how much of the original implementation was replaced rather than emulated.

The PS1 user interface entry is the interesting counterpoint, because it shows the project is not simply chasing modernity. A fan project that rendered the games in 2026 quality would be easy; a project that offers the period look alongside a photo mode is making a choice about what the reimplementation is for.

The renderer work is the slow part, and the README says so about the visual side: TRX is constantly getting new rendering improvements and texture fixes, and great stuff takes time.

The Q&A is where the honest answers are

The README has a question and answer section, and it is the most useful part of the document for anyone deciding whether to try the project.

On completeness, the answer is a yes. All three games are fully playable from beginning to end, and the answer adds that if you encounter a bug, you should file a ticket. That is a strong claim, and for a fan reimplementation of three platform games it is the one that matters most, because the alternative is a project that runs the first level well and then falls apart.

On HD textures, the answer is a no, and notably it is a no with a reason attached: regarding HD texture packs, that feature is not currently planned. The distinction is important because the answer is not a general refusal of visual work. Other visual updates are actively happening, with reflections and skyboxes cited as examples of what the project has already introduced, and the phrasing is that the sky is the limit on what can be added. So the omission is about asset production, which needs somebody to redraw every texture in the game, rather than about the engine's ability to display them.

On Tomb Raider 4, the answer is the frankest of the set. The work is well underway, still early, but moving fast, with progress tracked through the changelog and the release showcases on the team's YouTube channel. And there is a policy attached: tickets for problems specific to TR4 raised before the game is fully supported will most likely be closed.

That last sentence is good practice stated plainly. A reimplementation that invites bug reports for a half-finished game accumulates a queue of reports it cannot act on, and saying so up front is kinder to the reporters and to the maintainers.

Controllers, bindings and the input layer

The question about playing on other platforms gets the short answer that currently supported platforms include Windows, Linux and macOS, and the question about controllers gets a longer one.

TRX supports a wide variety of controllers out of the box with no additional software required. The keyboard or controller controls can be fully customised in the Controls menu with multiple layouts. Multi-key combo shortcuts, up to three keys, are supported, and there are two binding slots per action.

The last two details are what separate a controller that works from one that works well. A single binding per action means a player with a modern controller and a player with a retro-style pad have to fight each other over the same buttons, and a remapping menu that lets you keep two configurations per action solves exactly that, because the player can switch between a layout for one game and a layout for another without reconfiguring anything. Three-key combos are what you need for the actions the original games bound to a key plus a modifier, and the original games' control schemes were fixed, so the binding layer has to be more flexible than the originals.

All of that is input-layer work, which is the same category as the health bar and the developer console. A reimplementation that stops at rendering the original screens would need a gamepad driver per platform and per model, and the claim of no additional software required is a statement about how much of the platform the project has absorbed into itself.

Container builds, host user ids and a ccache cache

The repository ships a justfile, and it is the clearest available description of how the project is built and tested, because it shows the whole flow rather than a single command.

The recipes are Docker-based. There are three image targets, image-win, image-linux and image-win-installer, each pointing at a Dockerfile under tools/shared/docker, and the default recipe builds the Windows debug binary. The images are named rrdash/trx-win, rrdash/trx-linux and rrdash/trx-installer, and the version suffix is a dated development string, 20260809.dev1, which is a sensible choice for a snapshot image that changes constantly.

The build recipe has a three-step fallback that is worth copying. It checks whether the image already exists locally, and if it does, stops. If it does not, it tries to pull the image from Docker Hub, and if that succeeds, stops. Only if both fail does it build the image from the Dockerfile. For a development container that is rebuilt on every change, that ordering means a developer who only changed code pulls the cached build rather than paying for a full compile, and a developer whose image is missing gets it from the registry before paying for a build at all.

The run recipe is where the details are. The container runs with --rm, and with --user set to the host's uid and gid, which the justfile captures at the top with id -u and id -g, so the files a build writes into the mounted working directory belong to the developer rather than to root. The current directory is mounted at /app, and four environment variables are passed through for the compiler cache, CCACHE_DIR, CCACHE_BASEDIR, CCACHE_COMPILERCHECK and CCACHE_MAXSIZE, so that the cached objects are written to a location the host can keep.

The combination of a host user id and a shared compiler cache is what makes this style of containerised build pleasant rather than annoying, and it is the kind of detail that tells you the people maintaining it build every day.

Releases, branches and the shape of the repository

The repository layout is a modern C project with the usual supporting material: a src/ directory for the code, data/ for the game's data files, docs/ for the documentation including the installation guide and the changelog, tools/ for the build and Docker tooling, a justfile as the task runner, a .clang-format for the formatting rules, a .pre-commit-config.yaml for the commit hooks, a .emmyrc.json for editor configuration, a .gitmodules file for the submodules, a BUG_REPORTING.md, a CODE_OF_CONDUCT.md and the COPYING.md carrying the GPL-3.0 text.

The release naming has two schemes, and the difference matters when you are pinning. There are the versioned tags, trx-1.11 published on 2026-09-19 and trx-1.11.1 on 2026-09-22, and there is a tag called latest whose description is Development snapshot, last published on 2024-03-26. A consumer who follows the latest tag gets a snapshot from 2024, and a consumer who follows the version tags gets a real release from September 2026. The README's download link points at the release list filtered to exclude prereleases, which is the correct thing to point at, and the installation instructions and the changelog are both documents inside the repository rather than pages on a website.

The credits section is short and specific. Endless GitHub contributors, the TR1 title screen image by Kidd Bowyer, HD assets by goblan and posix, and the TR2 HD images by Arsunt. The team describes itself as a small, passionate community of developers and creators with a deep love for the classic Tomb Raider titles, building and maintaining freeware fan projects, and the site hosts the TRX documentation as well as other Tomb Raider projects.

That last point is worth noting. TRX is one project in a family, and the same team maintains other fan projects, which is why the engine is built to be a general-purpose base for the series rather than a one-off.

Where TRX is the wrong tool

The first limit is assets. The project replaces the proprietary components of the original games with open source ones, which is what a reimplementation can do and what it cannot do is ship the original game data, since that content belongs to the rights holder. The practical consequence is that TRX is an engine, not a game, and the installation document linked from the README is where the required files are described. A reader who expects a download-and-play package with everything in it will be disappointed, and a reader who wants to know whether the original assets are covered should read that document rather than assume.

The second is scope. Three games are fully playable, Tomb Raider 4 is early, and HD texture packs are not planned. Those are three separate limits on the fantasy of a perfect restoration, and the project states all three plainly, which is more information than most fan projects give.

The third is the platform set. Windows, Linux and macOS are supported, so a player on any other system, or on a console, is out of luck, and the question about Android in the README is answered in the negative by omission.

The fourth is the effort. Decompilation is slow, and the README's own framing of the visual side, that great stuff takes time, is an accurate warning. A project maintained by a small passionate community has a different risk profile from a commercial one, and the TR4 tickets policy is a reminder that capacity is finite and is allocated deliberately.

The fifth is the legal frame, which is worth stating once and plainly. This is a fan project distributing open source code under the GPL, and the games it runs remain the property of their rights holder. Whether a given use is permitted is a question for that rights holder, and the project is explicit that it is unaffiliated in spirit with the commercial product even if the README does not spell that out in legal language.

Editorial conclusion

TRX fits a player or a modder who wants the original games running with modern rendering, working controllers, a developer console and a single engine that spans three games, and it fits a reverse engineer who wants to read a decompiled codebase of that era. It does not fit a player who expects HD texture packs, which the project says are not currently planned, and it does not fit anyone who wants Tomb Raider 4 today, since that work is early and problem reports about it will mostly be closed. Before adopting it, read docs/trx/INSTALLING.md, because the engine replaces the proprietary components rather than shipping the original game data, and check the changelog rather than the tags, since the release naming includes a development snapshot tag that has not moved since 2024. The licence is GPL-3.0, version 1.11.1 was published on 2026-09-22, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. LostArtefacts/TRX on GitHub
3. Project website
4. README
5. Releases