SpartanPort 2.7.0

SpartanPort 2.7.0. These notes cover the 28 pull requests merged since 2.6.0, through 003e42b (#922), including the version bump to 2.7.0.

Updating from 2.6.0

• Windows: update through the launcher as usual. Saves, game settings and launcher settings carry over.
• Linux: the 2.6.0 AppImage cannot update itself. Download spartanport-x86_64.AppImage from this release once and replace the old file; from 2.7.0 on, the launcher offers updates.
• First start: the shader cache is rebuilt once and the game can stutter for a while. Later starts reuse it.

Performance and shader cache

• Low-thread CPUs (#813, issue #209). Before: on CPUs with 4 threads or fewer, the game's five job workers spun on a lock and took almost all the CPU; the GPU command thread got about 17% of one core and the sound thread starved. Now: the workers run below normal priority and the sound and file threads above it. A per-thread CPU report is written to the log on shutdown.
• Saved shaders reused (#386). Before: saved shaders were never loaded, so every start and save load compiled them again and objects popped in a few frames late. Now: they are read back, with a background prefetch so the GPU thread does not wait on the disk. New shaders and driver changes still compile.
• Smaller pipeline-binary cache (#386, issue #177). Before: the same driver binary was copied into almost every file, and the folder could pass 20 GB. Now: identical binaries are stored once; existing files are converted in the background at start.
• Readback waits (#386): image uploads and frees no longer wait for unrelated copies that only share a memory page. This targets streaming stalls, not FPS on every system.
• Delete the shader cache from the launcher (#386): Performance > Shaders has a button that shows the size and folder, asks first and refuses while the game runs. Shader notes in the corner are off by default.

Measurement	Before	After
FPS, Ryzen 5 5600X limited to 4C/4T, same scene (#813)	19-32 FPS	97-120 FPS
FPS, Ryzen 5 5600X limited to 2C/2T (#813)	14-16 FPS	40-48 FPS
Average FPS, i5-7500 + GTX 1660 Ti, player test (#813)	36.0 FPS	59.0 FPS
Sound buffer underruns per minute, 4 threads (#813)	113	0
Shaders compiled on the second start, RTX 5070 (#386)	623	6
Pipeline-binary sample of 300 real files (#386)	393 MB	11.6 MB

The 5600X figures come from limiting CPU affinity, not from real older CPUs, and other CPUs and scenes can gain less.

Game and native menus

• Cheats in the game's Options menu (#921): a Cheats entry below Game Settings has eight toggles, including Automatic QTE, and a Multipliers page with six sliders and Reset All to 1x, with native navigation and scrolling. Until now they were only in the Insert overlay menu.
• Enemy health bar (#921): also a toggle in the native Display menu.
• Overwrite confirmation (#918): picking an occupied save slot now asks first, with Cancel selected by default, and shows the new save image next to the existing save's location, date, difficulty and play time.
• Local trophies (#540): unlocks are saved and survive restarts, with a notice card, an in-game list (F8 or R3 + R2) and a Trophies page in the launcher. Icons come from the player's own game files; there is no PlayStation Network sync.
• Timed QTE crash on older CPUs (#884, issues #811 and #818). Before: the timed-QTE hook added in 2.6.0 used a BMI1 instruction, so every timed QTE crashed on CPUs without it (Sandy and Ivy Bridge, AMD FX), even with Automatic QTE off. Now: the hook uses base x86-64 instructions.
• Exit to Desktop in the game language (#779, issue #649): French, Spanish, German, Italian, Polish and Portuguese are translated. Russian, Japanese and Chinese stay in English because the menu font only covers the Latin alphabet. The translation may not work on every game version yet, and we are working to improve it.

Graphics, controls and audio

• 144 and 180 FPS (#705): new engine rates in the launcher, the overlay and the live switch. F9 or R3 + L1 + R1 now cycles 60, 100, 120, 144, 180 and 240 FPS.
• Monitor selection (#647): both launcher settings views pick the display the game opens on, falling back to the primary one.
• Steam Deck resolution (#877, issue #855): a first start on an LCD or OLED Steam Deck uses 1280 × 800 instead of leaving black bars. A saved resolution wins.
• Resolution labels (#696): 3440 × 1440, 3840 × 1600, 5120 × 1440, 5120 × 2160, 1920 × 1200, 2560 × 1600 and 1920 × 1440 are no longer marked beta, after player reports. 2560 × 1080, 1440 × 1080, 2048 × 1536, 2560 × 1920 and 8K keep the label.
• Fullscreen Alt+Tab (#695, issues #325 and #391). Before: Alt+Tab or the Windows key in fullscreen crashed the game while the swapchain was recreated on a minimized window. Now: recreation waits for the window to come back. Optimus laptops were not verified on hardware.
• Larger keyboard prompts (#617): key caps and labels such as SPACE, SHIFT and CTRL are bigger in tutorials and QTEs.
• Lyre prompts (#706): the Xbox and Nintendo styles also repaint the lyre puzzle after Hermes, through a generated copy of the level file; the game files are not changed.
• Windows audio (#665): when WASAPI fails on some outputs (optical S/PDIF, some USB DACs), the game falls back to DirectSound by itself instead of running silent, unless a driver was chosen by hand.

Launcher and localization

• Linux AppImage updates (#707, #900): the AppImage checks for updates, verifies the download against the release SHA-256 file and replaces itself. A bad checksum, a failed download or a read-only folder leave it unchanged.
• Languages (#615, #840, #869): Brazilian Portuguese in the game-language list, a complete Simplified Chinese interface and an Indonesian launcher. Choosing a language does not add missing language files to the game.
• Game-language note (#882, issue #842): the launcher explains that the game's own save keeps its text and speech languages, changed in the game's menus.
• Language change on Linux (#857, issue #697): saving a new launcher language no longer closes the AppImage on Fedora.
• Desktop shortcuts (#838, issue #824). Before: after 2.6.0 the old shortcut deleted itself at every start and a SpartanPort one appeared. Now: the migration runs once and never deletes a shortcut.
• Memory errors at start (#905, issue #878). Before: a failed memory reservation (error 1450) gave a black screen with the FPS counter running, and the reason was only in the log. Now: the game stops and the launcher shows advice and the log. Low-memory setups are still unsupported.
• Linux build with GCC 16 (#913): fixed a buffer size in the CPU report that stopped the build.
• Regional patches (#894, issue #817): the game is recognized by its own title again after the rename, which restores the built-in patches (including 3440 × 1440) on unlisted IDs. CUSA01740 is now listed.

Tools

• Voice replacement (#576): xvag_voice_swap.py builds an Update folder from the player's own recordings, without writing to the dump. Only mono lines with the original length are handled.

Requests addressed

Issue	Fixed by
#177 Pipeline-binary cache too big	#386
#209 Performance on i3-9100F and similar CPUs	#813
#325 Crash on Alt+Tab in fullscreen	#695
#391 NVIDIA Optimus flickering and crash	#695
#649 Exit to Desktop not following the language	#779
#697 AppImage crash when changing the launcher language	#857
#811 Crash on the QTE finisher near Helios	#884
#817 3440 × 1440 broken and CUSA01740 missing	#894
#824 Desktop shortcut deleting itself	#838
#842 Choosing English voice with other text	#882
#855 1280 × 800 for the Steam Deck	#877
#878 Black screen on memory reservation failure	#905

#818 (crash when starting QTEs) has the same cause as #811 and stays open until players confirm the fix on 2.7.0.

Known issues

Same as 2.6.0: see the 2.6.0 release notes. This release is not a general fix for startup crashes, loading hangs, corrupted textures or integrated GPUs. Also:

• High frame rates can still block some traversal and QTE sequences. Switch to 60 FPS with F9 or R3 + L1 + R1 for that part.
• Do not share one shader cache with an older build: it writes the old numbering. If it happens, delete user/cache/CUSA01623/disk_shaders.bin to force a rebuild.
• Autosave capacity is unchanged, and save previews are not verified on every region and update.
• Trophies are local: PlayStation unlocks are not imported, and an advanced save may not trigger earned trophies again.
• 8K and the other beta resolutions need more testing and more memory and VRAM.
• Native menus need a recognized game script; other regions or updates may need more work.
• AppImage self-update was tested against a local mock release only. Its first real run is the update after 2.7.0.

For a new or continuing problem, open an issue with the release version, operating system, CPU, GPU and driver, render resolution, game title ID and update version, reproduction steps and the relevant log.

Validation

• CPU scheduling (#813): live A/B on a Ryzen 5 5600X + RX 6700 XT with limited affinity, and a player check on an i5-7500 + GTX 1660 Ti with the test build.
• Shader cache (#386): cache tests, gameplay on AMD and on an RTX 5070.
• Save confirmation (#918): service tests on Windows and Linux with AddressSanitizer and UndefinedBehaviorSanitizer, 8 runtime tests, layout at 720p and 1080p, final layout confirmed in game.
• Native settings (#921): 28 Python...

Test build startup-test1 on 2.6.0: startup fixes and diagnostics (2.6.0-startup-test1)

Test build for startup crashes, black screens and first-level loading failures, including the #188 candidate. Windows and Linux packages are attached to this single release. The launcher still shows version 2.6.0.

This build combines candidate fixes and additional diagnostics. It is not a confirmed fix for every startup report. Gameplay and comparisons on previously affected machines are still pending.

Download spartanport-windows.zip for Windows or spartanport-x86_64.AppImage for Linux. Both are complete packages: Python and a separate source patch installation are not required.

What changes from 2.6.0

• First-level loading candidate (#188, #270, #467, #497, #769). Preserved the Windows shared-descriptor I/O fix and the crash diagnostics from the preceding #188 test build. Sequential and positioned reads sharing a descriptor are serialized. Fatal errors include the last 128 reads, registers and instruction information. Confirmation on a previously affected machine is still needed.
• Launcher errors stay visible (#404). The output reader remains alive while the launcher window is hidden. If launching fails, the window now reappears with the error instead of closing.
• NVIDIA 610 startup fallback (#774). Proprietary NVIDIA 610 drivers use conventional pipeline compilation instead of the optional binary-cache path. This avoids the global-key query implicated in the report. Other driver families retain their existing behavior; the affected Linux/NVIDIA system still needs testing.
• Device creation failure stops initialization (#556). The renderer no longer continues with an invalid logical device after creation fails. This improves error handling without establishing the original cause of the report.
• Invalid game files are identified before gameplay (#243, #621, #452). Preparation rejects invalid REGION.TXT identifiers and names executable/module files that are not SELF or ELF. Binary analysis found a path from an unrecognized region to the null strncpy source seen in #243/#621. The reporters' file contents are not available to confirm that cause. Original files are preserved; the message asks for the original file from a complete dump.
• Missing data directories no longer abort native startup. Parent directories are created when needed, and an explicitly selected GPU data directory is honored even when it does not exist yet. A file in that location produces a controlled error instead of an uncaught filesystem exception.
• Diagnostics without closing the game (#568). Use Advanced > Diagnostics > Collect running game diagnostics to request thread information while the game remains open. Windows also records recent file reads. Keep the launcher available to use this button.
• Specific startup guidance. Added advice for address reservation error 487 (#546/#605), insufficient Vulkan support (#404), Intel driver crashes (#286), RivaTuner crashes (#829), invalid-device failures (#556), and the signatures in #249/#383. Advice does not mean the underlying fault is fixed.

How to test

1. Keep your working installation and back up your saves. Extract the Windows ZIP into a separate folder, or make the Linux AppImage executable and open it. Select the same game dump and use copies of your saves/settings. Keep resolution, patches and cutscene-skipping behavior the same for comparisons.
2. Repeat the startup that failed in three separate launches. For #188, start a New Game, choose the difficulty and check whether the opening reaches playable gameplay. Preserve the complete last_run.log before each new launch; with a custom saves folder, the log is inside that folder.
3. For #404, enable Close the launcher when the game starts and check that preparation continues. An unsuccessful launch should show the launcher again with its log.
4. For #774, leave Pipeline binary cache enabled. On NVIDIA 610, the log should report conventional compilation without entering binary-cache initialization.
5. If the game hangs, keep it open and use Collect running game diagnostics. Preserve the log after the thread snapshot finishes.

Reply in the corresponding issue with this build tag, CPU, GPU/driver, operating system, game title ID/update version, settings, the complete log and whether the previous build still fails at the same point. First-level crashes matching the #188 signature belong in #188. Do not upload game files.

Known issues

• Gameplay and affected-hardware validation are pending. Local regressions and launcher startup do not confirm that every reported crash is fixed. The NVIDIA 610 policy was checked with synthetic identifiers; that NVIDIA hardware was not available locally. Earlier gameplay checks belong to the preceding #188 candidate.
• Memory and address reservation remain environment-dependent (#213, #546, #605). This build does not create additional RAM/page-file capacity or establish one cause for every report in #213. Increasing the page file does not resolve address reservation error 487. No global Windows security settings are changed automatically.
• Vulkan 1.3 remains required (#404). A test build cannot add capabilities missing from the GPU or driver.
• Intel and RivaTuner crashes need comparisons (#286, #829). Test the Intel driver installation or disable the RivaTuner overlay for SpartanPort as applicable. Driver and overlay settings are not changed automatically.
• Some reports still need diagnosis (#249, #383, #568). The original Windows signature in #383 is separate from the Linux pipeline-binary report posted there; that Linux report follows the #774 test path. The original cause of #556 and the reporters' region data in #243/#621 remain unconfirmed.

Validation so far

• Windows Python suite: 668 tests run, 74 skipped, no remaining failures. Modules ran in separate processes to isolate Tk state. Translation coverage was corrected and rechecked. Skipped tests are not counted as validated behavior.
• Linux native-loader Python tests: 23 tests run, two Windows-only cases skipped, no failures. The shared-descriptor I/O regression passed on both platforms.
• Pipeline-binary initialization tests passed on Windows/AMD RX 6700 XT and Linux/llvmpipe. The binary-cache regression also passed on Linux. These are not NVIDIA gameplay checks.
• Opened both packaged launchers with isolated data and verified their frozen dependencies. The Windows native executable code matches the tested build. Linux was built on Ubuntu 24.04, and the AppImage launcher was opened under Xvfb in WSL. No Linux gameplay or other-distribution validation is claimed.
• Verified Windows ZIP integrity, package hashes and all six uploaded asset digests. Both packages and their SHA-256 files are attached.
• Source base: 6eba8dafcfc95566ffbebe136b24dab1b84de828. Candidate changes remain uncommitted and are supplied in source-changes.patch, verified to reconstruct 19 changed source/test files. source-manifest.json records source and package hashes. The release target identifies the base, not a commit containing these local changes. Players do not need to apply the source patch.
• Not validated yet: gameplay of this combined build, affected Intel/NVIDIA configurations, or resolution of every startup issue listed above.

SHA-256: see spartanport-windows.zip.sha256 and spartanport-x86_64.AppImage.sha256.

This project builds on Supermedo/bloodborne_pc, deadinside28/bloodborne_pc and shadPS4.

You still need your own copy of the game files. No game files are included.

Test build qte-bmi1-test1 on 2.6.0: QTE crash on CPUs without BMI1 (2.6.0-qte-bmi1-test1)

EN-US

Windows test build for the 2.6.0 crash on every timed QTE on CPUs without BMI1 (Intel 3rd generation / Ivy Bridge and older, e.g. i7-3770, i5-3470, Xeon E3-1230 v2), reported in #811, #818, #833, #860, #874 and in a comment on #814. Log signature: Fault: exception 0xc000001d at guest offset 0x2090015, with CPU: missing ... BMI1 earlier in the log.

Candidate fix. It has not yet been confirmed on a CPU without BMI1.

Download spartanport-windows.zip, the complete Windows package. Python and a separate patch installation are not required. No Linux package is included.

What changed

• The timed QTE hook added with Automatic QTE (#729) used andn, a BMI1 instruction. The CPU instruction rewrite only covers the game's own code, not the hook, so every timed QTE stopped the game on these CPUs, even with Automatic QTE turned off. The hook now uses mov / not / and, which give the same result on every supported CPU.
• Added a regression test that decodes every hook stub and fails on BMI1, BMI2, LZCNT, MOVBE, F16C, AVX2 or FMA instructions.

How to test

1. Keep your working installation and back up your saves. Extract this ZIP into a separate folder and select the same game dump.
2. On a CPU that crashed in 2.6.0, load a save before the QTE that crashed (finisher on the Centaur, Chain of Balance, the three-headed dogs, etc.) and complete it. Try it once with Automatic QTE off and once with it on.
3. Play a few more QTEs, then close the game normally.
4. Reply in your issue with this build tag, your CPU, whether the QTEs passed, and the complete user/last_run.log. When using a custom saves folder, the log is inside that folder. Do not upload game files.

Validation so far

• The new hook-instruction test failed on 2.6.0 with andn ecx,eax,[rdi+94h] (BMI1) and passes with this change.
• The native QTE hook test, which runs the stubs, passed: a new press yields the expected button mask, and Automatic QTE still sets only the prompt's button.
• Python suite: 269 tests passed, 58 skipped (they need built binaries). This package passed the clean-runner smoke test.
• Not validated yet: gameplay on a CPU without BMI1.

Source and download verification

Built from commit 080470c on branch worktree-fix-qte-bmi1, based on main 6eba8da (the base of the other 2.6.0 test builds). The launcher's version remains 2.6.0.

SHA-256: see spartanport-windows.zip.sha256.

You need your own game files. None are included.

---

PT-BR

Build de teste para Windows do crash da 2.6.0 em todo QTE cronometrado em CPUs sem BMI1 (Intel de 3ª geração / Ivy Bridge e anteriores, por exemplo i7-3770, i5-3470, Xeon E3-1230 v2), relatado em #811, #818, #833, #860, #874 e em um comentário da #814. Assinatura no log: Fault: exception 0xc000001d at guest offset 0x2090015, com CPU: missing ... BMI1 antes no log.

Correção candidata. Ainda não foi confirmada em uma CPU sem BMI1.

Baixe spartanport-windows.zip, o pacote completo para Windows. Não é necessário instalar Python nem aplicar um patch separado. Esta release não inclui pacote Linux.

O que mudou

• O hook de QTE cronometrado adicionado com o QTE Automático (#729) usava andn, uma instrução BMI1. A reescrita de instruções para CPUs antigas cobre só o código do próprio jogo, não o hook, então todo QTE cronometrado fechava o jogo nessas CPUs, mesmo com o QTE Automático desligado. O hook agora usa mov / not / and, que dão o mesmo resultado em todas as CPUs suportadas.
• Adicionado um teste de regressão que decodifica todos os stubs de hook e falha se encontrar instruções BMI1, BMI2, LZCNT, MOVBE, F16C, AVX2 ou FMA.

Como testar

1. Mantenha sua instalação funcional e faça backup dos saves. Extraia o ZIP em uma pasta separada e selecione o mesmo dump.
2. Em uma CPU que travava na 2.6.0, carregue um save antes do QTE que fechava o jogo (finalização do Centauro, Corrente do Equilíbrio, cães de três cabeças etc.) e complete o QTE. Teste uma vez com o QTE Automático desligado e outra com ele ligado.
3. Faça mais alguns QTEs e feche o jogo normalmente.
4. Responda na sua issue com a tag deste build, sua CPU, se os QTEs passaram e o user/last_run.log completo. Se usar uma pasta personalizada de saves, o log estará nela. Não envie arquivos do jogo.

Validação realizada

• O novo teste de instruções dos hooks falhou na 2.6.0 com andn ecx,eax,[rdi+94h] (BMI1) e passa com esta mudança.
• O teste nativo dos hooks de QTE, que executa os stubs, passou: um botão novo gera a máscara esperada e o QTE Automático continua marcando só o botão do prompt.
• Suíte Python: 269 testes aprovados, 58 ignorados (precisam dos binários compilados). Este pacote passou no teste de fumaça em máquina limpa.
• Pendente: gameplay em uma CPU sem BMI1.

Código-fonte e verificação do download

Compilado do commit 080470c da branch worktree-fix-qte-bmi1, com base na main 6eba8da (a mesma base das outras builds de teste da 2.6.0). A versão exibida pelo launcher continua sendo 2.6.0.

SHA-256: consulte spartanport-windows.zip.sha256.

Você precisa dos seus próprios arquivos do jogo. Nenhum está incluído.

Test build issue188-test1 on 2.6.0: first-level load crash

EN-US

Windows test build for the first-level loading crash in #188, also reported in #270, #467, #497 and #769: a read at address 0x8, guest offset 0x160b8, around Pos050 / PosSkyBox_050.

Candidate I/O fix with additional diagnostics. Resolution of #188 is not yet confirmed on an affected machine.

Download spartanport-windows.zip, the complete Windows package. Python and a separate patch installation are not required. No Linux package is included.

What changed

• Serialized reads, positioned reads/writes, writes, seeks and closes sharing the same guest descriptor on Windows. Other descriptors remain independent. A native regression reproduced a sequential read returning byte 11 instead of byte 0 during a concurrent positioned read; the candidate returns the correct data and preserves the cursor.
• Added a bounded history of the last 128 reads, dumped on a fatal error: guest paths, descriptors, offsets, requested/returned bytes, errors and unfinished operations. No activation command is needed.
• Added the missing Windows registers, including R14/R15, instruction bytes and a guarded resource-name diagnostic for the verified 0x160b8 instruction. Diagnostics do not skip the failing guest instruction.

How to test

1. Keep your working installation and back up your saves. Extract this ZIP into a separate folder and select the same game dump. Use copies of saves and settings when comparing builds.
2. On a machine that reproduced #188, start a New Game, choose the difficulty, and let the opening reach playable gameplay. Keep resolution, frame rate, patches and skipping behavior the same as your previous comparison, and report them.
3. Repeat in three separate launches. If a run succeeds, play for a few minutes and close normally. Copy user/last_run.log before the next launch; when using a custom saves folder, the log is inside that folder.
4. If it crashes, preserve the complete log before reopening. Reply in #188 with this build tag, CPU, GPU/driver, Windows version, game region/update version, whether the old build fails at the same point, and the complete log. Do not upload game files.

Validation so far

• Passed the 660-test Python suite, with 74 skipped, plus the additional crash-diagnostic check. Both new crash-diagnostic scenarios and the native shared-descriptor I/O regression passed.
• Compiled the changed native sources with warnings treated as errors.
• Two monitored local player sessions loaded Pos050 and PosSkyBox_050, reached autosave and exited with code 0. The second run restored 256 cached pipelines with no new compilation or cache errors. These runs do not confirm the result on hardware affected by #188.
• Verified ZIP integrity, absence of game/player files, required frozen modules, native startup and the launcher window with a Windows-only PATH. Confirmed the packaged native executable code matches the gameplay-tested build.
• Still pending: reproduction and comparison on a machine that previously exhibited #188. No Linux distributable was built or tested.

Source and download verification

Base: main commit 6eba8dafcfc95566ffbebe136b24dab1b84de828, including the nine recently integrated PRs. The candidate changes are still uncommitted and are supplied in source-changes.patch; source-manifest.json records the exact base and file/package hashes. Verified that the patch reconstructs every changed source file from that base. The Windows ZIP already contains the changes; players do not need to apply the source patch. The launcher's version remains 2.6.0.

SHA-256: see spartanport-windows.zip.sha256.

You need your own game files. None are included.

---

PT-BR

Build de teste para Windows do crash no carregamento inicial da #188, tamb?m relatado em #270, #467, #497 e #769: leitura no endere?o 0x8, offset do jogo 0x160b8, durante Pos050 / PosSkyBox_050.

Corre??o candidata de I/O com diagn?stico adicional. A resolu??o da #188 ainda n?o foi confirmada em uma m?quina afetada.

Baixe spartanport-windows.zip, o pacote completo para Windows. N?o ? necess?rio instalar Python nem aplicar um patch separado. Esta release n?o inclui pacote Linux.

O que mudou

• Serializadas leituras, leituras/escritas posicionais, escritas, mudan?as de posi??o e fechamento que compartilham o mesmo descritor do jogo no Windows. Descritores diferentes continuam independentes. Um teste nativo reproduziu uma leitura sequencial retornando o byte 11 no lugar do byte 0 durante uma leitura posicional concorrente; a candidata retorna os dados corretos e preserva a posi??o.
• Adicionado hist?rico limitado ?s ?ltimas 128 leituras, registrado em caso de erro fatal: caminhos do jogo, descritores, posi??es, bytes solicitados/retornados, erros e opera??es n?o conclu?das. N?o exige comando de ativa??o.
• Adicionados os registradores ausentes no diagn?stico do Windows, incluindo R14/R15, os bytes da instru??o e a consulta protegida do nome do recurso para a instru??o verificada em 0x160b8. O diagn?stico n?o ignora a instru??o que falhou.

Como testar

1. Mantenha sua instala??o funcional e fa?a backup dos saves. Extraia o ZIP em uma pasta separada e selecione o mesmo dump. Use c?pias dos saves e das configura??es ao comparar os builds.
2. Em uma m?quina que reproduzia a #188, inicie um Novo Jogo, escolha a dificuldade e deixe a abertura chegar ao gameplay. Mantenha resolu??o, FPS, patches e uso de pular cenas iguais aos da compara??o anterior e informe essas op??es.
3. Repita em tr?s aberturas separadas. Se funcionar, jogue por alguns minutos e feche normalmente. Copie user/last_run.log antes da pr?xima abertura; se usar uma pasta personalizada de saves, o log estar? nela.
4. Se ocorrer crash, preserve o log completo antes de reabrir. Responda na #188 com a tag deste build, CPU, GPU/driver, vers?o do Windows, regi?o/atualiza??o do jogo, se o build anterior falha no mesmo ponto e o log completo. N?o envie arquivos do jogo.

Valida??o realizada

• Aprovada a su?te de 660 testes Python, com 74 ignorados, al?m da verifica??o adicional do diagn?stico de crash. Os dois novos cen?rios de diagn?stico e o teste nativo de I/O com descritor compartilhado passaram.
• Compilados os fontes nativos alterados com avisos tratados como erros.
• Duas sess?es locais monitoradas carregaram Pos050 e PosSkyBox_050, chegaram ao autosave e encerraram com c?digo 0. A segunda restaurou 256 pipelines do cache, sem compila??es novas nem erros no cache. Essas execu??es n?o confirmam o resultado no hardware afetado pela #188.
• Verificadas a integridade do ZIP, a aus?ncia de arquivos do jogo/usu?rio, os m?dulos necess?rios, a inicializa??o nativa e a janela do launcher com PATH restrito ao Windows. Confirmado que o c?digo nativo empacotado corresponde ao build testado no jogo.
• Pendente: reprodu??o e compara??o em uma m?quina que apresentava a #188. Nenhum pacote Linux foi compilado ou testado.

C?digo-fonte e verifica??o do download

Base: commit 6eba8dafcfc95566ffbebe136b24dab1b84de828 da main, incluindo as nove PRs integradas recentemente. As altera??es candidatas ainda est?o sem commit e est?o em source-changes.patch; source-manifest.json registra a base exata e os hashes dos arquivos/pacote. Verificado que o patch reconstr?i todos os fontes alterados a partir dessa base. O ZIP do Windows j? cont?m as altera??es; jogadores n?o precisam aplicar o patch de c?digo-fonte. A vers?o exibida pelo launcher continua sendo 2.6.0.

SHA-256: consulte spartanport-windows.zip.sha256.

Voc? precisa dos seus pr?prios arquivos do jogo. Nenhum est? inclu?do.

Test build issue345-test1 on 2.6.0: WAD loading diagnostics

Diagnostic test build for the endless WAD loading in #345, with similar reports in #428, #636 and #701.

This is a diagnostic build, not a confirmed fix for the campaign hang. Source: 397c307a86c7f270dca0fbd44b9aaa5d103d0f8c on fix/issue-345-wad-loading, based on main commit 4b843a7dd10bc6f159da378e308b89c1627392f4.

Download spartanport-windows.zip, the complete Windows executable package. No source patch or separate activation helper is required. No Linux package is included in this Windows test release.

What changed

• Added optional WAD file tracing with SPARTAN_FILE_TRACE=1. It is off by default.
• WAD opens, sequential reads, positioned reads and closes have paired phase=begin / phase=end entries with a shared ID. They record guest paths, descriptors, offsets, requested and returned bytes, errors, file sizes on open, and timing. Entries are flushed so the last unfinished operation can survive a hang.
• Only WAD files are traced, case-insensitively. Host filesystem paths and file contents are not included in the new trace records. Non-WAD files are filtered out.
• Retained the protected-page read recovery and synthetic regression from the preceding candidate. The player retest below does not support that recovery as the explanation for the post-Hades hang.

Thanks to @Azaberth for the original patch, the checkpoint retest, log and autosave. On 2.4.0, his patched build still hung after HADESDEATH; the attached log reports reads recovered=0. The purpose of this build is to find where WAD file operations stop, without assuming the cause is file reading, GPU synchronization or scheduling.

How to test

1. Close other instances of the launcher and game. Back up your saves and keep your working installation available. Extract spartanport-windows.zip into a separate folder, select the same game files, and use a copy of the save that reproduces the hang. Keep your previous settings, mods and translation for the first comparison and report them.

2. In the folder containing the extracted SpartanPort.exe, open PowerShell and run the commands below. They enable tracing for that PowerShell session. No administrator privileges are needed. Launch the game using Play.

   $env:SPARTAN_FILE_TRACE = "1"
   .\SpartanPort.exe

3. Confirm user/last_run.log contains Runtime: WAD file tracing enabled (SPARTAN_FILE_TRACE=1) and File trace: entries. If they are missing, report that before drawing conclusions from missing WAD operations.

4. For #345, load the original autosave, defeat Hades, and let HADESDEATH finish without skipping. Other useful points: enter the Forge after the statue fight (#428), the Cav600 transition (#636), or the hidden passage after Helios (#701).

5. Record whether loading completes and roughly how long you waited. If it remains stuck, copy the available user/last_run.log before closing or restarting. If it completes, close normally and copy the log before the next launch.

6. Reply in #345 with this build tag, CPU, GPU/driver, Windows version, game region/update version, affected checkpoint, mods/translations, and the complete log. If possible, compare the same checkpoint with your previous build. Do not upload game files.

Interpretation guide: no open for the target WAD means the request has not reached the traced file-open path; a begin without a matching end identifies an in-flight operation; completed reads, their offsets and the file size help identify how far the file was processed. These observations narrow the investigation, but do not by themselves identify a GPU fence, decompression or Fios bug.

Tracing deliberately adds logging and flushing overhead. Use it only for reproducing the loading problem, not for FPS comparisons. Close that PowerShell session and launch the EXE normally to leave tracing disabled.

Validation so far

• Added the tracing contract test before implementation. It failed because the previous runtime produced no WAD trace records.
• Windows: compiled with GCC 16.2.0 and ran trace-on, trace-off, and protected-page regression cases with warnings treated as errors.
• Linux: compiled with GCC 15.2.0 under WSL/musl and ran the same cases plus the existing file-mods test. A temporary header shim handles existing runtime names that collide with newer musl declarations; it is not shipped.
• Checked matched operation IDs, successful and failed opens/reads, sequential and positioned offsets, file sizes, negative offsets, WAD/non-WAD filtering, and no diagnostic output when disabled. The earlier protected-page regression still passes.
• Checked shell syntax and Git whitespace errors.
• Full Windows package build with MSYS2 CLANG64 and clean-runner startup checks passed in GitHub Actions run 39426658134. The workflow did not publish a release.
• Downloaded the produced ZIP and verified its SHA-256 and ZIP integrity. Confirmed the compiled probe contains the new trace markers. With a clean PATH, the packaged probe completed --cpu-features, and the packaged launcher ran the import check and preserved the diagnostic environment in script mode. These checks do not exercise gameplay or WAD loading.
• Not validated: gameplay, the affected checkpoints, the loading-hang cause, tracing overhead in the game, or a Linux distributable.

SHA-256 of spartanport-windows.zip: 91027afa366c38a877f192e3282a44b2b31d64e9a65787ede5ac56b41e9290a5. The checksum is provided here for download verification.

You need your own game files. None are included.

Test build apple-silicon-test2 on 2.6.0: macOS support (2.6.0-apple-silicon-test2)

Experimental Apple Silicon test build based on 2.6.0 and the consolidated macOS port from #798. This replaces test1 for package startup testing. Requires an M1 or newer Mac, macOS 26 or newer and Rosetta 2.

What changed

• Fixed the bundled KosmicKrisp ICD manifest to use ./libvulkan_kosmickrisp.dylib, relative to the manifest rather than a system library search.
• Added the relative libvulkan.dylib and libvulkan.1.dylib aliases required by the renderer's dynamic Vulkan loader. Both point to the versioned loader included inside the app.
• Made packaging stop if the required Vulkan loader or KosmicKrisp driver is missing.
• Added a regression test and a macOS smoke test against the final mounted DMG. The smoke test loads both loader names under Rosetta, creates a Vulkan instance with Metal surface extensions and checks loaded library origins with Vulkan and dyld overrides cleared.
• Preserved the experimental Apple Silicon port, runtime settings and credits to Fleurat (#798), nizwar (#510) and Incognito-Coder (#469). Thanks to Lucas-Kobayashi for the startup report and moamlmushtaq for investigating and testing the two packaging fixes.

How to test

1. Close the launcher and game. Download spartanport-macos.dmg, open it and replace the old application in Applications with the new SpartanPort.app. Read README-macOS.txt inside the disk image. Please use the unmodified application for the first test; no manual driver-path edits, library links, Homebrew or system Vulkan installation should be needed.
2. Use your own compatible game files. Start at 720p, with engine frame rate and frame limit both set to 60 FPS.
3. Check whether the game starts past the Vulkan window error from test1. Then test cinematics, gameplay, audio, keyboard/controller input, saving/loading and scene transitions.
4. Export the log from the launcher. Report results in #798 with the macos-v2.6.0-apple-silicon-test2 tag, Mac model, RAM, macOS version, game title ID/update, FPS and scene tested, controller and any problems. Please report successful startup too.

Saves, settings and logs remain in ~/Library/Application Support/SpartanPort. Replacing the application preserves that folder; back up saves before testing.

Known issues

• Gameplay, FPS, scene transitions and physical controllers on this new package still need player testing. The earlier M4 report concerned test1 with local changes and does not validate this DMG.
• Apple Silicon and macOS 26 or newer only. Intel Macs, Sonoma and other older macOS versions, MetalFX and the alternate MoltenVK path are outside this package.
• The application is signed ad hoc and is not notarized with an Apple Developer ID. macOS may block its first launch; see the installation notes inside the DMG.

Validation so far

• Added the packaging regression before implementation and confirmed it failed without the fix.
• Passed the macOS 26 CI on the release source commit: runtime build, 12 native tests and the no-MSAA test.
• Python suite: 556 tests run, 50 skipped, no failures. Skipped tests are not counted as validated behavior.
• Generated the app and DMG. The existing packaging checks verified x86-64 runtime libraries, dependency relocation, redistribution boundaries and ad hoc code signatures.
• Mounted the final DMG read-only, verified the app signature again and passed all 8 package tests. Under Rosetta, both libvulkan.dylib and libvulkan.1.dylib loaded the bundled loader and KosmicKrisp driver and created a Vulkan 1.3 instance with Metal surface extensions. The test rejected non-system libraries outside the bundle, with Vulkan/dyld environment overrides cleared and an isolated temporary home.
• Downloaded the CI artifact and independently checked the DMG SHA-256 and source-commit.txt against the exact source commit.
• Source: eb5b29d565ef2e9facb668c8f00f9233b1a2b343 on fix/macos-test2-vulkan, based on the test1 PR head 76830ef10f99cf5ca26f0cd2e41a4ab83207ae5f.
• Build and test evidence: macOS workflow, attempt 3. The first two attempts of this run could not acquire a hosted macOS ARM64 runner; the successful attempt rebuilt and tested this exact source.
• Not validated here: game startup through the full launcher/game flow, gameplay, FPS, scene transitions and physical controllers on this new package. The isolated Vulkan instance test does not validate those behaviors.

SHA-256 of spartanport-macos.dmg: 3fcaadd85b055b1db6068e4d3fe569e2e87942846466014cd06efd6145b39a80.

You need your own game files. None are included.

Test build apple-silicon-test1 on 2.6.0: macOS support (2.6.0-apple-silicon-test1)

Test build for Apple Silicon Macs (pull request #798, with selected contributions from #469 and #510). It is 2.6.0 plus the experimental macOS port. If you have an M1 or newer Mac running macOS 26 or newer, this build is for you. Intel Macs and older macOS versions are not supported by this package.

What changes from 2.6.0

• Apple Silicon support. The game runtime runs through Rosetta 2, with the bundled KosmicKrisp driver translating Vulkan to Metal. The macOS runtime includes low-address memory allocation, Cocoa window handling and audio queue adjustments.
• A Mac application in a DMG. Drag SpartanPort.app into Applications and select your game files in the launcher. Python and Homebrew are not needed. The package includes its runtime libraries and licenses.
• Saves and settings outside the application. Saves, settings, logs and generated files live in ~/Library/Application Support/SpartanPort, so replacing the application preserves that folder.
• One macOS integration in #798. Contributions from Fleurat (#798), nizwar (#510) and Incognito-Coder (#469) were consolidated there. MetalFX and the alternate MoltenVK/Intel path are not included in this first test.

How to test

1. Download spartanport-macos.dmg, open it and drag SpartanPort.app into Applications. Read README-macOS.txt inside the disk image. Rosetta 2 is required.
2. Open the launcher and select your own compatible game dump. Start at 720p, with the engine frame rate and frame limit both set to 60 FPS, as a common test baseline.
3. Check game startup, audio, keyboard/controller input, saving and loading, and transitions between scenes. The menu opens with Insert, the key left of 1 (`), or the controller shortcut.
4. Export the log from the launcher after testing.

Reply on #798 with: your Mac model, RAM, macOS version, game title ID/update version, resolution, FPS and scene tested, whether the sound stuttered, whether your controller worked, and the exported log. If something looks wrong, include a screenshot or video.

Known issues

• Gameplay is not validated yet on this consolidated build. Clean installation and physical controller behavior also need player testing. Earlier reports from the contributors' own branches do not validate this package. No FPS target or full-game completion is claimed.
• Apple Silicon and macOS 26 or newer only. Intel Macs, older macOS versions, MetalFX and the alternate MoltenVK path are outside this first test.
• The application is signed ad hoc, not notarized with an Apple Developer ID. macOS may block its first launch. See the installation notes inside the DMG.

Validation so far

• Built on the macOS 26 CI runner: runtime, 12 native tests and the no-MSAA test passed.
• Python suite on macOS: 553 tests run, 49 skipped, no failures. Skipped tests are not counted as validated behavior.
• Generated the application and DMG. CI checked runtime library architectures, dependencies, package contents and code signatures.
• Downloaded the final DMG and independently verified its SHA-256 checksum.
• Windows integration: runtime built, nine focused native tests passed, Python suite passed (553 tests, 70 skipped). Follow-up runtime build and focused portability checks also passed.
• Package built from cab359ebb750bd502c233ad0aa72a46af5514f5c, the CI merge commit for PR head 76830ef10f99cf5ca26f0cd2e41a4ab83207ae5f. Their source trees match exactly. The source commit is recorded in the attached source-commit.txt.
• Build and test evidence: macOS workflow.
• Not run in game here on a Mac. That is what this build is for.

SHA-256: see spartanport-macos.dmg.sha256.

You still need your own copy of the game files. No game files are included.

SpartanPort 2.6.0

gow3_pc is now SpartanPort. Updating from 2.5.0 through the launcher keeps your saves and settings: on the first start, the game settings, the launcher settings and, on Linux, the data folder are copied to their new names, and the old files stay where they were. These notes cover the 9 pull requests merged since 2.5.0, through 8ad72a8 (#803), including the rename (#755) and the version bump to 2.6.0 (#800).

SpartanPort

• New name and icon (#755): the launcher, the executables, the game window (#803), the packages and the docs are now SpartanPort, with the SP monogram as icon. The Windows package is spartanport-windows.zip and the Linux one spartanport-x86_64.AppImage.
• Nothing to redo after the update (#755): game settings, launcher settings, saves, mods and the desktop shortcut carry over. Shortcuts and Steam entries that start Play God of War III.exe keep working, and variables set by hand with the old GOW3_ prefix still apply.
• Linux: the AppImage keeps its data in ~/.local/share/spartanport. The GPU caches stay in the old folder, so the first game after the update compiles its shaders again and can stutter for a while. Steam launch options that call the AppImage by its old file name need the new name.

Game

• Automatic QTE (#729): new option in the in-game menu (Game → Cheats), off by default and toggled live. Single presses, stick rotations, repeated and held presses and the Circle struggle answer themselves. The Circle presses in part of the Poseidon fight still need the player: they go through the move system, not a QTE.
• Polish is in the launcher's Game language list (#632).
• Shoulder-button prompts aligned (#638): the L1, L2, R1 and R2 prompts no longer sit on the bottom edge of their frame. Button prompt textures are redrawn the first time the game starts after the update.

Graphics and resolutions

• 8K is built in (#702): 7680 × 4320 in the render resolution list and the in-game graphics menu, marked beta, with no mod needed. Scene buffers use a single sample at 8K to leave room for textures, which fixes the crash at start.

Launcher

• Portable launcher settings (#628): settings.json now lives in the port folder, next to the game settings, instead of %APPDATA% or ~/.config. The old file is copied over once and left in place.

Documentation

• Website: the project now has its own site, spartanport.com, designed and built by @WilkPrintes (#801).

Requests addressed

These open requests are covered by the changes above and can be closed once players confirm them on 2.6.0: Polish as a game language (#493, via #632), shoulder-button prompts misaligned with the HUD frame (#581, via #638) and portable launcher settings (#561, via #628).

Known issues

Same as 2.5.0: see the 2.5.0 release notes. Also:

• 8K is beta. It was validated in one area on Windows; full-game stability, Linux and other hardware remain unverified, and its memory requirements are higher than 5120 × 2160.
• Automatic QTE leaves a prompt kind to the player when its code site is not found; the log says how many kinds are ready.

For a new or continuing problem, open an issue with the release version, operating system, GPU and driver, render resolution, game title ID/update version, reproduction steps and relevant log.

Validation

• Python suite on the rename branch: 531 tests run, 72 skipped, no failures. Skipped tests are not counted as validated behaviour.
• Rename (#755): update from 2.5.0 through the launcher on Windows, keeping saves, settings and the desktop shortcut; the Linux AppImage in game; tests that a 2.5.0 player keeps saves and launcher settings on Windows and on Linux, and that the Linux move leaves the GPU caches behind.
• Automatic QTE (#729): single presses, repeated Circle and L1+R1 presses and gates checked in game.
• 8K (#702): gameplay validated on Windows in the Tomb of Ares.
• Polish (#632), shoulder-button prompts (#638) and portable settings (#628): covered by their unit tests; not checked in game.
• Final packages built from 8ad72a81ef2fe0387d5339b0a5e97c1f5093f78a: the Windows ZIP workflow passed its clean-runner launcher smoke test without MSYS2. The Linux AppImage workflow passed launcher smoke tests on Debian 13, Fedora 42, Ubuntu 24.04, Arch Linux and openSUSE Tumbleweed. Both packages and their SHA-256 files are attached to this release.
• Downloaded the attached Windows ZIP and verified its SHA-256 checksum; it carries SpartanPort.exe, Play SpartanPort.exe and the former God of War III.exe and Play God of War III.exe the 2.5.0 updater and shortcuts look for.
• Final Windows package validated by the maintainer: the extracted release ZIP was opened on Windows 11 and the checklist passed: the SpartanPort name and icon in the launcher and the game window, version 2.6.0, launcher settings carried over from 2.5.0, 8K (beta) and Polish in their lists, the update check, launch and save loading, Automatic QTE, the shoulder-button prompts with Xbox icons, live frame-rate switching, Exit to Desktop and settings kept after reopening. This is a scoped manual check, not a full playthrough.
• No final-package Linux gameplay validation has been completed for 2.6.0.

Credits

Thanks to @Rajinder798 and @Invictus-potens for contributions included in this update, to @WilkPrintes for the website, and to the players who supplied reproductions, logs and in-game checks.

This project builds on the work of Supermedo/bloodborne_pc, deadinside28/bloodborne_pc and shadPS4.

Full changelog: 2.5.0 to 2.6.0

Test build issue209-test1 on 2.6.0: INSANE IMPROVEMENTS on low-end CPUs, up to 4x FPS (2.6.0-issue209-test1)

INSANE IMPROVEMENTS on low-end CPUs: up to 4x more FPS

i3-9100F class CPUs: from 19-32 FPS to 97-120 FPS. Dual cores: about 3x faster.

Test build for low-end CPUs (issue #209, also #148, #157, #191, #285, #319, #330, #333, #387). If your CPU sat at 100% while your GPU was nearly idle, and lowering the resolution did nothing, this build is for you.

What was wrong

The game spreads its work over 5 worker threads that wait for jobs with a busy spin lock. On a PS4 each of them has its own core, so that spin lasts nanoseconds. On a PC with 4 threads or fewer, Windows pauses the worker holding the lock and the other ones spin for their whole time slice. They took almost all the CPU, leaving the thread that feeds the GPU with about 17% of one core: CPU at 100%, GPU at 15%, 16 to 30 FPS.

What changes

• Worker threads run at a lower priority (below normal on Windows, nice +5 on Linux). They still get every idle cycle, but they can no longer starve the GPU thread and the game's main thread. No setting needed.
• Sound thread runs at a higher priority: the game's sound driver (and its file I/O threads) had a high priority on PS4 but ran at normal priority here. With 4 threads the sound output ran dry 113 times a minute on 2.6.0, with gaps up to 92 ms (crackles and stutters). Now: 0 times, gaps under 10 ms. On Linux the priority is only raised when the system allows it.
• CPU report per thread in last_run.log: when the game closes normally, the log lists the threads that used the most CPU (Runtime: CPU time by thread) and how often threads yielded while waiting. If you still have low FPS, this tells us where the time goes.
• Everything else is the 2.6.0 build. The launcher still shows v2.6.0 and does not offer this build as an update.

Measured results

Test machine: AMD Ryzen 5 5600X (6 cores / 12 threads) + Radeon RX 6700 XT, Windows 11. Each CPU below was simulated by limiting the game to the same number of cores and threads (Windows CPU affinity, set before the game starts). Same scene every time (Gaia's head, Poseidon fight area). "Before" is the 2.6.0 behaviour, "After" is this build, compared live in the same session. FPS read from the in-game overlay.

Simulated CPU	Cores / threads	Affinity	Before	After	Gain
Intel Core i3-9100F (also i5-7400, i5-6500, i5-4440, i5-3470)	4 / 4	0x55	19 to 32 FPS	97 to 120 FPS	about 4x
Intel Core i3-2100 / i3-3240	2 / 4	0xF	27 to 30 FPS	65 to 86 FPS	about 2.5x
AMD A4-5300 / Athlon X2 340	2 / 2	0x5	14 to 16 FPS	40 to 48 FPS	about 3x
AMD Ryzen 5 5600X (no limit)	6 / 12	all	133 to 150 FPS	133 to 160 FPS	no change
Single core	1 / 1	0x1	3 FPS	5 FPS	not playable

With 4 threads, GPU usage went from 18% to 60%, and the GPU thread from 37% to 66% of a core.

Frame time and sound with 4 threads (30 to 45 seconds each):

	2.6.0	This build
Frame time, 99th percentile	106 to 175 ms	37 ms
Frame time spread (standard deviation)	about 30 ms	about 6 ms
Sound ran dry	113 times per minute	0
Largest gap in the sound	92 ms	9 ms

Tip for weak CPUs: the CPU is still almost full, so some frames take 30 to 60 ms. Set the engine frame rate to 60 FPS in the launcher for a steadier picture.

Your numbers will be lower than these: the simulation uses fast Zen 3 cores, and older CPUs are slower per core. The gain should be in the same range. CPUs without MOVBE/BMI (Sandy and Ivy Bridge, like the i3-3240 and i5-3470) also pay for the instruction rewrite, which this build does not change.

Strong CPUs (6+ threads, like the Ryzen 5 5600G or 5700G in #157 and #333) see no change here: their limit is a different one, the single GPU command thread. That is the next step.

How to test

1. Extract spartanport-windows.zip over your current spartanport-windows folder (this keeps your saves, settings and shader cache).
2. Play as usual for at least 5 minutes, ideally a place where your FPS was low before.
3. Close the game from the in-game menu (not with Alt+F4 or Task Manager), so the CPU report is written.

Reply on #209 with: your CPU, GPU, resolution, FPS before and after (the in-game overlay shows it: Insert > Overlay), whether the sound stuttered, and user/last_run.log.

Validation so far

• Built on Windows 11 (MSYS2 CLANG64), full Python suite run on the development branch.
• Played on a Ryzen 5 5600X + RX 6700 XT limited to the CPUs in the table above, with live A/B of the old and new behaviour in the same scene.
• Sound and frame time measured with the game's own statistics (SPARTAN_AUDIO_STATS, SPARTAN_FRAME_STATS) at 4, 2 and 12 threads. With 2 threads the sound still ran dry 6 times in 30 seconds: the CPU is completely full there.
• Not checked yet: loading times and a real low-end CPU, and the Linux build (not compiled).

SHA-256: see spartanport-windows.zip.sha256.

You still need your own copy of the game files. No game files are included.

God of War III Remastered for PC 2.5.0

Windows and Linux packages have been built and passed their automated smoke tests. These notes cover the 26 pull requests merged since 2.4.1, through 5428f39 (#625), including the live engine frame rate (#622), the mods and patches guides (#623), and the version bump to 2.5.0. The final Windows package passed the maintainer's launcher and gameplay checklist on Windows 11 with an RX 6700 XT. Linux gameplay remains untested.

Controls

• Expanded keyboard and mouse controls (#351): bind mouse buttons and the wheel, configure Dodge and Grab, and activate Rage with one input. Rotation QTEs support keyboard inputs or mouse gestures. Mouse aiming supports sensitivity settings and Relative or Absolute right-stick behaviour. Saved bindings are preserved or migrated.
• Cursor capture follows the game (#351): mouse capture is released when pausing or losing focus and restored when returning to gameplay.
• In-game keyboard prompts follow your bindings (#471, #612): key labels, movement keys and weapon-selection keys reflect the configured controls. Automatic button icons use keyboard prompts when no controller is connected.
• Xbox and Nintendo controller diagrams in the pause menu (#234): the Controls screen now shows the matching controller drawing when using those button-icon styles. Enable In-game button icons and select the appropriate style in the launcher. The drawings ship with the project and are applied automatically; no separate mod download or installation is required. Keyboard and Original styles keep the PlayStation drawing. Gameplay and QTE button icons were already supported; this change completes the controller illustration.
• The launcher Controls page is organised by device, and Nintendo labels follow the physical button positions (#612).

Game

• Native Exit to Desktop (#462): the pause menu includes an exit entry with a Yes/No confirmation. It is also accessible through Options from the main menu. No external mod or overlay is needed. The exit label currently remains in English in every game language.
• Engine frame rate changes while the game runs (#622): Engine frame rate (60, 100, 120 or 240) moved to the Live section of the in-game menu and no longer needs a restart. R3 + L1 + R1 on the controller or F9 on the keyboard go through the list, with a short notice on screen; the three buttons are hidden from the game while held. This lets you drop to 60 FPS on the spot where a higher rate blocks progress (#114, #535) and go back afterwards. Every launch now takes the 240 FPS patch and writes the chosen rate into the game; the displayed frame rate never exceeds the engine rate, so game speed stays normal. The launcher keeps the same setting for the next start.
• 100 FPS option (#506): both the engine frame rate and frame-rate limit now offer 100 FPS, suitable for 100 Hz displays. Normal game speed was confirmed in game.

Graphics and resolutions

• 900p is built in: 1600 × 900 (#511).
• More display sizes (#521): 1280 × 800, 1440 × 900, 1360 × 768, 1280 × 960, 1440 × 1080, 1920 × 1440, 2048 × 1536, 2560 × 1920 and 5120 × 2160. No external resolution mod is needed. The 4:3 patches also correct the unwanted letterboxing.
• 1280 × 800, 1440 × 900, 1360 × 768 and 1280 × 960 have in-game confirmation and are no longer marked beta. The other new sizes remain beta. Existing beta sizes retain their labels.
• Aspect-ratio filter on Home and Performance (#618): narrow the resolution list to your display shape. If the current size is outside the selected group, the launcher selects the closest available size.
• Correct brightness at lower resolutions (#613): corrected the half-resolution postprocessing buffers used at 480p, 720p and 900p. This fixes the excessive brightness reported at 480p (#390). It does not resolve every GPU-specific lighting issue listed below.
• The game window initially matches the selected render resolution and fits the usable desktop when the requested size is too large (#470).
• Added a guard against empty shader input in the recompiler (#398). This handles one invalid-input case; it is not a general fix for shader or GPU crashes.

Requests addressed

These open requests are covered by the changes above and can be closed once players confirm them on 2.5.0: keyboard & mouse controls with mouse buttons, a Dodge key and one-key Rage (#350, #518, via #351), keyboard prompts in game (#207, #486, via #471 and #612), a way to close the game from its own menu (#161, via #462), and the Diagnostics panel overlapping the Log (#236, via #559).

Mods

Mods replace textures, models, sounds, text and videos without touching your game folder. The full guide is in docs/MODS.md, and game patches have their own guide in docs/PATCHES.md (#623).

• Dedicated Mods page (#597): mods moved out of the Game page into their own page, with:
  • Load mods, a master switch that also turns off the mods' game patches;
  • Load order with a checkbox per mod and arrows to reorder; the lower mod in the list wins a file that two mods replace, and a counter shows how many are active;
  • Conflicts: a warning under the list when more than one active mod replaces the same file, a ⚠ beside each mod involved and Details with every disputed file and the order of the mods (the last one wins; mods are never merged inside one file);
  • A details panel for the selected mod: picture, name, author, version, description, number of files, whether it carries game patches, its conflicts, and buttons to open its folder and website;
  • Presets (Save, Load, Delete) for the order and the enabled mods, kept in mods_presets.json; mods that no longer exist are skipped and new ones are added at the end;
  • Third-party patches and the mods and patches folders on the same page.
• Mod details from the mod itself (#597): an optional mod.json (name, author, version, description, url) and a preview.png or .jpg beside EXEC/. Without them the launcher uses the folder name, the start of a readme and the first picture in the folder. Links only open when they start with http:// or https://.
• Mods laid out as the game is (#595): EXEC/... and the language folders (ENGLISH/, PORTUGUESE/ and the others) at the top of the mod folder, as well as dvdroot_ps4/EXEC/... (shadPS4), app0/EXEC/... and one wrapper folder around either (an archive extracted into a folder of its own name). eboot.bin, sce_module and sce_sys are always refused. This addresses the layouts reported in #473 and #574.
• Regional and disc layouts (#234): data folders found in the selected game's root (for example JAPANESE/ in an Asian release) are accepted for that game only, so a mapping learned from another installation never leaks into its mods.
• Network-share compatibility (#507): game, update and mod overlays fall back to real directories with hard links or copies when an SMB share allows neither symlinks nor junctions. Source game files are preserved.
• Packaged launcher support (#234): the mod loader is read from disk, so the frozen launcher uses the shipped loader.
  Unchanged but worth knowing: a .zip dropped into the mods folder is still unpacked automatically (unsafe paths, links and more than 16 GiB unpacked are refused; 7z and RAR must be extracted first), and the log still lists which mod won each disputed file (Mods: EXEC/...: A -> B) and the total (Mods: 12 game files replaced, 0 added; 0 game files replaced usually means the paths inside the mod are wrong).

Mods are layered through a mod-game-* view that is removed when the game exits. If one is left behind after a crash, it points into your game folder: do not delete it with tools that follow links (such as rm -rf in Git Bash or WSL).

Documentation

• Mods guide rewritten (#623) in English, with Portuguese and Spanish versions: what each game folder holds and whether a mod can replace it, which WAD holds what, examples, common problems, every mod.json field, presets, how mods are applied and a section on sharing mods and copyright, with screenshots of the Mods page.
• New patches guide (#623) in the same three languages: the built-in patches and who turns them on, what happens at start, how to read the log, why a patch does not apply, the XML format with signatures and targets, patches in mods and third-party patches.

Launcher

• HiDPI scaling (#584): Auto, 1x and 2x GUI scaling, with text, icons and spacing adjusted together.
• More reliable save-backup retention (#550): backups created within the same second are ordered correctly, preserving the newest backups.
• Support for valid unpacked PS4 ELF files during game preparation (#552), alongside existing SELF support. Invalid, incomplete or unsupported game files can still fail preparation.
• Logging continues when the launcher closes its window after starting the game (#554): hiding the window keeps the output reader alive. The original packaged-build report still needs confirmation with the final release package.
• Diagnostics expand above the Log without overlapping it (#559).
• Game artwork falls back to the base game when a separate update contains no artwork (#553).
• Completed the Spanish launcher translation (#612).

Linux

• Updated Steam/AppImage troubleshooting (#558), including use of the host/default runtime when Steam Linux Runtime fails to launch the native AppImage. The native AppImage should not be run through Proton.
• The current AppImage build targets Ubuntu 24.04 / glibc 2.39 or newer. The 2.5.0 AppImage passed launcher smoke tests on Debian 13, Fedora 42, Ubuntu 24.04, Arch Linux and openSUSE Tumbleweed. Linux gameplay validation is still pending.

Known issues

The reports below ...