Bloodborne Runs on Linux Without an Emulator. Sort Of, and the Caveat Matters.

2026-10-05 · News and analysis

Affiliate disclosure: This guide contains affiliate links. As an Amazon Associate, we earn from qualifying purchases at no extra cost to you. Learn more.

The story going around is that Bloodborne now runs natively on Linux with no CPU emulation, executing the game's original x86-64 code directly.

That is true. It is also the least interesting true thing about the project, and stating it that way makes a claim the project does not actually make. So here is what shipped, what is genuinely new about it, and the two corrections worth carrying.

Correction one: nothing about this is official. It is a four day old project by one developer, released under the GPL, with no connection to Sony or FromSoftware. The developer says plainly that they work alone and can test on two machines.

Correction two: "no CPU emulation" is not what makes it different. The PlayStation 4 is an x86-64 machine. shadPS4, the general PS4 emulator, already runs the game's own x86-64 code natively on your CPU. It never emulated the processor either, because there is nothing to emulate when the guest and host share an instruction set. That line has been reported as the breakthrough and it is actually the baseline.

The real differences are elsewhere, and they are good.

The Short Version

• What it is: bbport, a project that converts Bloodborne's PS4 executable into a flat native Linux program ahead of time, then runs it with a runtime written for this one game.
• Status: experimental, playable. Boots, loads saves, plays, with sound, gamepad and saving. A full playthrough has not been verified.
• Version 0.2, released 3 October 2026, as a single Linux x86-64 AppImage. GPL-2.0.
• Linux only. There is no Windows build. Windows users have a different option, covered below.
• The graphics come from shadPS4, vendored into the project with roughly 200 marked changes. The developer says so, and says there would be no bbport without it.
• What is new: a two stage threaded GPU command pipeline, and temporal upscaling with motion vectors the project computes itself.
• The developer's own description is the best one: "kind of like Wine, but for Bloodborne."
• You bring the game. It needs your own decrypted dump of Bloodborne, specifically CUSA03173 at version 1.09. Nothing is included.

What It Actually Does

Three pieces, and the first is the one with no equivalent in an emulator.

The executable is converted offline. Rather than loading and interpreting the PS4 binary every time you start, bbport converts the game's eboot into a flat memory image ahead of time, with the PS4's own C library and file library linked into it as native code. A small loader maps that image and jumps into the game. The loader and runtime together are about five thousand lines.

The system calls hit a purpose-built runtime. A general emulator has to implement a broad approximation of the PS4 operating system so that any game's calls land somewhere sensible. bbport implements exactly what Bloodborne asks for and nothing else: memory, threads, synchronisation, files, audio including the PS4's ATRAC9 codec, the controller, saves and app content.

The graphics are shadPS4's, substantially rebuilt. This is the part the headlines skip. bbport vendors shadPS4's video core and shader recompiler and modifies them, with the changes marked in the source. New on top of that: a two stage draw pipeline, render state and texture memoization, render scale proxies, motion vectors, three FSR implementations, and a GPU profiler.

So: a native executable, a bespoke runtime, and a fork of an emulator's renderer. That mix is why people are arguing about what to call it.

Is It a Port or Is It Emulation?

The project's issue tracker has a thread titled "This is emulation" and another asking the developer to respond to people saying the same thing. It is a fair question and it got a straight answer.

The developer's framing: the game runs natively, and what the project provides is a translation of the game's calls into something a PC understands. In their words, "it's kind of like Wine, but for Bloodborne."

That is the right analogy and it settles the argument honestly. Nobody calls Wine an emulator, and Wine's own name is a joke about exactly that. Wine does not emulate an x86 CPU because it does not need to. It reimplements an operating system's interfaces so a foreign binary can run on your kernel. bbport does that for one PS4 game, and ahead of time rather than at load.

By that standard it is not emulation in the sense people mean when they picture a CPU being simulated. By a stricter standard, the graphics path is a modified emulator and the runtime is high level emulation of the PS4's libraries, which is the same technique shadPS4 uses. Both readings are defensible, which is why both camps sound confident.

The useful version for a reader is this: it is not a from-scratch PC port, it is not a decompilation, and it is not a general emulator. It is a single-game compatibility layer with an ahead-of-time loader. The nearest thing we have covered is AnyPS5, which uses the same idea on PS5 binaries and has never shipped a release. bbport is that approach actually working, which is the part worth being impressed by.

If you want the underlying concepts, our decomp vs recomp explainer covers where this sits relative to real native ports, and translation layers explained covers the Wine comparison properly.

What It Adds That shadPS4 Does Not

Two things, and neither is about the CPU.

The GPU command stream got threaded. In shadPS4 a single thread processes the whole PS4 command stream, and in Bloodborne that thread is the bottleneck. bbport splits decoding and draw recording across separate threads, with a Vulkan recording thread and helpers for memory copies. The developer reports that the single threaded version capped the game at about 26 FPS, and that it now reaches 90 to 150 depending on resolution and scene.

