bbhost runs Bloodborne's own code on a PC and reimplements the PS4 around it

bbhost loads the game's own ELF instead of emulating a console CPU

The starting point is an architectural choice rather than a feature list. The PS4 runs an x86-64 CPU, so Bloodborne's code does not need to be translated to run on a PC. It needs a place to live. bbhost supplies that place: it loads the game's ELF executable, relocates it, links its imports to its own implementations and starts it. The game's own code then runs at full speed on the host CPU, with no interpreter and no recompiler in the loop.

That is the difference from the emulator route, where a console's CPU and GPU are both reproduced instruction by instruction. Here the CPU side is borrowed from the machine you already own, and only the parts the game calls into are replaced. The cost of that choice is visible: some GPU work still runs through bbhost's own command processor rather than through native code, so the project is a translation layer in progress rather than a finished port.

The stated aim is a definitive PC version, the original release intact, with what a PC release would have added: any resolution and aspect ratio, 60 fps and beyond, keyboard and mouse, proper settings, mods and online play. One thing bbhost does not contain is the game itself. It ships no game code or data, so you need your own dump with the 1.09 update and its decrypted executable.

All 660 named PS4 imports are reimplemented for the host system

A game executable imports its platform. Bloodborne binds 660 named functions from the PS4's system libraries, and bbhost implements every one of them for the PC: files and saves, threads and memory, input, audio, movies, networking, and the PlayStation Network calls the online features use.

The runtime pieces behind those implementations are ordinary open components rather than bespoke ones. Window, input, audio, movies and saves run natively through SDL3, Vulkan, FFmpeg and LibAtrac9. That choice matters for anyone planning to run it on the Steam Deck, which the project lists as a supported device, because the dependencies are ones a Linux distribution can supply.

There is a second, slower track running beside the library work. Game functions are being rewritten as source code one at a time, each checked against the original, so the game can be corrected and extended in places where a patch would not reach. The project keeps a record of that work in docs/decomp.md, which is the file to read if you want to know whether a particular behaviour has been rewritten yet or is still inherited from the original binary.

Shader lifting replaces GCN programs, but compute still walks the PM4 buffers

Graphics are the part being moved from emulation to native code, and the split is precise enough to measure. bbhost hooks FromSoftware's own graphics layer, so draws are built directly from the engine's graphics objects instead of being assembled inside a command buffer, and it decompiles the game's GCN shader programs into typed, structured SPIR-V as the game creates them. The status table counts 3,206 of 3,209 pixel shader programs lifted, with all vertex and tessellation programs lifted as well, and reports 100 percent of draws at twelve measured places running through lifted shaders.

The remainder still runs the old way. Compute shaders, and the few programs the lifter refuses, are translated by bbhost's GCN compiler. Compute dispatches, labels and fences remain emulated, running through bbhost's command processor, which walks the game's PM4 command buffers. GPU particle counters are an exception, kept natively as per-buffer counters.

Two further costs come with that arrangement. Roughly 5 GB of the game's GPU-visible memory stays imported into Vulkan, because some shaders still read it through page-table walks, and the game's tiled textures are detiled on the GPU with changes tracked by watching the game's writes. Tessellation is fully native, all three stages lifted, with mesh hulls drawing as one native pipeline and without the PS4's on-chip ring.

Getting a first launch: dump, update folder, then the setup window

The getting started instructions are short because the setup window does the checking. You need three things in place: a dump of Bloodborne with the 1.09 update applied, the update kept beside the dump as `CUSA00900-UPDATE` (the layout shadPS4 uses) or copied over it, and the 1.09 `eboot.bin` decrypted to an ELF. The release notes give the expected hash for that executable, so you can confirm you have the right build before you start.

The remaining steps are download and launch:

2. Download a release for Windows or Linux, or build bbhost yourself.
3. Start `bbhost`. The setup window asks for the two paths, checks them and
   saves them; press Play.

The setup window asks for the two paths, checks them and saves them, after which you press Play. Building the project yourself is also on the table, and the repository carries a CMakeLists.txt, a cmake directory, a src and include tree, plugins, patches, tools, tests and a third_party directory, plus bbhost.example.toml as the configuration starting point. Once the game is running, docs/running.md covers configuration, controls and saves.

Because the launcher never touches the game files, a first launch that fails usually means the two paths were wrong rather than that something in the port broke.

Frame pacing and the settings menu are rewritten, not inherited

The game's frame-time manager runs as bbhost source, with 30, 60, 90, 120 or uncapped selected, and the game's per-frame steps follow real time. The game logic stays at 60 when you raise the cap, and the timing correction means physics, animation and cutscenes run at the right speed rather than the emulated speed.

