PS5 & Switch 2 Emulation on PC in 2026 | How Far Have We Come?

Recorded results and project research · 6–7 November 2026

PS5 and Switch 2 emulation on PC are progressing through different projects and different routes. This result-led walkthrough follows recorded Ocarina of Time remake, Mario Kart World, Astro Bot and Demon’s Souls sessions, native Zelda ports, and the separate roles of DLSS and frame generation.

Console games, different routes

A PS5 adventure, a new Zelda remake, and Mario Kart World, all on a Windows desktop. These are recordings from the setups we have been testing. The exciting part is that there is no single trick behind them. Different projects are solving different pieces of the problem, and the results are starting to meet in the same place: games you can actually control on a PC. Let's follow that progress, see what changed, and work out where DLSS and frame generation really belong.

Three ways to reach the desktop

First, a small distinction that makes the whole story easier to follow. An emulator provides the environment a console game expects. A compatibility or translation layer supplies the system behaviour a program needs on another platform. A native recompilation prepares the game's code for the PC ahead of time. The boundaries can overlap inside a project, but the installation steps are not interchangeable. A Switch emulator, a PS5 relinker and a Zelda PC setup program are three different routes, even when their final windows all look like ordinary Windows games.

From a black world to Kokiri Forest

Ocarina of Time shows how quickly a useful result can emerge. In an earlier session, the title screen and menus worked, but the world itself was black. The hearts were still there. Changing the recorded session from Handheld to Docked brought the scene back, and Link could move through the room. That is a concrete fix with a visible result. Later recordings reach Kokiri Forest on updated builds. It is much more helpful to follow that chain than to treat every new version number as an entirely new emulator.

What the newer build changes

The build eighty-eight release describes work on GPU synchronization, cached bindings and shader pipelines. It also brings in a Dynamic FPS mod for this particular Zelda game. Those are changes to the route that produces the original game frames. The practical starting point is still a normal CPU clock, a supported game build, and a working graphics profile. Follow the release's own settings before experimenting with extra layers. We have a clear record of this build running, while its exact benefit still depends on the PC and the scene.

Look at movement, not just the title screen

What matters next is ordinary play. Can you leave the first room, move the camera, talk to a character and keep exploring? Here, those actions are visible. A working scene is a meaningful step beyond a boot logo, and a longer playable route is a step beyond one attractive screenshot. That is how I want to show progress in these videos: keep the actual controls and movement on screen, and let you judge what the recorded build can do. Here is a little of that first playable area at its original speed.

Mario Kart is a different practical test

Mario Kart World asks a different question. A race needs readable motion and responsive steering, not just a pretty still. Our Eglantine session starts with the game's recommended Vulkan profile, its shader settings, and a working controller. Only after a normal race works do we add the optional graphics tools. That order is useful across the scene: establish one clean baseline, save the working settings, and change one layer at a time. It turns an intimidating list of switches into a setup you can actually follow and return to.

The PS5 side of the story

On the PS5 side, KytyPS5 is another project making visible progress. Its repository describes a translation layer for Windows, Linux and macOS, with a Vulkan graphics path. In our Demon's Souls and Astro Bot recordings, the interesting part is not a claim about every PS5 title. It is the fact that these particular games get into controllable scenes. The footage has a date and a build behind it. New fixes can improve one title before another, so the project's game reports are the useful companion to the release page.

Astro Bot reaches actual play

Astro Bot makes that progress easy to recognise. In this recorded run, the opening gives way to the desert, then the game reaches Sky Garden. You can see movement, interaction and a rescued bot rather than only a launch screen. I am keeping those moments at normal recording speed. They show the specific route we tested; a different fork, update or graphics card should be checked against its own report. The useful question for your setup is simple: which combination gets your game to the next playable checkpoint?

AnyPS5 takes another route

AnyPS5 approaches the PC from a different direction. Its relinker prepares a console executable for the target system, and its library implementations provide the functions that program expects. That is why building from source, converting a game and launching the finished result are separate stages. A convenient front end can make those stages easier for a player, but the underlying project still determines which game features work. For a useful test, keep the source revision, the game version and the resulting log together. That gives the next developer something they can reproduce.

Why a percentage can fall while work moves forward

There is one number that deserves a better explanation: library coverage. AnyPS5 counts the functions the project currently knows about. When more functions are discovered and declared, the total gets bigger. That can reduce the percentage even while the implemented count continues to grow. It is a more complete map of the work, not proof that the previous work vanished. It is also not a completion meter for a particular game. Game reports and actual playable checkpoints tell us what that growing implementation means in practice.

Native Zelda ports change the installation

Breath of the Wild and Tears of the Kingdom add a third route to this story. The native projects use your game files to prepare a PC build. That changes the setup experience: instead of adding the game to an emulator library, you select the inputs required by that port and let its build process finish. Our recordings include a Breath of the Wild setup with both DLC packs recognised, and a separate Tears of the Kingdom installation. Keep the names separate. An update for one native project is not automatically an update for every other Zelda port.

The files are part of the setup

This is also where careful instructions save the most time. A base game, an update and DLC are not simply three folders to merge at random. In the Breath of the Wild recording, the DLC's outer folders need to sit beside the base-game folders in the expected layout. In the Tears of the Kingdom recording, the installer rejects a nonempty destination, and choosing a suitable empty destination resolves that step. Those are installation problems with direct answers. Show the error where it happens, make the correction, and continue from the working result.

Compilation is preparation, not gameplay

A native setup may spend time generating code, compiling and preparing shaders before the first launch. An emulator may build a shader cache while you load or play. Those waits look similar, but they are doing different jobs. In the edit, I shorten a passive progress bar and return to normal speed before showing the result. On your PC, allow the job to finish and preserve the useful cache. A recording that jumps past that wait should still make it clear what you are waiting for, rather than suggesting the game appeared instantly.

DLSS is more than one switch

Now we reach the graphics features that often get bundled into one promise. Super resolution reconstructs an image from a lower input resolution. Neural rendering changes the image's appearance through its processing stage. Frame generation creates additional presented frames. They can exist in a combined setup, but they do different jobs. NVIDIA's official DLSS support and a community mod installed through ReShade are also different routes. If a tutorial does not tell you which route it is using, an impressive image can leave you with no clear idea which setting you actually need.

What the community Manager adds

The community DLSS five Manager is useful because it brings several of those tools into one place. In our recordings, it targets the emulator's Windows executable and installs the Vulkan add-on route. ReShade then supplies the in-game interface. That is separate from the emulator itself, and separate again from the Manager's Live Flow frame-generation controls. Think of it as an optional graphics layer around a game that already works. You do not need to reinstall the game every time you want to test a different image-processing setting.

Make sure the effect is really processing

There is a useful lesson in our latest Zelda session. The effects were checked in ReShade, and the saved session log confirms successful neural processing. But the same log also revealed a motion-vector provider that needed correcting. The Feeder documentation recommends Lumenite Kernel as provider three, with Kernel above Feed in the effect order. A checked box is only the starting point. Check the active processing status, make the required provider selection, and then test camera movement. That is a stronger setup check than judging one stationary picture.

Frame generation happens after the base frames

Frame generation answers the motion question. The game first produces its normal frames; the generator adds output frames between them. A two-times setting does not mean that every part of the game's simulation suddenly runs twice as fast. It also does not remove the work needed to produce the original frames. That is why I start with a working game and a modest setting. In the recorded Live Flow profile, the generator is set to two times, with Auto game type and Quality Preset B. Its output has to be checked separately from the emulator counter.

Read both sides of the counter

Our Zelda frame-generation example is a good reason to keep both numbers visible. The captured status shows roughly nineteen input frames and thirty-six output frames. That is a useful observed result for that moment, with processing overhead included. It is not a measurement of stable native sixty. A higher output counter can make motion look more continuous, while the original game rate still affects response. If you want a better result, improve the base settings first, then decide whether the generated output is worth keeping on your display.

Choose the layer for your goal

This gives you a practical way to choose. If your game will not launch or the world is missing, solve the emulator or port problem first. If the game works and you want a different image, test the image-processing layer. If the base rate is usable and you want smoother presentation, test frame generation. Keep each test short and repeatable: the same view, the same movement and the same starting settings. You can enjoy the experimentation without losing the setup that was already working for you.

A complete setup is a sequence of checkpoints

For the installation videos, that becomes a simple sequence. Download the correct application package. Extract it completely. Prepare the personal files the project requires. Select the right game folder or installer inputs. Reach a playable checkpoint. Only then add the optional graphics tools, one at a time. Each checkpoint gives you a working place to return to. The full guides linked with this video show those steps with the actual errors and corrections, rather than asking you to copy a pile of unrelated settings and hope for the best.

Where the progress goes next

The reason to follow these projects is not one percentage or one dramatic FPS badge. It is the accumulation of specific improvements: a game gets past a blocker, a shader path renders correctly, a cache makes the next start easier, or another controller action works. Those changes turn an experiment into something more useful for players. The next release still needs testing, and a result on one machine still needs its context. But the progress already visible here gives us plenty to explore, explain and build better guides around.

Build and test together

If you are following one of these setups, tell me the game, project, build and graphics card you are using. That makes it much easier to compare a result or work out the next step. Join our Discord through the guide for PC setup help, build testing and useful reports. We are building a place where players can help each other follow this progress. The videos and written guides are linked below, so choose the route that matches your game and start from a working baseline.

Project links and resources

Use your own compatible game and personal console files. No game, firmware or keys are distributed here. Community graphics mods are independent of NVIDIA’s official game integrations. Source passages show the dated build used; a newer release can behave differently.

Credits: the linked project maintainers and contributors, Nintendo and the respective game creators. Gameplay recordings belong to this channel; external videos were studied as editorial references, not reused as footage.

Watch the full video on YouTube

Search This Blog

ItsOOGWAY