Temporal upscaling that had to be built from nothing. Bloodborne has no velocity buffer, which is normally a hard requirement for temporal upscaling. So the project derives motion itself: camera motion from the depth buffer and scene matrices, and object motion for characters, cloth and weapons from the previous frame's vertex positions. The scene is jittered sub-pixel, rendered at reduced resolution, and upscaled with FSR 3.1, FSR 4 or FSR 4.1.1.

The FSR 4.1.1 path is unusually careful about licensing. AMD's library is recorded once on your own machine, from your own files, and its passes are replayed natively on Vulkan, bit-exact. The project distributes none of AMD's model data.

Users in the tracker report the practical upshot, and it is not framerate. The win people describe is temporal stability: Bloodborne's thin geometry, the metal fences around Yharnam, shimmers badly even at 4K native, and proper temporal upscaling fixes that.

The Performance Numbers Are One Machine

Everything below is the developer's own measurement on their own hardware. We have tested nothing.

Frame rate above 30 relies on community patches that make the simulation use the real frame time, which the project compiles in at startup. 30, 60 and 90 FPS modes are also offered.

The only machine tested thoroughly is an AMD Radeon RX 7800 XT on Mesa with RADV. One user reported a successful start with FSR 3 on a GTX 1060, where selecting FSR 4 produced a black window.

On a Steam Deck

The project ships its release as an AppImage and names the Steam Deck as the reason. That is more Deck attention than most projects of this kind give, and it still is not a green light.

What is there. A single x86-64 AppImage, about 829 MB. Add it to Steam as a non-Steam game, no compatibility tool needed, since it is already a Linux binary. A --play flag skips the launcher window for Game Mode. MangoHud is bundled. The project tells you to pick the 1280x720 output, because the game is 16:9 and the Deck's 1280x800 screen gives you thin bars.

What is not there. "Steam Deck validation of the AppImage" is still an open item on the project's own roadmap, and so is the parallelism work it calls most important for the Deck. There is no published Deck performance figure from the developer.

What users report. The tracker has a Deck crash report: it plays for a while, then exits with code 139, which is a segmentation fault. A second person describes crashing during the Cleric Beast fight on a Steam Deck LCD at mostly default settings with FSR 3 Quality and the unlocked frame rate patch.

So the honest Deck verdict is that it launches and plays and then falls over, four days into the project's life. That is normal for day four. It is not something to plan an evening around yet.

A

What You Need

• Linux on x86-64, with a Vulkan 1.3 GPU. There is no Windows build and no ARM build, so Android handhelds are out entirely.
• Your own decrypted dump of the CUSA03173 folder at game version 1.09. The version is specific, not a suggestion. We do not cover acquiring game files, and the project ships none.
• For FSR 4 and 4.1.1, a GPU exposing specific Vulkan shader features. FSR 4.1.1 additionally needs a Valve shader extension. Unsupported choices fall back to FSR 3.1 before the first frame rather than failing.
• For FSR 4.1.1 assets, your own AMD library files, processed on your machine by a tool in the project. These are not packaged.

What Is Broken

Four days old, 18 open issues, and the list is informative rather than damning.

Ghosting from the homemade motion vectors. There is an open issue for it and a user describes the sewers as heavily affected, while saying the rest of the game is far more stable than before. Deriving motion vectors from depth and vertex positions is a clever workaround, not a free one.

Crashes with code 139. Reported on the Steam Deck and on desktop, including instant crashes at startup for some people. This is the most common complaint.

Character creation and name entry. One report of being unable to create a character, and an open issue where the name entry dialogue gives no on-screen feedback in fullscreen, with a patch attached by the reporter.

Controller handling. No way to pick a controller or switch between them while running.

Flickering item glyphs, a visible mouse cursor in fullscreen, and build failures when assembling the FSR 4.1.1 assets.

Unfinished GPU work. Occlusion queries use synthetic pixel counters and one predication instruction is unimplemented, which the project documents rather than hides.

The developer also says the renderer is being reworked onto a PC style memory model, and that this is not released yet because it is still raw.

If You Are on Windows

bbport will not help you. But a separate project appeared on 4 October that might: a Windows shadPS4 build for Bloodborne specifically, adding NVIDIA DLSS alongside FSR 3.1 and FSR 4. It is on version 1.5.2 already and a user in bbport's own tracker recommends it for having less ghosting.

That is a per-game emulator fork rather than anything native, which is the model we covered in how Bloodborne and Gravity Rush 2 reached PC. It is also days old with tiny download counts, so treat it as equally experimental.

There is also a Windows fork of bbport itself, created on 5 October. It has no releases, so there is nothing to download from it yet.

The AI Question

This came up in the tracker and it deserves a careful answer rather than an exciting one.

Several commenters accused the project of being AI written. The developer did not deny it. Their response was that AI is a tool you need to know how to use, and that quality control of the final product is what matters.

The repository carries no AI disclosure policy, no contributing guide and no agent configuration file, so there is nothing stating the extent either way. What exists is an accusation, a non-denial, and a shipping build.

We are not going to characterise it further than that. The scene is genuinely split on this question and we cover the split, including the projects that disclose properly and the ones that do not, in the recomp scene's AI problem. shadPS4's own mainline now merges AI-assisted fixes under a written policy, which is covered in Claude is fixing PS4 games in shadPS4.

Should You Try It

If you run Linux on a desktop with a recent AMD GPU, yes. That is the configuration it was built and tested on, the download is one AppImage, and the temporal stability improvement is the kind of thing you cannot get from the base emulator at any resolution.

If you are on a Steam Deck, wait a few weeks. It runs, which is remarkable. It also crashes, Deck validation is still an open roadmap item, and the threading work that would most help the Deck is unfinished.

If you are on Windows, this is not your project yet. Use the Windows shadPS4 Bloodborne fork, or mainline shadPS4.

If you were excited by "runs without an emulator," recalibrate slightly. The achievement here is real but it is not the absence of CPU emulation, which the PS4's architecture handed everyone for free. It is one person building a single-game compatibility layer, threading a bottleneck the general emulator still has, and inventing motion vectors for a game that never produced them. That is a better story than the headline.

Questions People Ask

Does Bloodborne really run natively on Linux now?

In the sense that the game's own x86-64 code executes directly on your CPU, yes, and a project called bbport released a playable Linux build on 3 October 2026. But that was already true of shadPS4, because the PS4 is an x86-64 machine and no PS4 emulator has to emulate the processor. What bbport adds is an ahead-of-time converted executable, a runtime written only for this game, and a heavily reworked version of shadPS4's renderer.

Is bbport an official Bloodborne PC port?

No. It is an unofficial community project by a single developer, four days old at the time of writing, with no involvement from Sony or FromSoftware. There is still no official Bloodborne PC release.

Is bbport emulation or not?

Both answers have a case. The developer's description is "kind of like Wine, but for Bloodborne," which is accurate: it reimplements the PS4's library interfaces rather than simulating its CPU. But the graphics path is a modified fork of the shadPS4 emulator, and the runtime is high level emulation of PS4 libraries. It is best understood as a single-game compatibility layer rather than either a real port or a general emulator.

Does bbport work on Windows?

No. The only release is a Linux x86-64 AppImage. A Windows fork of the project exists but has published no builds. Windows users wanting better Bloodborne visuals should look at the Windows shadPS4 Bloodborne fork with DLSS and FSR instead.

Does bbport work on Steam Deck?

It launches and plays, and there are crash reports from Deck users at default settings. The project ships its AppImage with the Deck in mind and tells you to select the 1280x720 output, but "Steam Deck validation" is still an open item on its own roadmap. Treat it as something to try rather than rely on.

What do I need to run bbport?

Linux on x86-64, a Vulkan 1.3 GPU, and your own decrypted dump of Bloodborne specifically at CUSA03173 version 1.09. The project includes no game files. FSR 4 and FSR 4.1.1 need extra GPU features and, for 4.1.1, AMD library files processed on your own machine.

How much faster is bbport than shadPS4?

The developer reports about 90 FPS at 4K with FSR 4 Balanced and about 150 FPS at 1440p on an RX 7800 XT, up from roughly 26 FPS before the GPU command stream was threaded. One user with a strong desktop says they see no framerate improvement over shadPS4 at all, and that the real gain is image stability. Only one machine has been thoroughly tested, so treat all of it as indicative.

Can an Android handheld run this?

No. The build is x86-64 Linux, and PS4 software is x86 throughout. No Retroid, Anbernic or phone can run any of it. Our guide on why ARM handhelds miss out covers the general version of this wall.

Related Reading

• How Bloodborne and Gravity Rush 2 Reached PC: The shadPS4 Fork Era
• shadPS4 Setup Guide
• PS4 Emulation on Handhelds
• AnyPS5: Running PS5 Games Natively Without an Emulator
• Decomp vs Recomp: How Old Games Become PC Ports
• FEX, Box64, Proton, DXVK: What Translation Layers Actually Do
• The Recomp Scene Split Three Ways Over AI
• Claude Is Fixing PS4 Games in shadPS4

Written 5 October 2026. Project status, version numbers, the technical description, system requirements, performance figures and the roadmap come from the bbport project's own README and documentation, retrieved 5 October 2026. The developer's "like Wine, but for Bloodborne" description and their response on AI are quoted from their replies in the project's issue tracker. Bug reports and the Steam Deck crash accounts are user reports in that same tracker, not our testing. Release dates, star counts and download counts are from the GitHub API on the same date. All performance figures belong to the developer who published them, measured on a single machine. We have not run bbport on any hardware. All emulation and compatibility software should be used with game files from hardware you legally own.