The settings live inside the game's own interface, which is why they look native: the System menu gains PC Settings, PC Graphics, PC Effects, PC Controls, PC Camera and Key Bindings, drawn in the game's style, covering anti-aliasing, ambient occlusion, shadow distance, fog, motion blur, field of view and frame cap. Resolution can be changed while playing, 21:9 and 32:9 get a wider field of view with the HUD where it belongs, and FSR 1 upscaling is available for slower GPUs. Input goes further than key rebinding: mouse camera, a pointer in every menu and button prompts that show the keys.

Some PC additions can be switched off to return the game to how it shipped. The Hunter's Dream mirror opens the character appearance editor that was cut from the release, Rebirth in the Nightmare at the Altar of Despair allows levels to be redistributed, and the late areas allow two invaders the way the chalice dungeons do.

Mods and online play bypass both the game files and the retail network

Modding works through the layer rather than through the data on disk. Four mechanisms are listed: replacement files, param tables edited by field name, byte patches applied as data, and native plugins. The plugins that ship with the project include a randomizer covering items, shops and enemies, a boss rush, gameplay mutators and the developers' own debug menu.

Online play is also routed around the original services. It runs against a private server with co-op, invasions, messages, bloodstains and summon signs between bbhost players. Underneath, the network path is native sockets and HTTP for the server side, with peer-to-peer UDP and NAT traversal for the connections that matter most, which is the summon. Nothing here touches the retail PlayStation Network, and no account linking is described.

That independence from the retail network is also why the online features can exist at all: the original calls depended on services the project has no access to, so the community server replaces them entirely. The trade-off is that the population on that server is only the people running bbhost.

The known issues list is specific, and one entry is still unexplained

The project publishes a short list of live defects, which is more useful than a general caveat. Compute work still goes through the emulated command processor, and about 5 GB of GPU-visible memory remains imported into Vulkan. A new GPU particle system's counter can start uninitialized, and bbhost clamps such a dispatch to nothing rather than hang. A new area compiles its pipelines on first sight, so the first visit can hitch briefly. Slow poison runs twice as fast at 60 fps. About one in four first summons fail and have to be repeated.

One entry is an open question rather than a workaround: the cause of a GPU hang reported on an AMD RX 580 (Polaris) under Windows is not yet known.

The other limit is the input side. The project ships no game data and asks for a dump and a decrypted executable, so anyone reading this should be clear about where their copy of the game came from and whether its terms cover that use. bbhost is licensed GPL-3.0, which covers the port's own source and does not settle anything about the game.

There is also a smaller class of limitation that comes with the architecture. The README does not document rollback, so there is no stated path back to a previous game state if a rewritten function misbehaves.

A GPL-3.0 tree shipping v0.2.18 releases and three directories of ongoing work

The maintenance picture is healthy by the only measure that counts: the last push was on 2026-10-22, and the recent release list runs from v0.2.17 on 2026-10-09 to v0.2.18 on 2026-10-10, with a pipeline-list-v2 tag on 2026-10-18. The repository is not archived, and the release cadence visible in those three tags is measured in days rather than months.

The tree gives a fair picture of where the effort goes. src and include hold the C++ core, plugins holds the native mod plugins, patches holds the byte-level patches, tools holds utilities, docs holds rendering and decompilation notes, tests hold the test code, and third_party holds vendored dependencies. The build is driven by CMakeLists.txt and the cmake directory, and configuration is exposed through bbhost.example.toml.

Two upgrade costs deserve attention. The first is the game update: the port targets version 1.09 specifically, so a newer game build is not a supported input. The second is the fast tag rate. A tree that ships several tags a week and keeps rewriting game functions as source means a build can be days old, which cuts both ways when you are chasing a specific defect or a specific graphics improvement.

Editorial conclusion

bbhost is worth adopting for PC players who already own Bloodborne and want ultrawide, a 60 fps frame cap, keyboard and mouse, mods and a private-server online mode, but it is the wrong tool for anyone expecting a turnkey install or a fully emulator-free path, since compute dispatches still run through an emulated command processor and about 5 GB of game memory stays imported into Vulkan. Before anything else, check that your dump carries the 1.09 update and that the decrypted eboot.bin matches SHA-256 941f887a562aae054fac35af8cc8f27cf075f3d4cc2e029fb5ae2a663aaa5ae7, because the setup window checks those two paths and nothing else.

Frequently asked questions

Official sources

1. droogie/bbhost on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases