Bloodborne Windows Launcher 2.1: Community Fixes End the Long-Session Crash

By Indie Kings | October 22, 2026

Updated October 22, 2026: The Jgamrot build of Bloodborne for Windows published launcher 2.1 on 22 October 2026, about 54 minutes after 2.0. The release is mostly other people's work: four community pull requests and a set of upstream fixes adapted from two other ports, aimed at failures that only show up late in a long session.

Image: GitHub repository card for Jgamrot/bloodborne_pc, the Windows port and launcher for Bloodborne.

A launcher that became the product

Bloodborne for Windows is three things stacked: the game's own code running natively on the CPU, its graphics translated to Vulkan, and a launcher that owns everything around it. The repository describes the result as Bloodborne running natively on Windows 10 and 11 with a launcher in 13 languages, DLSS, FSR 3.1 and 4, unlocked frame rate, cheats, mods and one-click updates.

That last list is the story of version 2.x. The renderer gets the headlines, but the launcher is where the project's quality now lives, and the 2.1 notes are almost entirely about the interface between a translated console game and a PC that has been running it for hours.

The prerequisite has not changed and should be stated first. You need your own decrypted copy of Bloodborne, disc CUSA03173, version 1.09. No game files are included. The project states it is not affiliated with Sony Interactive Entertainment or FromSoftware, and that sentence is doing exactly the work it appears to be doing.

Three ports deep, and what that means for support

The README is unusually clear about the family tree, and the clarity is useful when something breaks. This fork is based on Supermedo's Windows port by Mohammed Albarghouthi, which builds on deadinside28's bbport and on the shadPS4 emulator's renderer. Three layers of other people's work sit under the launcher.

Version 2.1 makes that dependency concrete. It ports fixes from Supermedo's and Awakenchan's builds for open issues, and it credits those ports by name in the first line of the release notes. Two of the long-session fixes are attributed to Awakenchan 0.9.35 and 0.9.34, which means a bug in this build was diagnosed and fixed somewhere else first and then carried across.

That is normal for this corner of PC gaming and it has a practical consequence for anyone filing a bug. A problem that exists in all three forks will be fixed upstream and arrive here later. A problem specific to this launcher is the maintainer's. The release notes are structured so you can tell which is which, which is more than most forks manage.

The long-session fixes

The 2.1 notes include a failure that only appears after hours of play, and the explanation is specific enough to be useful even to someone who will never read the code.

Three issue numbers are named: #74 for frame rate falling over a long session, and #93 and #83 for a crash at guest offset 0x2169edc after hours of play. The causes are different and the notes treat them separately.

