CTR-NitroFueled-PC, running a PS4 racing game natively on Windows
Crash Team Racing: Nitro-Fueled (PS4) running natively on Windows 10/11. Windows fork of SacredFire, built on bbport and shadPS4. No game files included.
At a glance
- What is it?
- CTR-NitroFueled-PC is a Windows port of SacredFire, a native Linux port of Crash Team Racing: Nitro-Fueled. The game's own x86-64 code runs on the CPU, a small runtime stands in for the PS4 system libraries, and a renderer derived from shadPS4 translates the PS4 GPU work to Vulkan. No game files are included.
- Who is it for?
- CTR-NitroFueled-PC suits a player on Windows who already owns the game and wants it running natively with modern display options such as ultrawide, upscaling and frame generation, rather than on a console. It does not suit anyone without their own copy of the game and its update, since no game files are shipped, and it does not suit a user who wants a stable release.
- Can I use it commercially?
- Yes, with conditions. GPL-2.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The three layers that make a PS4 game run on Windows
CTR-NitroFueled-PC is described as Crash Team Racing: Nitro-Fueled for PS4, the CUSA13795 v1.21 release, running natively on Windows 10 and 11. It is a Windows fork of SacredFire, the native Linux port of the game by T3CHNOLOG1C, and the lineage explains the architecture.
The port works in three layers, and understanding them explains why it can run at native speed.
The first layer is that the game's own x86-64 code runs directly on the CPU. A PS4 is an x86-64 machine, so the compiled game code is already the right architecture, and it does not need translating or emulating. What has to be replaced is the environment around it, which is the second layer: a small runtime that stands in for the PS4 system libraries, providing the interfaces the game expects to find. And the third layer is the renderer, derived from shadPS4, which translates the PS4 GPU programming interface work into Vulkan, the graphics API that runs on a modern PC.
That is the same structure shadPS4 itself uses, and it is why the fork does not need a full emulator. Emulation is what you do when the guest code is a different architecture. Here the CPU work is native, the system calls are reimplemented, and only the graphics path is translated.
What this fork adds is the Windows layer, and the README is specific about where that comes from: the loader, memory, TLS, exceptions, files and timers from Supermedo's Windows port of bbport, plus the fixes SacredFire needed on top of it. The details of that work are in `packaging/windows/README.md`.
The repository structure reflects the layering. There is `src/` for the core, `gpu/` for the graphics side, `dlss_bridge/` for the DLSS integration, `launcher/` for the Windows front end, `patches/` for the game modifications, `third_party/` for the vendored dependencies, `docs/` for the guides, and `packaging/` for the platform-specific pieces. There is also `build.sh`, `run.sh`, `run.py`, `msys2-env.sh` and a `shell.nix`, which together describe a build that runs on a Unix-like toolchain and produces a Windows binary.
What is not included, and who this is not from
The README states the boundary in bold at the top, and it is the first thing to understand about the project.
No game files are included. You need your own dump of the game and its 1.21 update. Both builds of the 1.21 update work, the one for firmware 5.05 which is the reference, and the one for 6.72 and later, which has been accepted since v0.2.1.
So what the repository contains is the port, the launcher, the patches and the documentation, and what it does not contain is the game. That is the arrangement you would expect from a porting project, and it is also the line that separates it from a distribution of copyrighted content.
The disclaimers are equally explicit. The project is not affiliated with or endorsed by Sony Interactive Entertainment, Activision or Beenox, and Crash Team Racing, Nitro-Fueled and PlayStation are trademarks of their owners, named here only to identify the game the software runs.
The licence is GPL-2.0, and the project is a fork of SacredFire, the Linux port by T3CHNOLOG1C. The recent releases show how active the project is. The recorded releases are v0.4 from 2026-10-19, v0.3 from 2026-10-13 and v0.2.1 from 2026-10-13, and the last push to the repository was on 2026-10-19. So the work is weeks old, and the version is still 0.x, which is the usual signal that the API and the packaging may still change.
The repository has a docs/ directory, and the README links individual pages such as the frame generation guide, so the depth of documentation is a good sign for a project this young.
The launcher, and the one-time preparation step
The quickest route is the portable build, and the launcher does most of the work for you.
You download `CTR-NitroFueled-PC-portable-windows.zip` from the releases page, unzip it anywhere, and open `CTR-NitroFueled-PC.exe`. In the launcher you choose your `CUSA13795` folder, which is the base game, and your `CUSA13795-patch` folder, which is the 1.21 update. Then you press Prepare the game once, and then Play.
The preparation step is worth understanding because it is unusual. It merges the base game and the update with hard links, so the merged result takes no extra disk space. That matters when the game is tens of gigabytes and the update is another large chunk, and hard-linking the overlapping files means the total on disk is close to the size of the base game plus the genuinely new data.
Python is bundled in the package, so you do not need a Python installation to run it. The one hardware requirement is a Vulkan 1.3 GPU, which is the API the renderer targets.
The launcher itself is a project in the making. Version 0.2.0 introduced it, with game setup through the hard-link merge, settings, patches, save backups and imports, optional DLC, bundled Python and the project icon. Version 0.4 redesigned it with a Controls tab that does a live controller test with rumble for players one to four, lets you remap gamepad buttons by pressing them, and has a stick dead zone setting, and moved the keyboard rebinding page there. It also added an Achievements tab holding all 48 trophies with picture, name, what it was for, progress and dates, and the achievements are kept once earned with a launcher-style notice in the game itself.
The release history shows how the packaging evolved: v0.1.1 was the first portable build, with an FPS limit up to 240, a fullscreen switch and the licences in the package, and v0.2.0 introduced the launcher.
The DLC handling is worth a note. The game content you add comes from your own packages, and the DLC is optional. That is the same principle as the game files themselves: nothing is bundled, and the tool arranges what you supply.
The display options, and which of them are experimental
The bulk of the recent work has been in the display path, and the release notes are detailed enough to tell you which options are finished and which are not.
Internal resolution is the size the game draws its 3D scene at, from 480p to native 4K, and it replaces the PS4 Pro switch. The reasoning is given: 480p and 720p suit modest PCs, and 1440p to 2160p output a 4K picture which also smooths edges on a 1080p screen. It needs a restart, because the in-game menu does the change, and it is capped at 1440p while ultrawide is on.
Aspect ratio, added in v0.4, is a single choice among 16:9 with 1280x720 up to 3840x2160, 21:9 UltraWide at 2560x1080 or 3440x1440, and 32:9 Super UltraWide at 5120x1440, with a centered HUD. Upscaling is off while ultrawide is on, and the first launch prepares about nine gigabytes of patched archives with the originals kept.
Upscaling is a single choice at a time, switched live. AMD FSR 1 is the default and is described as a sharper spatial enlargement than the game's own stretch. AMD FSR 3 works on any GPU, AMD FSR 4 is experimental and uses the v07 INT8 model with the INT8 dot product support checked at startup, and NVIDIA DLSS is temporal upscaling that rebuilds detail over several frames from the game's depth and motion, and also works as anti-aliasing at the same resolution. The DLSS options are the quality mode, where Auto follows the internal resolution and the others render at NVIDIA's share of the output, and the model, where Transformer is recommended over the lighter CNN. The note about turning them off if you see trails is the kind of practical advice that comes from testing.
Frame generation came in v0.4 and is experimental. It uses AMD FSR 3.1.6 interpolation to show a generated frame halfway between each pair of game frames, roughly doubling the images on screen without changing the game, its FPS limit or its timing. The advice is specific: it is best on a 120 Hz or faster screen with the game running at half the refresh rate, and fast HUD elements may shimmer.
Other v0.4 additions include the game's 2x MSAA as a setting, off by default because it fixes dotted sky lines, the European edition CUSA14876, game languages per edition, an in-game menu restyled into tabs in Spanish or English, a check for CPUs without MOVBE, BMI1 or LZCNT, reporting for damaged dumps, and a fix for FSR 3 no longer turning itself off without Resizable BAR.
What the status line actually claims
The README has a status paragraph, and its detail is what makes it useful rather than a marketing claim.
The status on Windows is playable. The list is: menus, Adventure and Arcade, races, sound, cutscenes, Xbox and SDL controllers and the keyboard, saving, the community patches including 60 FPS and no motion blur, restart from the in-game menu, and the game's DLC from your own packages as optional.
The performance figures come with the hardware they were measured on, which is the right way to do it. The testing machine is Windows 11 24H2 with an NVIDIA RTX 3070 and an Intel i5-9500, and the result is 110 to 130 FPS uncapped in races with the 60 FPS patch. The FPS limit keeps it at 60 by default, and can be raised up to 240.
Two details in that paragraph matter more than the number. Shaders seen for the first time cause short stalls, and they are cached and load at start from the next session on, or compile in the background with the experimental switch. That is the standard shader compilation behaviour of a Vulkan title and it is a real first-session cost. And the fact that the reference machine is a 3070 with a 9500 tells you the target is a mid-range desktop rather than a high-end one, which is the more useful signal for anyone deciding whether to try this.
The frame rate is uncapped, so the number reflects what the hardware can do rather than what the game asks for, and with the 60 FPS community patch applied on top. That patch is one of the community modifications, alongside no motion blur.
The v0.3 release brought internal resolution scaling, a single unified upscaling list, the languages of the build, support for PS4 PKG Tool dumps, and a fix for the fullscreen switch in the game. The v0.2.1 release accepted the 1.21 update built for firmware 6.72 and later, with patches found by signature, and added the keyboard rebinding page to the launcher.
How this compares to the alternatives
There are three other ways to play this game on a PC, and the differences are about how the game is executed.
A real console is the baseline. A PS4 or a later PlayStation running the game natively is the reference, and it is the only option with zero risk of a port bug. Everything else is an approximation of that.
Running the game on a PlayStation 5 through a compatibility layer is the closest of the alternatives, and it is the most complete, because the hardware is a descendant of the target and the games are patched to run there. The cost is that it needs the console, and that the presentation is the console's.
Running the game on a PC through a full emulator is the other well-trodden path. An emulator interprets the guest code rather than running it natively, which is a much heavier proposition, and the result is a port that is technically a translation of the original rather than an execution of it.
CTR-NitroFueled-PC is the third approach, and the one that is unusual: the guest code is native, only the system environment and the graphics path are reimplemented. That is why the frame rates are high and the frame generation and upscaling options can be modern, because from the renderer's point of view this is an ordinary Vulkan application after the first few frames.
The trade is the one you would expect. A native port has to keep working as the game and the system interfaces change, and it has to be maintained by hand for a game that is not being updated. The version history shows that work happening weekly, with the compatibility of both update builds handled explicitly and damaged dumps being reported as a feature.
There is also the project that this one derives from, SacredFire for Linux, and the same arguments apply there. For a Linux user, that is the port to look at, and the Windows fork exists because the author wanted the same result on the platform most people have.
Editorial conclusion
CTR-NitroFueled-PC suits a player on Windows who already owns the game and wants it running natively with modern display options such as ultrawide, upscaling and frame generation, rather than on a console. It does not suit anyone without their own copy of the game and its update, since no game files are shipped, and it does not suit a user who wants a stable release. Verify first that your dump and update are the 1.21 versions the project targets, that your GPU supports Vulkan 1.3, and that your machine meets the settings you want, since the frame generation and FSR 4 paths are marked experimental in the release notes.
Frequently asked questions
What is CTR-NitroFueled-PC?
It is a Windows fork of SacredFire, the native Linux port of Crash Team Racing: Nitro-Fueled. The game's own x86-64 code runs directly on the CPU, a small runtime replaces the PS4 system libraries, and a renderer derived from shadPS4 translates the PS4 GPU work to Vulkan.
Does CTR-NitroFueled-PC include the game files?
No. The README states that no game files are included and that you need your own dump of the game and its 1.21 update, with both the firmware 5.05 and the 6.72 or later builds of that update accepted. The project is not affiliated with Sony Interactive Entertainment, Activision or Beenox.
How do I set up the game on Windows?
Download the portable windows zip from the releases, unzip it, and open the launcher executable. Choose your CUSA13795 base game folder and your CUSA13795-patch update folder, press Prepare the game once, which merges them with hard links and takes no extra disk space, and then press Play. Python is bundled and you need a Vulkan 1.3 GPU.
Which display options does CTR-NitroFueled-PC support?
Internal resolution from 480p to native 4K, aspect ratios of 16:9, 21:9 UltraWide and 32:9 Super UltraWide with a centered HUD, upscaling through AMD FSR 1, AMD FSR 3, AMD FSR 4 or NVIDIA DLSS, and AMD FSR 3.1.6 frame generation. The FSR 4 and frame generation paths are marked experimental in the release notes.
What licence is CTR-NitroFueled-PC under?
GPL-2.0, with the LICENSE file at the root of the repository. The current release is v0.4 from 2026-10-19, and the last push to the repository was on the same day.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/getlostin-ctr-nitrofueled-pc)Was this useful?