Hello yuz-ers! We have so much to talk about this month. From game fixes, input changes, and quality of life improvements, to new gameplay options available to everyone!
As promised in the previous progress report, and explained in its dedicated article, LDN support is here and available to all users! Enjoy pwning some noobs in your favourite games. But before we explain the how, let’s cover some theory.
The Nintendo Switch offers 4 methods for multiplayer gameplay:
Project London includes full support for LDN, with room hosting and joining, and revamps our LAN support to use the new LDN code in place.
Now, let’s get to the fun part: how to use it!
A user can launch the
Public Room Browser by selecting the
Multiplayer option in the Menu Bar and then selecting
Browse Public Game Lobby, or by clicking the status bar tip in the bottom right labeled
Not Connected. Click here to find a room!
From there, double-clicking a room will allow the user to join it. Keep in mind, the
Preferred Game is just a suggestion and there is no hard restriction on which games can be played in a room. Please keep this in mind when joining public lobbies and be courteous to your fellow yuz-ers! Any rooms that are user-hosted may enforce this by kicking players or locking their room.
Speaking of user-hosted rooms, the
Create Room option in the
Multiplayer menu allows users to host their own rooms, with custom player limits and optional password security.
Some ports need to be forwarded in the host’s router/modem configuration, so please follow our guide here.
Once a player joins a room, they can chat with other members, see the game they are running, and very importantly, the game versions other players are using. Most games tend to only work when all players run the same game update version, so remember to dump the latest from your Switch!
It’s not mandatory to join a room before starting a game in yuzu, but it is recommended. At the moment, only LAN supports connecting with real Switches. LDN is yuzu to yuzu only, but we’re working to include native Switch support for LDN sometime in the future.
So far, very few games have issues with LDN. Only
Super Mario Maker 2,
Mario Golf: Super Rush and
DRAGON BALL FighterZ have been reported as incompatible.
Any other local wireless compatible game should work fine, but don’t be shy to report any issues should you discover them.
One bit of info,
Super Smash Bros. Ultimate has a hardcoded 6 frames of delay when playing over LDN. This is supposedly to “help buffer” the latency expected from online and WiFi gameplay.
While the ideal solution is to play in local multiplayer with Parsec (no forced delay on local play), not everyone has good upload speeds to host, or is comfortable with giving remote access to their computer.
An alternative is available: run the game at 120 FPS, reducing the delay to only 3 frames instead. For this, all users in the room must do two things:
Open Mod Data Location, then place the folder of the compressed file in the location that yuzu opens.
Generaltab > set the
Limit Speed Percentto a blue enabled value (this means it’s a custom value, ignoring the default one) > change it to 200%.
Some GPU power is required to sustain 120 FPS, as such, our minimum hardware recommendations may not cut it (an RX 550 falls under 100 FPS in 1v1 fights), but modern low/mid-end hardware should be fine. Testing also shows that AMD Windows drivers can only reach framerates higher than 60 if the display supports it. We reported the issue to AMD, hopefully in the future this doesn’t force users to get high refresh rate monitors.
And that’s it! Join rooms, both in yuzu and in game, and fight! Or trade those Pokémon, your call. This endeavour was possible thanks to the ldn_mitm project who provided us a licence exemption, and the work done by Tobi and german77, along with the testers (your writer included) who never had so much fun crashing games in the name of progress.
After the Mainline release, Linux users reported that LDN rooms refused to work on some Linux distributions. The issue is in how the SSL package is distributed. toastUnlimited, taking reference from a previous pull request from Docteh, fixed the issue so now all supported operating systems can enjoy LDN.
Some users reported crashes when playing
While we implement the correction for it, make sure that a valid network device is selected in
Emulation > Configure… > System > Network > Network Interface.
The crash seems to happen when
None is set as the network interface.
NVIDIA OpenGL users may have seen some strange graphical glitches in games like
Dragon Quest Builders,
SNACK WORLD: THE DUNGEON CRAWL, and
Pixel Game Maker Series Werewolf Princess Kaguya due to an oversight in yuzu’s handling of the performance-enhancing
vonchenplus swooped in with a fix,
and these games now render as they should.
Dragon Quest Builders
SNACK WORLD: THE DUNGEON CRAWL
Pixel Game Maker Series Werewolf Princess Kaguya
Users may have noticed an intriguing square moon in
Live a Live.
This is caused by the texture cache not correctly synchronizing ASTC textures that the game is using to all layers, so vonchenplus added a workaround to avoid filling the extra invalid layers with an error colour,
which changes the moon back to the round shape we all love.
Not exactly a Red Moon, dood! (Live a Live)
Some systems, like Steam, don’t like yuzu’s behaviour of spawning a new process to check for working Vulkan support. toastUnlimited updated the Vulkan checker with a configuration option to, well, stop checking, allowing those systems to function the same as with older yuzu builds.
After three months of regression solving and the usual nasty delays,
Project Y.F.C. Part 1 is finally merged to Mainline!
You can find more information about it, as well as what’s expected in the near future for Part 2
One regression remains, for now.
It affects certain puzzles in the single player mode of
While Part 2 is in development, users affected by this problem should stick to
Mainline version 1190.
We mentioned last month about trying to push more aggressive
Staging Buffer values in order to benefit GPU users that can enable Resizable BAR/Smart Access Memory
While the option did get merged briefly with Mainline 1189, users quickly reported both big performance gains and losses, with no correlation to which GPU/CPUs were in use.
This change seems to be very platform specific, and the average tilts towards performance losses, so byte reverted it.
It’s been a while since Morph dabbled in graphics work.
.hack//G.U. Last Recode was unable to boot due to excessive vsync event calls.
Limiting the event to only once per display
.hack to finally boot and play.
The cleanup for
Xenoblade Chronicles 3 from last month continues this month with a new audio pull request
This fixed the audio desynchronization issue that some users were having during cutscenes.
Previously, Maide’s audio implementation sometimes had issues with the game audio producing samples too quickly for the host audio backend (SDL or Cubeb) to be able to play in time.
Now, if the game starts producing too many samples, it will be temporarily paused until the audio backend catches up.
Maide also implemented a relatively large cleanup of the audio system
and how it relates to pausing and shutdown.
Before Pull Request 8842,
the audio system had its own timer system for dealing with the backend that ran independently of yuzu’s timer system,
Now that the synchronization issues when doing this were fixed, Maide removed the custom timer system to now run everything through
CoreTiming, which correctly handles pausing and shutdown.
The scaffolding for the audio system to be aware of pausing and shutdown was therefore no longer needed, and could be deleted.
These audio changes did, however, come with a minor regression. In multi-core mode, timer callbacks are run on their own thread, which allows them to execute independently of the CPU cores. However, because yuzu tries to be deterministic in single-core mode, every timing callback and every emulated processor instruction in this mode is run from a single host thread. In single-core mode, this prevents the timer callbacks from being effectively paused, which causes the audio service to try to continuously pause the game to catch up. Maide worked around this issue by simply not pausing if single-core mode is enabled.
For once, Maide was not the only contributor to work on audio!
vonchenplus noticed that the new
HwOpus service, which is a service for optimized playback of Opus audio, didn’t implement any of the multi-stream functionality needed for
Dragon Quest X to boot.
He added one new function that the game needed,
GetWorkBufferSizeForMultiStreamEx, and the game booted.
yuzu is slowly but surely improving its ability to run homebrew applications.
So when the team discovered that the Ship of Harkinian homebrew (a PC port of
The Legend of Zelda: Ocarina of Time)
did not work correctly in yuzu, we were intrigued and tracked it down to a single missing service implementation.
german77 added support for the
which is used for loading fonts, and the game now boots and renders, with frame interpolation up to 60 fps working correctly.
Pure nostalgia, right click and enable audio (Ocarina of Time, Ship of Harkinian)
In the realm of our “other architecture” news, liushuyu modified yuzu’s CMake setup to be partly compatible with the ARM64 architecture.
This allows building the
yuzu-room LDN server application for ARM64.
Pi server, anyone?
Stay tuned for future news regarding yuzu on ARM64…
One of the longstanding issues with yuzu’s input emulation was motion controls not working after the controller reconnects. Thanks to german77, this has now been fixed. This was happening because yuzu was only checking for motion controls when the controller first connected, but not on subsequent reconnections. Ensuring that yuzu checked for motion controls on every reconnection resolved this issue.
Over the years, yuzu’s input emulation had been missing support for emulating the popular
Pokéball Plus controller.
In his efforts to reverse engineer this, german77 found that most meaningful features for it were locked behind Nintendo Switch Online (NSO).
Although this made him lose interest in it, he partially implemented support
for emulating this controller (including motion controls), thus opening it up for others to improve upon.
For now, you can select this in
Pokémon Let's Go, Pikachu/Eevee! and use it like any other controller, but loading data from it or writing data to it is NOT supported.
Last month’s Amiibo emulation support work also saw major improvements and bug fixes.
With these changes, Amiibo keys are now a mandatory requirement to read/write any data.
This also fixed Amiibo support in games like
Shovel Knight and
Super Smash Bros. Ultimate among others.
A minor bug within GameCube controller
input mapping which led to GC triggers overwriting the
ZL/ZR buttons was fixed.
And to further complement this fix, german77 also made analog input buttons toggleable
for extended usability.
Accessibility is both very important and, sadly, very easy to ignore too.
For example, something simple: what if a user needs more time to map buttons individually?
In an effort to help with this particular case, the button mapping timer duration
has been increased from
2.5 seconds to
We also had a variety of UI improvements from multiple contributors this month.
german77 modified the ordering of the input profiles saved in
Emulation > Configure... > Controls. They are now sorted by name.
While the colourful theme has been the default for a while, some icons remained in a “Default” theme directory. But as grabbing icons from other themes isn’t supported on linux, this was broken. Docteh fixed this by moving all the icons to the colourful theme.
Debug configuration tab was getting crowded, Docteh made it scrollable.
While this change also helps Windows users, Linux users will benefit the most from it
Docteh also fixed the broken help page hyperlink on the
TAS configuration window
For a long time, any yuzu bug reports from Windows users had to be manually reproduced and investigated by the team. Linux users had the option of providing stack traces, but there wasn’t an easy way for Windows users to provide similar debug info.
To overcome this, toastUnlimited implemented support to create Windows crash dumps within yuzu
This allows any layman on Windows to easily obtain a crash dump without jumping through various developer intended hoops.
But since this feature has a big performance impact, this was added behind an option in the
Debug settings for users to access.
You can find it in
Emulation > Configure… > General > Debug > Create Minidump After Crash.
Since the dumps use modern Windows SDK features, there’s a risk that this change can break compatibility with older Windows options. yuzu only officially supports Windows versions 10 1803 and newer. And Linux, of course. It’s faster than Windows.
Users started reporting crashes when booting up
Xenoblade Chronicles 3 on AMD Radeon GPUs running official AMD drivers (either the Windows driver, or the Linux amdvlk driver).
We’re investigating the amdvlk source code to find the reason, and already notified AMD with all the relevant information we have.
The cause seems to be improvements in Macro JIT’s accuracy. Testing has shown that even with older driver and yuzu versions, disabling the MacroJIT speedhack causes the official AMD Vulkan drivers to crash, so it sadly checks out that improving its accuracy gives the same result now.
Affected users can try running Mainline 1188, or just run the game using OpenGL. The Mesa RADV driver is unaffected.
We have merged the multithreaded ASTC CPU decoder mentioned last month, so we strongly recommend NVIDIA Maxwell and Pascal (GTX 745/750, 900, and 1000 series) users to disable ASTC decoding if you run the latest drivers.
You can find the option in
Emulation > Configure... > Graphics > Accelerate ASTC Texture Decoding, enabling this setting uses the GPU to decode, while disabling it uses the CPU instead.
As a bonus, now this option can be a performance boost on systems with very weak integrated GPUs, like old laptops with MX series Geforce hardware, or any Intel iGPU, where the CPU would do a faster job dealing with ASTC decoding. Testing has shown that Geforce MX 500 and Radeon Vega 7+ tier GPUs are slightly faster using the GPU for decoding.
On affected NVIDIA hardware, the performance decrease while decoding ASTC textures is minimal. Avoiding a crash, for example, when opening the map in
The Legend of Zelda games is arguably far more important.
Crashes caused by recent driver updates remain, but your writer continues to harass an NVIDIA driver developer daily (I only need to get into Intel to do the same to all three vendors now). This leads us to recommend the 472/473 series of drivers for Maxwell and Pascal hardware to ensure the best performance and compatibility with yuzu. There’s nothing wrong with using the latest drivers, but until these crashes are resolved, expect instabilities and graphical glitches with them. Turing, Ampere, and Ada hardware (1600, 2000, 3000, and 4000 series) exhibit some weird behaviour but are much more stable on the (at the time of writing) latest 520/522 series of drivers when compared to their older brothers.
One wonders how long Maxwell and Pascal will continue to be supported by NVIDIA drivers.
No news yet on Vulkan support for these new “AV1 video decoder cards” from Intel that can also work as a GPU. Low availability has made it difficult to get our hands on one, but it’s something we want to solve ASAP.
OpenGL is “functional” right now, but Intel continues to be the worst vendor regarding OpenGL support on Windows, so the experience is pretty bad. Linux Mesa drivers are reported to work correctly, and with good performance, in both OpenGL and Vulkan.
Speaking of AV1, for now we’ve been using h.264 encoding for the videos embedded in our articles, as it is both widely supported and very lightweight in regards to hardware requirements. Would you prefer if we switched to AV1 from now on? It can be a big battery drain on devices without dedicated hardware decoders, but it would allow for even lower bitrates while keeping a similar level of quality, something datacapped users have complained about in the past. Let us know on Reddit, our forums, or our Discord server what you would prefer!
For once, we don’t have much to say in this section. Or maybe I should say, we don’t want to start generating hype for new projects just yet.
Blinkhawk has started working on Part 2 of
Project Y.F.C., as previously mentioned, and the rest of the GPU gang (Byte, Maide, vonchenplus) is also busy with some top secret changes (for now, your writer has a reputation to uphold) to improve both rendering accuracy and performance.
Having the first part of
Y.F.C. merged to Mainline opens the floodgates to many projects that were on hold until now. We will discuss these in more detail in the next progress report.
Special thanks to Mysterious Writer B for their help with this progress report, and to CaptV0rt3x who came to aid at a moment’s notice.
That’s all folks! As always, many thanks for your time. We hope to see you in the next article!