Problem	Cause described in the notes	Fix
Frame rate falls over a long session (#74)	Occlusion queries were not being completed in order with the copy that clears them, and lock, semaphore and thread lookups slowed with every loading screen	Query ordering corrected and lookup paths fixed, attributed to Awakenchan 0.9.34 and 0.9.35
Crash at guest offset 0x2169edc after hours (#93, #83)	A query the game could not create was treated as fatal	The failed query is skipped and reported as visible, like every other query
"Unreachable code" GPU crash (#140)	An unknown GPU command stopped the game	The rest of its command buffer is dropped with a warning instead

The second row is the better engineering decision. A failed query is now degraded rather than fatal, which is what the notes mean by "reported visible, as every query already is". The third row is the same philosophy applied to the GPU command stream: an unknown command no longer ends the process, it ends the rest of that command buffer. Neither fix makes the underlying problem disappear, and both keep the game running while the problem is logged.

The frame rate fix is the one players will notice. A slow decline over a session is harder to diagnose than a crash, because by the time it is bad the session is long and the evidence is gone. If the notes are right that lookup cost grew with every loading screen, then a player who fast-travels a lot would see it first, which is the kind of symptom that shows up as reports after long sessions.

The four community pull requests

Four named contributors account for most of the new features, and the credit lines are specific enough to check.

Mouse flick target switching comes from LiquidRing, pull request 121. A quick sideways flick while locked on switches targets, tuned by mouse_flick_threshold in bbport.ini, default 300, with 0 turning it off. That is a small feature that only makes sense on mouse and keyboard, where the lock-on system's controller-first design otherwise forces a target cycle.

Sign-in checks and clearer start-up messages come from LDCanetti, pull request 129. There are three separate fixes in it, and all three are about the same thing: the launcher failing in a way the player cannot interpret. A Test connection button now asks The Hunter's Dream whether it accepts the sign-in instead of trusting a saved token. A leftover CUSA03173-mods folder from BBLauncher no longer stops every start. A shadPS4 savedata folder chosen as the Saves folder is explained instead of silently starting a new save.

DLSS frame generation comes from xiaodoudou, pull request 134, and the notes describe it precisely: motion vectors and jitter are supplied in the units DLSS expects. The same pull request fixes a freeze when the window is closed, which was happening inside the DLSS library's shutdown path. That is the classic shape of a frame generation integration: the rendering part works first, and the teardown is where it hangs.

16:10 support comes from Vaidas12345, pull request 136. 1920 by 1200 is now available in the launcher and the in-game menu, and menu and HUD composition starts at the right draw, which fixes icons along the left edge and grey loading bars. That is a display ratio the game never shipped with, and getting the menus right is the part that takes longer than adding the resolution to a list.

Frame generation, ultrawide and the 13 languages

The 2.0 release, published the same day, is the feature half of the pair, and a few items explain why the launcher has become the thing people talk about.

FSR 3.1 frame generation no longer leaks video memory at roughly 60 MiB per second until the device is lost. One long hitch no longer pauses frame generation. FSR 4 gained the 4320 tier for 32:9 and 8K outputs, about 45 MB of download in all. Discord Rich Presence arrived, off by default, reading only the game's memory and showing your area, boss fight, level, Blood Echoes and Insight. Trophy notifications gained themes, sounds and custom assets in a custom_trophy folder inside your saves folder. Stamina cheats were added with the ability to switch them on and off without a restart.

There are also 120 and 144 FPS presets, a Hunter's Atlas map that stays fast with fog, pickups and close zoom, controller play that hides the mouse cursor, and a fix for striped shadows in Chalice Dungeons on NVIDIA cards with an old shader cache. The co-op path finds Tailscale wherever it is installed, which is a practical detail for a community that has been using mesh VPNs to play together.

The 13-language claim is worth separating from the game's own localisation. The launcher is translated into 13 languages; the game text is a separate problem, and the 2.1 notes include a fix for that too, enabling "Unlock Game Region" for every text language except English and Russian so Spanish, Japanese and the others display their own text.

Your own dump, unofficial servers and account risk

Our take: the engineering here is genuinely impressive and the legal and account position is not something a release note can fix.

The project requires a decrypted copy of a game you own, which is the line it draws, and it ships no game files. Running it still means executing a recompiled version of a commercial game on an unsupported platform, and the fact that the tooling is open source does not change what Sony's terms say about that. We are reporting on the release, not advising anyone on their local law.

The online side needs a separate warning. A Test connection button that asks The Hunter's Dream whether it accepts your sign-in tells you the launcher talks to an unofficial server, not Sony's. Any account used there is outside the platform's official service, with the usual consequences for saves, achievements and account standing. Treat it as a separate account decision, not a checkbox.

There is also a security dimension that comes with any launcher that reads game memory. Discord Rich Presence is explicitly memory-reading and off by default. Mods are described as loading without changing your game files, and their features work through engine hooks. The launcher's own update path is what keeps that safe, and the notes say it ships one-click updates, so keeping it current is the cheap half of the risk management.

FAQ

Do I need to own Bloodborne to use this?
Yes. It requires your own decrypted copy of CUSA03173 version 1.09, and the repository ships no game files.

Does launcher 2.1 include the game?
No. It includes the launcher, configuration and mod support. The game data comes from your own dump.

What is the main fix in 2.1?
The long-session problems: frame rate that fell over time because occlusion queries and lookup paths were mishandled, and a crash after hours at guest offset 0x2169edc caused by a query the game could not create.

Does it support DLSS frame generation now?
Yes. Pull request 134 adds motion vectors and jitter in the units DLSS expects, and fixes a freeze during shutdown in the DLSS library.

Is online play official?
No. Sign-in goes through The Hunter's Dream, an unofficial server. Any account used there is outside Sony's official service and carries the usual account risk.

What is the mouse flick threshold?
A setting in bbport.ini, default 300, that controls how hard you flick the mouse to switch lock-on targets. Setting it to 0 disables the feature.

Bottom Line

The Jgamrot build has stopped being a renderer project with a launcher attached and become a launcher project with a renderer underneath, and 2.1 is the clearest evidence of that. The headline fixes are mundane in the best way: occlusion queries completed in order, lookup paths that no longer grow with every loading screen, and a failed query that degrades instead of crashing the game after hours of play. Four community pull requests fill in the rest, including DLSS frame generation, 16:10 menus and a sign-in check that stops trusting a saved token. The lineage matters when something breaks, because two of the fixes were diagnosed in Awakenchan's port and arrived here secondhand. The caveats are unchanged and not small: your own decrypted copy, an unofficial server behind the online features, memory-reading companions off by default, and a stack of proprietary code running where it was never meant to run. Update if you already run this build, credit the contributors when it works, and keep the launcher current, because the update path is part of the safety model.

Sources

Bloodborne for Windows repository README, Jgamrot/bloodborne_pc, accessed 22 October 2026
Release notes for qml-launcher-preview-23 (Bloodborne Windows Launcher 2.1) and qml-launcher-preview-22 (2.0), published 22 October 2026
GitHub repository metadata for Jgamrot/bloodborne_pc, accessed 22 October 2026