Repository navigation
Installation and Boot
Install KytyPS5 on Windows and add your own legally obtained Demon’s Souls PS5 game copy. See Testing and Known Issues for the current version and tested progress.
- Open KytyPS5-v20261013 and download KytyPS5-v20261013.zip and SHA256SUMS.txt. Earlier previews remain available on the releases page.
- Compare the ZIP’s SHA256 with its entry in SHA256SUMS.txt:
Get-FileHash ".\KytyPS5-v20261013.zip" -Algorithm SHA256- Extract the complete ZIP into a short, writable folder whose name has no
[or](the scripts stop in such a folder). Keep its executables, DLLs, Qt plugins, scripts, profile and license notices together. Launch from the extracted folder. - Install the x64 Microsoft Visual C++ v14 Redistributable if needed, including for missing MSVCP140.dll or VCRUNTIME140.dll errors.
The package requires Windows x64, an x86-64-v3 CPU with AVX2, FMA and BMI2, and a Vulkan-capable graphics driver. Tested hardware is listed on the game page; that hardware record is separate from minimum requirements. No game, system software, keys, saves, extracted shaders or driver caches are included.
Install Git, CMake 3.22.1 or newer, Ninja, Python 3, the Vulkan SDK, and Visual Studio 2022 or Build Tools with Desktop development with C++ and C++ Clang tools for Windows. Use clang-cl, rather than cl.exe. The Qt launcher requires Qt 6.10.3, MSVC 2022 64-bit, with Concurrent, Network, Svg and Widgets. Put glslangValidator on PATH.
Open Developer PowerShell for VS 2022 with an x64 environment, then clone the tagged source and initialize dependencies:
git -c core.autocrlf=false clone https://github.com/modhollow/KytyPS5.git
Set-Location .\KytyPS5
git checkout --detach v20261013
git submodule update --init --recursive
$qtPrefix = Read-Host "Qt 6.10.3 MSVC 2022 64-bit installation directory"
cmake -S . -B _Build/windows -G Ninja -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=clang-cl -DCMAKE_CXX_COMPILER=clang-cl -DCMAKE_PREFIX_PATH="$qtPrefix" -DKYTY_MARCH=x86-64-v3 -DKYTY_BUILD_ORIGIN=Fork -DKYTY_BUILD_REPOSITORY=modhollow/KytyPS5
cmake --build _Build/windows --target kyty_emulator launcher kyty_shader_precompile
cmake --install _Build/windows --prefix _Build/windows/installThe core.autocrlf=false clone keeps the source line endings the release used. The shader-cache identity is computed from source files, so a checkout with Windows line endings gives a different identity, and that build will not reuse the release’s caches.
Continue only when each command succeeds. Configuration downloads dependency inputs. The installed Qt application and runtime libraries are under _Build/windows/install; the separately built preparation tool is under _Build/windows. Source build scripts and their defaults are documented in the tagged README. The release’s corresponding-source archive supplies the complete implementation, pinned dependency sources and notices for redistribution.
Keep the complete original game tree outside the source and application folders. The directory selected as the game must directly contain eboot.bin and sce_sys, alongside all other original files:
DemonsSouls/
eboot.bin
sce_sys/
... remaining original game files and directories ...
A supported ZArchive .zar dump can also be selected; its archive root must contain eboot.bin. It is distinct from the ZIP containing the emulator. Preserve original saves and caches when trying a new version. The recorded test uses PPSA01341 version 01.007.000; see platform and game coverage before assuming another version works.
For the supplied package, double-click launcher.cmd. It opens launcher.ps1 using the factory launcher-settings.json. Select the game directory, resolution and language, then click Play. Play invokes run-windows.ps1 with the editable launch.json profile.
From KytyPS5-v20261013, launcher.cmd also works when started from a PowerShell 7 window. For preview 1 and preview 2, start it from Explorer; started inside PowerShell 7 they can fail at Play with "Get-FileHash is not recognized" (see the script-launcher limitation).
| Setting | Package starting value |
|---|---|
| Requested game window | 1920×1080 fullscreen |
| Shader preparation | On-demand recording |
| Ahead-of-time prefetch | Disabled |
| Preparation workers | 4 |
| Controller vibration intensity | 100 |
| Game culling setting | doIndexBufferCulling=false |
| Game fog | fog_enable=false |
Choose resolution before launching. The game window’s tested display behavior is recorded under Known Issues. Fog changes the image; edit its KYTY_GAME_CONVARS entry in launch.json if desired. No performance benefit from these overrides is established.
The Precompile shaders button starts optional offline preparation through precompile-windows.ps1. From KytyPS5-v20261013 the precompile can also be run for a fixed time and continued later; see precompile time budget. On first use, Play may still list shaders, create seed metadata and prepare static inputs. On-demand mode skips full offline pipeline preparation; it does not remove every first-use step. Complete first-use duration has not been measured for this package. Follow the preparation explanation and the tested limitations.
The separate Qt launcher.exe scans game folders in its global settings. Add the folder containing your dump, select the detected game, set the game options and launch. For a source build, open _Build/windows/install/launcher.exe. Qt settings and direct-emulator settings are separate from the PowerShell launch profile.
Open PowerShell in the extracted package folder:
$gamePath = Read-Host "Demon's Souls game directory or .zar path"
powershell -NoProfile -ExecutionPolicy Bypass -File .\run-windows.ps1 -Game "$gamePath" -Width 1280 -Height 720 -Set 'KYTY_SHADER_WARMUP=record,KYTY_SHADER_PREFETCH=0' -FollowThis uses the supplied launch.json profile. In a source checkout, run-windows.ps1 instead finds the source build and its separate run-windows.json defaults. A direct emulator command bypasses the script’s preparation and dialogs:
$gamePath = Read-Host "Demon's Souls game directory or .zar path"
.\kyty_emulator.exe --game "$gamePath" --screen-width 1280 --screen-height 720
.\kyty_emulator.exe --helpFor a source build, use _Build/windows/install/kyty_emulator.exe. Inspect the help for your actual version; the tagged parser defines the supported options.
| Symptom | Check |
|---|---|
| Missing DLL or Qt platform plugin | Extract the complete ZIP; install x64 MSVC v14; keep Qt plugins with launcher.exe |
| Game absent from Qt launcher | Rescan the chosen parent folder; the game or archive root must contain eboot.bin |
| Invalid game path | Enter the existing game directory or .zar file; quote paths containing spaces |
| Build/configure error | Check the x64 developer environment, clang-cl, Vulkan SDK/glslangValidator and Qt prefix/modules |
| Graphics initialization failure | Check Vulkan support and driver; include hardware and driver in a report |
| Long first-use or loading pauses | Distinguish script input preparation from GPU pipeline compilation; see Known Issues |
| Black screen or incorrect rendering | Record location, actions and diagnostic messages; no universal workaround is established |
Use the issue chooser and the report template, with personal information removed. Do not attach game, shader, save or cache payloads.
Close the emulator, back up settings and saves, preserve the old complete package, and extract each update into a separate short writable folder. Read its version notes and verify its checksums. Replace the complete application rather than mixing executables and libraries from different releases.
KytyPS5-v20261013 and earlier packages keep saves in the package's _SaveData folder and shader caches in _PipelineCache: to keep them, copy both folders from the old package into the new one before its first start. A development change that is not released yet keeps them instead in %LOCALAPPDATA%\KytyPS5\SaveData and PipelineCache, which every later build uses without copying; its first start copies a package's own _SaveData and _PipelineCache there, and the launcher's "Import from a previous build..." brings in another build's folder (see the revision history).
The pipeline cache implementation identifies source/producer, device and driver state. Reuse depends on the actual cache type and identity checks. Do not rename or alter metadata to make another build accept it. Loaded bytes and entry counts do not prove successful reuse during a scene.
The Windows scripts support an isolated CacheRoot; keep paths short and writable, preserve originals, and use the options documented for the executable you have. A short-folder recovery in an older experiment is not a permanent long-path fix. Full prepared coverage, compatible-update reuse and warm-restart benefits need measurements for the actual version. See cache reporting.
Chen's release notes give the following approximate preparation times. These are reports from another fork, not measurements of this fork's public source or the unfinished local evaluation:
| External release | Reported at 22 CPU threads | Reported at 8 CPU threads |
|---|---|---|
| v20261010 | 45 minutes | 2 hours |
| v20261010b | 55 minutes | 2.5 hours |
The later release also reports broader indirect-draw vertex and recorded-specialization preparation. Different coverage, source versions, graphics drivers and existing caches can change the amount of work. The release notes' CPU-thread counts do not specify a complete worker configuration. These figures therefore do not establish a matched comparison, a local completion estimate or a measured scheduling improvement.
Preparing shader inputs does not finish every GPU-specific pipeline. As a general engine example, Unity documents build-time shader compilation separately from driver preparation at runtime, which can still cause a first-use stall. This does not describe Demon's Souls' proprietary engine.
Full preparation moves known work before gameplay. Preparing only a recorded scene or some inputs can shorten the initial wait while leaving compilation for later encounters. Background work also consumes resources: Epic's pipeline precaching documentation distinguishes complete pipeline readiness from shader-only readiness and tracks work that finishes too late. These are explanatory examples, not additional features established in this fork.
For a useful timing report, record the exact release, game version, GPU/driver, preparation scope, worker settings, cache reuse and completed wall time. Preserve compatible caches according to that build's documented identity checks. New states can still require compilation; no fixed duration, complete unseen-state coverage or gameplay frame rate is established here.
From KytyPS5-v20261013, the precompile can stop after a time budget and continue where it stopped on the next run. The shaders recorded play uses most are compiled first, so a short run covers the places visited most. From a fresh Windows PowerShell window in the complete extracted package folder:
$gamePath = Read-Host "Game folder or .zar file"
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\precompile-windows.ps1 -Game "$gamePath" -Minutes 15-RecordedOnly compiles only what recorded play uses (about 24 minutes on the test PC); without either option the whole precompile runs (about 1 h 27 min on the test PC). To continue a partial precompile at idle priority while the game runs, start the game with run-windows.ps1 -BackgroundPrecompile; what it finished is merged before the next start. Times depend on the CPU, GPU and driver; the results above are from one Ryzen 7 7800X3D / RTX 5080 PC. See the tested results.
Preview 2's Windows preparation script uses a reduced worker budget and enables EcoQoS by default. Windows can use EcoQoS to favor lower CPU frequencies or more efficient cores; Microsoft recommends it for work whose performance is not critical. See Windows power policy.
The existing -FullSpeed option uses all allowed CPUs and skips the script's
EcoQoS request. This also changes automatic worker counts, so it is not an
isolated power-policy comparison and does not guarantee a shorter preparation
time. It can increase CPU load and power use.
From a fresh Windows PowerShell window in the complete extracted package folder:
$gamePath = Read-Host "Game folder or .zar file"
powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\precompile-windows.ps1 -Game "$gamePath" -FullSpeedUse the power options supported by your version. Preserve original saves and caches; record the build, worker settings and shard logs for a comparison. See the preparation report and retry counters.
KytyPS5-v20261013 retains the bounded worker budget while making EcoQoS an
explicit -EcoQoS option; -FullSpeed overrides it. Preview 1 and preview 2
keep the earlier defaults.
The local binary-capture ordering experiment measured one preparation subset and its retries, with equal retained pipeline coverage verified by native merge and replay. It does not establish a complete precompile duration, cross-build upgrade safety or gameplay performance. The ordering is included in KytyPS5-v20261013. Use the script and power options documented for your actual version, and preserve original caches and saves when comparing preparation results.
Prepared inputs are tied to their producer and other compatibility checks. The checkout-format correction, included in KytyPS5-v20261013, preserves the established LF producer while making equivalent CRLF checkouts match it. Old inputs made with a divergent CRLF producer need regeneration for the corrected build. Keep the original data when comparing builds, and use the preparation instructions for your actual version. A matching producer alone does not prove compatibility with changed sources, devices or drivers.
The parallel compute variants experiment further reduced native-run time for one matched subset and all its retries with three workers, while native merge and empty-claims replay checked equal retained coverage. It does not establish complete-batch duration, single-worker speedup, warm-replay improvement or gameplay performance. It is included in KytyPS5-v20261013. Keep existing worker-budget limits and use the instructions for the version you actually run.
The larger compute modules first experiment also reduced measured time for one three-worker subset and its required retries, with equal native-validated retained coverage. It kept the worker budget and single-worker order and required no new setting. The lighter control was unchanged; complete-batch timing and gameplay performance remain unverified. This scheduling is included in KytyPS5-v20261013.
Prepared shader inputs and saved pipeline binaries have separate compatibility checks. The local regeneration and reuse check verified that a producer change required genuine input regeneration while compatible same-device binaries remained reusable. Use the preparation steps for the build you run and regenerate stale inputs; changing a cache header does not validate its contents. The local result does not establish that caches are portable between different GPUs, drivers or compiler outputs, and is not included in published previews.