Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/v5.6...v5.7

Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/v5.5...v5.6

Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/v5.4...v5.5

Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/v5.1...v5.4

Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/KytyPlus-2026-10-26-636bc95...KytyPlus-2026-10-26-e560633

Full Changelog: https://github.com/Coder787-source/KytyPlus/compare/v5.1...KytyPlus-2026-10-26-636bc95

KytyPlus v5.1

Two changes aimed at the same class of failure: running out of graphics memory, and a shader that a Mac driver simply refuses to build.

Making room for a large texture (issue #17)

• A cached texture is now evicted to fit a new one, instead of the allocation being refused. The periodic collector was gated on usage thresholds and freed at most 10, 20 or 40 images per pass, so a title asking for one big allocation at a scene transition could be refused while hundreds of stale textures sat in the cache. Inserting an image now checks what the device reports as free, and evicts least-recently-used textures until the request fits with headroom.
• The headroom is deliberate. The driver still needs memory for its own page tables and staging, so the target is not the last byte of the heap; aiming at that trades this failure for a worse one later in the same frame.
• The previous release could only trim buffers from this point, because image creation happens while the texture cache lock is held and calling the collector from there would have deadlocked. The eviction now runs where the lock is already held, which is what makes it possible at all.
• This is still containment. If nothing is reclaimable the run ends as before, and nothing here explains why memory fills up. On an 8 GB card a title that genuinely needs more will now thrash rather than abort, which gets further but is not a fix.

Apple Silicon: vertex shaders that use lane operations (issue #18)

• Metal cannot compile a subgroup operation into a vertex, tessellation or geometry function at all - not a missing feature, a hard refusal - and a Unity title on an M1 was dying at pipeline creation because the recompiler emitted gl_SubgroupInvocationID and friends there. Those stages now emit as a wave of one lane: the lane index is zero, a shuffle returns the value in hand, a ballot reports only the invoking lane, and the subgroup barrier is dropped.
• Pixel and compute shaders are unchanged, since Metal supports subgroups in both. Windows and Linux are unaffected by construction - the fallback is compiled in only for Apple.
• This is a degradation, not an emulation. A title that genuinely exchanges data between vertex invocations will render incorrectly where it used to stop running. That is the only option Metal leaves, and rendering something is the better failure.

Known issues

• Device-memory exhaustion is still the open problem. The vkQueueSubmit variant of it is not addressed by this release, and the eviction here has not been run against Demon's Souls - no copy of it is installed here, so the next report from that title is the real test.
• The upscaler options in the launcher currently do nothing. FSR method, quality and render scale are read from the configuration but have no call sites in the present path, so output is a single blit at the window size. Claims about upscaled resolutions should not be made yet.
• PS5 packages that are encrypted still cannot be installed, unchanged: retail package keys are not available, so only packages carrying the plain or debug marker get through.

KytyPlus v5.0

One fix, and it is a compatibility one: PS5 packages no longer abort during installation on titles whose filesystem metadata is not the last thing in the package.

Package installation (issue #20)

• Gran Turismo 7's package failed before listing a single file. The installer reported Invalid package range: offset=25FC1FD8031, length=3FFDC, total=1F27EE0000 — a read 2.6 TB past the end of a 134 GB package. The offset was never the problem; the position it came from was.
• How the position is chosen was the bug. The package layout lists one boundary per file, and the installer took the highest boundary that was 64 KiB-aligned and treated it as the start of the game's filesystem. That granularity is finer than the mount is served in: blocks are 256 KiB, so a boundary 128 KiB inside a block is a file tail, not a superblock. Decoding a file tail is what produced the impossible offset.
• The position is now proven by decoding it, not guessed. Candidates are required to sit on a real block boundary and are tried from the top down until one yields an actual PS5 filesystem superblock, which is the position every later read depends on. Up to 512 candidates are tried; each is a single block decode, so a package that resolves on the first candidate costs what it used to.
• Failures now say which record broke. A block address that lands outside the package reports the records that produced it — the run record, its raw bits, the gap and the accumulated offset — instead of a bare range check that cannot be compared between two packages. Running the extractor with KYTY_NAPS_TRACE=1 additionally reports the outer filesystem's flags, including whether a package is encrypted, and the layout header's table sizes.

Known issues

• This is verified not to regress the one PS5 package we can test here — it resolves at the same position on the first candidate and extracts every file — but Gran Turismo 7 itself has not been installed by us, and we will not ask anyone to send a dump. If a package's compressed-block addressing also breaks at that size, installation will now fail later, with a message that names the records, so the next report is actionable rather than a dead end.
• Encrypted PS5 packages still cannot be installed. That is unchanged and not fixable here: retail package keys are not available, so only packages that carry the plain or debug marker get past the outer filesystem.
• PS4 packages and .ffpfsc images do not use this code path at all, so neither is affected either way.

KytyPlus v4.9

Two follow-ups to last release: Apple Silicon no longer aborts during startup, and a refused texture allocation gets one more attempt before the run ends.

Apple Silicon startup (issue #18)

• v4.8 could not start on an M1 at all. Requiring the AGC driver DMEM at a fixed guest address was the right instinct but the wrong mechanism: macOS runs the x86_64 build under Rosetta, which reserves that range, so the mapping failed outright and the emulator aborted in driver startup before a single frame. Last release's MoltenVK fix had already gotten those machines as far as this, so v4.8 shipped a regression for them.
• The preferred address is now a preference, not a demand. It is requested as a fixed mapping first, and if the kernel cannot honor it the returned address is used instead — with the driver's binding table derived from wherever it actually landed rather than from the constant, which is what made the original assertion necessary in the first place. When that happens the log says so, naming both addresses.
• Windows is unaffected: verified there that the preferred address is still granted, so the addresses the driver writes are identical to before.

Texture allocation under memory pressure (issue #17)

• A refused image no longer ends the run on the first attempt. Demon's Souls was dying in vkCreateImage with ErrorOutOfDeviceMemory on a 2048x2048, 12-level BC1 texture — about 2.7 MB. A request that small failing means the device was already full, not that the request was unreasonable, so the buffer cache is now trimmed and the creation retried once.
• The buffer cache only, deliberately. Image creation happens while callers hold the texture cache lock, so evicting textures from there would have deadlocked instead of helping.
• This is containment, not a cure. If nothing is reclaimable the run still ends, and it does not explain why memory fills up in the first place.

Known issues

• Device-memory exhaustion remains the open problem, and it now spans titles: this same release window has seen it at image creation and at vkQueueSubmit. The retry paths log a heap dump when they trigger, so the next reports should show how close to budget these machines actually were.
• Apple Silicon startup past this point is unconfirmed by us — no one here has M1 hardware to test on, and block-compressed texture support is a likely next obstacle.

KytyPlus v4.8

The AGC driver no longer aborts during startup when the kernel puts its memory somewhere else — which is what stopped an Apple Silicon Mac once v4.7 had got it a Vulkan device.

Boot / Graphics5Driver

• The driver DMEM is now mapped at a fixed address. libagc asked for its 2 MB driver DMEM at a preferred address but passed no fixed flag, so the kernel was free to return any aligned free range — and the driver then asserted the address had come back exactly as requested. Windows and Linux happened to get the address they asked for; macOS did not, so every Apple Silicon launch aborted during startup. The mapping is now required rather than suggested, and if the address cannot be reserved the failure names both addresses instead of a bare condition.
• This is the first release to change how guest memory is mapped. The macOS and Linux builds compile clean on CI, but no one here has run it on Apple Silicon hardware.

Diagnostics

• A failed image allocation now says why. Image creation returned a boolean, so a title dying at failed to create image gave no way to tell device-memory exhaustion from a driver rejecting the create flags. The abort now carries the Vulkan result together with the usage, flags and sample count. This came out of the Demon's Souls (PPSA01341) reports, where a 4K RGBA16F render target failed to allocate after several hundred shaders had compiled.

Known issues

• Demon's Souls is not fixed. Its remaining failure is exactly that image allocation, and the logs reaching us are missing the heap-budget lines the emulator prints on every failure. If you can reproduce it, please attach the complete log rather than an excerpt — the next one is diagnosable, this one wasn't.
• Whether LEGO Voyagers (PPSA23732) now gets past the AGC abort on an M1 is unconfirmed: the fix was read out of the reporter's log, not off a Mac.

KytyPlus v4.7

An Apple Silicon Mac could not create a Vulkan device at all, so no game could start. That gate is gone.

MoltenVK device selection (issue #18)

• Every macOS device was being rejected before a game loaded. A reporter on an M1 got Could not find suitable device, naming four features: image view minLod, shaderBufferInt64Atomics, nullDescriptor and shaderCullDistance. These are not borderline cases — MoltenVK hard-codes nullDescriptor to false, reports shaderBufferInt64Atomics false, states maxCullDistances = 0 // unsupported, and exposes no VK_EXT_image_view_min_lod. Requiring them meant requiring something no Mac can answer, so the emulator never reached vkCreateDevice.
• Those capabilities are needed per shader, not per device. The SPIR-V emitter asks for the Int64Atomics capability only for shaders that perform 64-bit atomics, and CullDistance only for shaders that write gl_CullDistance. Selecting the device without them costs an individual shader at worst instead of the whole title.
• Null descriptors were never actually used. An unbound shader resource resolves to the shared dummy buffer, not to a null descriptor, so requiring that feature gained nothing.
• Image views fall back to the base mip level. VK_EXT_image_view_min_lod is now probed on macOS instead of required, and a view only carries a minimum-LOD parameter when the device can honour it. Windows and Linux still require it, so their behaviour is unchanged.
• vkCreateDevice is no longer asked for features the device reports as unsupported. The emulator requested nullDescriptor and shaderCullDistance unconditionally, which is invalid input for a device that does not have them. This is fixed on every platform, not just macOS.

Known issues

• Nobody on this project has Apple Silicon hardware. The macOS branches are compile-verified by CI, but not run on an M1 — if you filed #18, please retest and report the new log.
• A second gate may still stop some Macs. The device check also requires a block-compressed format to be usable as both a sampled image and a blit destination; Apple GPUs can sample BC, but may not offer that second use. If it fires, the log now names the format rather than a list of features.
• The macOS package is still x86_64-only, so Apple Silicon users run it through Rosetta.

KytyPlus v4.6

Games can now be launched straight out of a .zar archive, and a class of shader-descriptor aborts no longer kills the game.

ZArchive (.zar) loading, without extraction

• Load Game gained a "ZArchive game image (.zar)..." option. The archive is read in place: members are decompressed on demand through the emulator's archive!/member path namespace, so nothing is extracted, staged or copied to disk. The archive reader, the file layer and the guest /app0 mount already supported this — what was missing was --game routing and a launcher entry point.
• .zar files inside a configured game folder now appear in the list like .ffpfsc and .exfat images do, and Explorer's "Open with" and --open-image accept them.
• The mount-progress dialog no longer waits on an archive. That dialog is driven by markers printed by the external NAPS helper, which an in-process archive never emits; sharing one predicate between the two would have left it spinning forever on a .zar. Formats that need the helper are now tested separately from formats that merely launch.
• A .zar with no eboot.bin says so instead of failing later as an unclear missing-file error.

Crash fixes

• An unmapped shader buffer descriptor is now treated as unbound. A descriptor whose base address is not committed at all went through a clamp that reports a fatal error and aborts. Titles can legitimately hold a descriptor pointing into freed memory and never bind it to a shader stage; that now degrades to the same empty binding an explicitly-zero address already produced, with a capped log line. This is what killed Demon's Souls (PPSA01341, issues #16 and #17) before its intro cutscene — on Windows and on Fedora alike.

Compatibility table

• Astro Bot (PPSA21567) is now listed, at Ingame (broken).

Known issues

• The .zar path was verified against archives built for the purpose, not against a real game .zar; none was available to test with. The mechanism is exercised end-to-end, a shipped title in that container is not.
• The Demon's Souls fix has not been run against a dump locally — it rests on the reports in #16 and #17.
• Astro Bot reaches in game but is still not playable: frame rate is far from real-time on an iGPU, and the title can still exit on its own during a session.

KytyPlus v4.5

Astro Bot now boots, and controllers work properly in the launcher again.

Astro Bot (PPSA21567)

• Boots through to the title prompt. A shader descriptor read on an unbound handle was being treated as a live host pointer and faulted, killing the game before it could render. Unbound reads are now zero-filled, matching the existing policy for out-of-range offsets, so the game compiles its shaders and reaches "Press Any Button".
• Game artwork restored. Icons were being overwritten by a generic file icon after the real artwork was applied, so titles showed a name and serial but no art.
• Launcher options restored. Seven options were lost in the upstream merge — --hdr, --hide-cursor, --tessellation, --network-connected, --trophy-notifications, --sync-raw-image-buffers and --skip-notice-screen. Their absence is what made the launcher refuse to start games at all.

Controllers

• Gamepads can be mapped in Settings → Controls. The dialog was never handed the launcher's controller poller, so it always read "No controller connected" and the Gamepad tab could not capture a press. Keyboard and mouse were unaffected, which made this look like a controller-support problem rather than a wiring one.
• Controller detection no longer dies permanently after launching a game once. The poller was suspended when a game started and never resumed, so every later launch in the same session saw no pad. Suspension now follows the emulator process state, which also covers the image- and package-launch paths that previously skipped it entirely.

Known issues

• Astro Bot reaches in game but is not yet playable: frame rate is far from real-time, and the game still exits on its own after a little.

KytyPlus v4.4

Four KytyPS5 upstream syncs since v4.3, reconciled so that no KytyPlus feature was lost. This is the first release where the launcher actually starts games again.

Highlights

Cheats — remote catalog, Local/Remote dialog, .shn import, and a file picker Performance — reduced renderer synchronisation and allocation overhead DLC — add-on support plus mountable-content DLC with real content Astro Bot now boots — it previously aborted during shader compilation A large shader-accuracy batch from upstream

Cheats

Browse and import cheats from a remote catalog with per-title and per-version filtering; import to Local, tick the mods you want, Apply. .shn (ShenJS trainer XML) is now supported — converted automatically into the mods plan, so the emulator only ever sees one format. New Select file... button on the Local tab loads a cheat file from anywhere: it validates, converts, and installs it as _Patches<TITLE_ID>.json. .mc4 files are published encrypted upstream and are not supported.

Games and content

Add-on (DLC) support (#1519) and mountable-content DLC with real content (#1581). Trophy notifications localised via embedded JSON catalogs; toast duration configurable 5–10 s (#1538). snd0.at9 plays during the startup splash screen (#1545). NGS2 lock/unlock implemented; vectored writes for profile index saves; path-based truncate for replay files.

Performance

Reduced synchronisation and allocation overhead in the renderer. Fixed-refresh VRR status reporting and entitlement requests ported. Verified pattern-fill recognition added to the shader recompiler.

Shader and loader accuracy

Float inline constants read at the correct width on 16-bit and 64-bit operands (#1582, #1576); quiet-NaN payload bits kept out of the packed f16 min/max sNaN path (#1579); f32 clamp turns NaN into 0. DS_CMPST_RTN_B32 returning a 32-bit LDS compare-exchange (#1578); 64-bit buffer atomic add BUFFER_ATOMIC_ADD_X2; native half conversion for v_cvt_pkrtz_f16_f32 (GTA V) (#1520); front-face input format honoured; RDNA2 DLC coherence preserved for flat address loads. Loader keeps the caller's flags in TLS stubs (#1571) and preserves game output and log across LoadExec relaunches (#1480).

Stability fixes

The launcher launches games again. Seven flags it emits (--hdr, --hide-cursor, --tessellation, --network-connected, --sync-raw-image-buffers, --trophy-notifications, --skip-notice-screen) were not parsed, so every start exited immediately on unknown option while the launcher still reported success. Astro Bot (PPSA21567) boots past its TileBasedLighting compute shader: unbound SRT descriptor reads are now zeroed instead of faulting. Restored five network entry points and the Usbd / WebBrowserDialog export tables, which had silently stopped registering. macOS builds again — the floating-point std::from_chars overload is unavailable below macOS 26, so argument parsing uses a validated strtof path. Restored KernelHandleReservedRangeAccessViolation and repaired merged CMake configuration and Linux SDL dependencies.

Build and CI

Test executables are no longer compiled or run in CI, which removes a large slice of every job. shadPS4 is bundled from the latest upstream prebuilt release rather than compiled from source.

Known issues

Astro Bot reaches its splash screen but then stalls on a guest thread wait, so it is not playable yet. .mc4 cheats unsupported. Upstream's --amd-cpu instruction patching is not wired into the KytyPlus loader path.

KytyPlus v4.3 Release Notes

KytyPlus v4.3 collects launcher compatibility, Vulkan shader, and Windows path-handling fixes made since v4.1. These changes improve specific code paths and do not imply a broad increase in game compatibility.

What’s new

Vulkan layer-output shader compatibility

• Layer-output shaders now use the core SPIR-V ShaderLayer capability enabled by the Vulkan feature set, rather than the unenabled SPV_EXT_shader_viewport_index_layer extension.
• Layer-output shaders use SPIR-V 1.5 and include their live descriptor and push-constant variables in the entry-point interface. Shaders without layer output retain SPIR-V 1.3.
• Added regression coverage for SPIR-V validation and Vulkan pipeline creation.

Launcher and CLI configuration compatibility

• Legacy launcher configurations can disable FSR without failing because of inherited default output dimensions.
• Explicit FSR output dimensions remain validated, and invalid or incomplete dimensions are rejected.
• Fixed successful launcher process starts being reported with Qt’s misleading “Unknown error” text.
• Added emulator CLI regressions for the discussion #15 argument combination and FSR option ordering/validation.

Windows Unicode game paths

• Mounting and resolving game paths now consistently convert UTF-8 strings to native filesystem paths on Windows.
• Windows file enumeration and directory operations preserve non-ASCII names, including paths containing characters such as an en dash.
• Added regression coverage for Unicode mount paths, guest filenames, directory opens, and file reads.

Compatibility data

• Updated Dead Cells (PPSA-15554) to Playable, last tested with v4.1.

Limitations

• The shader change has focused validation and regression coverage; it is not a guarantee that every game or graphics driver is compatible.