Fix links from yuzu-emu.org to yuzu-mirror.github.io
This commit is contained in:
parent
ff606a874b
commit
993e596072
43 changed files with 103 additions and 103 deletions
|
@ -20,7 +20,7 @@
|
|||
<h1>Site is temporarily unavailable.</h1>
|
||||
<p>Scheduled maintenance is currently in progress. Please check back soon.</p>
|
||||
<p>We apologize for any inconvenience.</p>
|
||||
<p id="signature">— <i>Team behind <a href="https://citra-emu.org">Citra</a> and <a href="https://yuzu-emu.org">yuzu</a></i></p>
|
||||
<p id="signature">— <i>Team behind <a href="https://citra-emu.org">Citra</a> and <a href="https://yuzu-mirror.github.io">yuzu</a></i></p>
|
||||
</article>
|
||||
</body>
|
||||
</html>
|
|
@ -18,7 +18,7 @@ Please download and install the dependency from below.</p>
|
|||
|
||||
The installer will allow you to download your preferred release channel.
|
||||
|
||||
If you are a Patreon subscriber, the "Early Access" channel will be available to you, and will provide early access to exciting experimental changes on top of what is available in the main channel. Please follow our [Early Access guide](https://yuzu-emu.org/help/early-access/) for assistance linking your Patreon account.
|
||||
If you are a Patreon subscriber, the "Early Access" channel will be available to you, and will provide early access to exciting experimental changes on top of what is available in the main channel. Please follow our [Early Access guide](https://yuzu-mirror.github.io/help/early-access/) for assistance linking your Patreon account.
|
||||
|
||||
Intel and AMD users are strongly recommended to switch to Vulkan by going to `Emulation > Configure > Graphics > API`. Latest GPU drivers are recommended.
|
||||
</div>
|
||||
|
|
|
@ -12,7 +12,7 @@ A major milestone in yuzu has been reached, as it can now boot a handful of the
|
|||
{{< youtube 1VzyIHMTA2Q >}}
|
||||
</div>
|
||||
|
||||
These changes are now available in the latest [yuzu canary builds](https://yuzu-emu.org/downloads/)!
|
||||
These changes are now available in the latest [yuzu canary builds](https://yuzu-mirror.github.io/downloads/)!
|
||||
|
||||
Currently, only a few games are confirmed to boot, including:
|
||||
|
||||
|
|
|
@ -47,7 +47,7 @@ We will be working to polish this feature and make this available to the Mainlin
|
|||
|
||||
<article class="message has-text-weight-semibold"><div class="message-body"><p>
|
||||
If you're using the yuzu installer, you'll automatically be updated to the latest build.<br>
|
||||
If you're <b>not</b> using the yuzu installer, please download it from our <a href= https://yuzu-emu.org/downloads/>Download</a> page. <br>
|
||||
If you're <b>not</b> using the yuzu installer, please download it from our <a href= https://yuzu-mirror.github.io/downloads/>Download</a> page. <br>
|
||||
<br>
|
||||
We highly recommend using our installer to always stay up to date on both Mainline and Early Access builds.
|
||||
</p></div></article>
|
||||
|
@ -97,7 +97,7 @@ Please respect the `Preferred Game` listed in publicly hosted rooms, as even unr
|
|||
You can use these rooms for LAN mode games as well — instead of ZeroTier or Hamachi.</b>
|
||||
</p></div></article>
|
||||
|
||||
Please visit [our multiplayer guide](https://yuzu-emu.org/help/feature/multiplayer/) for further help with Hosting, Port Forwarding, Authentication, and Moderation of your publicly hosted rooms.
|
||||
Please visit [our multiplayer guide](https://yuzu-mirror.github.io/help/feature/multiplayer/) for further help with Hosting, Port Forwarding, Authentication, and Moderation of your publicly hosted rooms.
|
||||
|
||||
## Development
|
||||
|
||||
|
|
|
@ -278,7 +278,7 @@ The Button and Stick placements can be adjusted here as well.
|
|||
|
||||
# Setup guide
|
||||
|
||||
If you need help setting up yuzu, our [Quickstart Guide](https://yuzu-emu.org/help/quickstart/) will provide all the steps required to get up and running.
|
||||
If you need help setting up yuzu, our [Quickstart Guide](https://yuzu-mirror.github.io/help/quickstart/) will provide all the steps required to get up and running.
|
||||
All the same requirements apply, including having a PC and the mandatory hacked Nintendo Switch.
|
||||
The yuzu on Android onboarding process will have you select the location of your `prod.keys` file.
|
||||
|
||||
|
|
|
@ -97,7 +97,7 @@ The error applet is used by games to crash and report back error codes to the us
|
|||
|
||||
# Fin
|
||||
|
||||
Both the new keyboard applet and the controller friendly error applet are now available in the [latest Early Access build](https://yuzu-emu.org/help/early-access/).
|
||||
Both the new keyboard applet and the controller friendly error applet are now available in the [latest Early Access build](https://yuzu-mirror.github.io/help/early-access/).
|
||||
Since these are currently still under development, we would like to hear more about your experiences and any bugs/issues you might encounter.
|
||||
Please don't hesitate to reach out to us on our Discord server's Patreon support channels to report any findings.
|
||||
That's all we have for today but, we're sure to be back with more exciting news soon!
|
||||
|
|
|
@ -49,7 +49,7 @@ This approach was necessary, because of how yuzu was initially designed.
|
|||
Originally, yuzu's memory reads were `reactive` — meaning textures were downloaded only when games tried to read them and hence it wasn't possible to know which textures were going to be downloaded.
|
||||
|
||||
Although these memory reads were fixed a few months later, the Scaler still needed changes to be made to the management of uniform buffers, so that it would be supported on drivers other than Nvidia.
|
||||
However, the planned rewrites of the [**Texture Cache**](https://yuzu-emu.org/entry/yuzu-tcr/), [**Buffer Cache**](https://yuzu-emu.org/entry/yuzu-bcr/), and the massive GPU emulation overhaul with [**Project Hades**](https://yuzu-emu.org/entry/yuzu-hades/) further delayed developers from working on the Scaler, resulting in it never getting merged.
|
||||
However, the planned rewrites of the [**Texture Cache**](https://yuzu-mirror.github.io/entry/yuzu-tcr/), [**Buffer Cache**](https://yuzu-mirror.github.io/entry/yuzu-bcr/), and the massive GPU emulation overhaul with [**Project Hades**](https://yuzu-mirror.github.io/entry/yuzu-hades/) further delayed developers from working on the Scaler, resulting in it never getting merged.
|
||||
|
||||
|
||||
{{< single-title-imgs
|
||||
|
|
|
@ -6,7 +6,7 @@ coauthor = "GoldenX86"
|
|||
forum = 348059
|
||||
+++
|
||||
|
||||
Hey there, yuz-ers! The follow-up to our [previous big code rewrite](https://yuzu-emu.org/entry/yuzu-tcr/) is finally here: the Buffer Cache Rewrite!
|
||||
Hey there, yuz-ers! The follow-up to our [previous big code rewrite](https://yuzu-mirror.github.io/entry/yuzu-tcr/) is finally here: the Buffer Cache Rewrite!
|
||||
This massive undertaking not only improves performance significantly, but also simplifies the code for our developers.
|
||||
Now let's get this article started!
|
||||
|
||||
|
@ -112,7 +112,7 @@ As a special mention, AMD Vega based integrated GPUs show an up to 223% increase
|
|||
## Fin
|
||||
|
||||
With that, we conclude our coverage of the new Buffer Cache Rewrite.
|
||||
As always, we would like to remind users that the features released in [Early Access](https://yuzu-emu.org/help/early-access/) are still being worked on.
|
||||
As always, we would like to remind users that the features released in [Early Access](https://yuzu-mirror.github.io/help/early-access/) are still being worked on.
|
||||
If you come across any bugs, issues, performance loss, crashes, or regressions with this new feature, please
|
||||
reach out to us on our [Discord server](https://discord.com/invite/u77vRWY) and share your findings.
|
||||
|
||||
|
|
|
@ -36,7 +36,7 @@ By emulating the `BCAT` service at a high-level, yuzu is able to intercept the g
|
|||
This means that games running on yuzu, will now check for new content on yuzu's servers instead of Nintendo's.
|
||||
|
||||
This allows us to add new in-game content for games that use this service.
|
||||
For the inaugural run, our team members have added some cool content across different games which you can check out [here](https://yuzu-emu.org/help/feature/boxcat/).
|
||||
For the inaugural run, our team members have added some cool content across different games which you can check out [here](https://yuzu-mirror.github.io/help/feature/boxcat/).
|
||||
We will have new events occasionally, so users will have even more fun while playing games on yuzu.
|
||||
|
||||
{{< imgs
|
||||
|
@ -54,7 +54,7 @@ For example - Using Patreon funds, several internal bounties have been setup, wh
|
|||
|
||||
{{< message "Want more information on Boxcat?" >}}
|
||||
Refer to our help page for Boxcat.
|
||||
https://yuzu-emu.org/help/feature/boxcat/
|
||||
https://yuzu-mirror.github.io/help/feature/boxcat/
|
||||
{{< /message >}}
|
||||
|
||||
### Fin!
|
||||
|
|
|
@ -39,7 +39,7 @@ You’ll still get the same daily yuzu updates, which will include new features
|
|||
## How do I install yuzu Early Access?
|
||||
|
||||
Follow this detailed step-by-step guide, to install yuzu `Early Access` via the Installer. <br>
|
||||
[**Click here for the guide**](https://yuzu-emu.org/help/early-access/)
|
||||
[**Click here for the guide**](https://yuzu-mirror.github.io/help/early-access/)
|
||||
|
||||
## Why did we make this change?
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ Let's get started!
|
|||
<!--more-->
|
||||
|
||||
|
||||
Project Hades is now available in the latest [yuzu Early Access build](https://yuzu-emu.org/help/early-access/).
|
||||
Project Hades is now available in the latest [yuzu Early Access build](https://yuzu-mirror.github.io/help/early-access/).
|
||||
As always, we ask that you test various games with these builds and if you encounter any issues, bugs, or crashes, please reach out to us via the [Discord](https://discord.gg/u77vRWY) Patreon channels.
|
||||
<article class="message is-warning"><div class="message-header"><p>Notice</p></div><div class="message-body"><p style="color:white">The entire shader generation process has been redesigned from the ground up, thus existing shader caches have been invalidated. Users will need to build their shader caches again, from scratch, with Project Hades.</p></div></article>
|
||||
|
||||
|
|
|
@ -17,7 +17,7 @@ Let's jump right in!
|
|||
As we mentioned, the yuzu installer is available for Linux.
|
||||
The installer will distribute `AppImages` of Mainline and Early Access builds for our Linux users.
|
||||
|
||||
You can now download the new installer from our [Downloads page](https://yuzu-emu.org/downloads/).
|
||||
You can now download the new installer from our [Downloads page](https://yuzu-mirror.github.io/downloads/).
|
||||
|
||||
(Note: Early Access builds require a subscription to our [Patreon](https://www.patreon.com/yuzuteam). We appreciate any and all support!)
|
||||
|
||||
|
|
|
@ -66,7 +66,7 @@ That means things like uptime and support are much better than `Travis` or `Appv
|
|||
It is a single service which can generate builds for all of our platforms, which we didn't have before.
|
||||
We also get more dedicated resources and therefore builds are generated much faster with Azure.
|
||||
|
||||
Starting today, users will be able to get the new and improved yuzu builds via the installer from our [website](https://yuzu-emu.org/downloads/) or our [GitHub](https://github.com/yuzu-emu/yuzu-mainline/releases/).
|
||||
Starting today, users will be able to get the new and improved yuzu builds via the installer from our [website](https://yuzu-mirror.github.io/downloads/) or our [GitHub](https://github.com/yuzu-emu/yuzu-mainline/releases/).
|
||||
And if you are already using our installer, you will be automatically migrated to the latest yuzu build.
|
||||
|
||||
{{< imgs
|
||||
|
|
|
@ -233,7 +233,7 @@ seen so far were getting stuck, either hanging or deadlocking because they were
|
|||
Apart from the work mentioned above, we have also had minor fixes which helped us boot further in
|
||||
games like Super Mario Odyssey, 1-2-Switch, and The Binding of Issac.
|
||||
|
||||
***Check out the next part of this report [here](https://yuzu-emu.org/entry/yuzu-progress-report-2018-p2)***
|
||||
***Check out the next part of this report [here](https://yuzu-mirror.github.io/entry/yuzu-progress-report-2018-p2)***
|
||||
|
||||
<h3 align="center">
|
||||
<b><a href="https://github.com/yuzu-emu/yuzu/">Contributions are always welcome !</a></b>
|
||||
|
|
|
@ -9,7 +9,7 @@ We bring you part 2 of the extensive coverage on yuzu's tremendous progress. So
|
|||
exciting ride, cause its gonna blow your mind!
|
||||
|
||||
<h5 style="text-align: center;">
|
||||
***Haven't read the first part yet? Read it [here](https://yuzu-emu.org/entry/yuzu-progress-report-2018-p1)***
|
||||
***Haven't read the first part yet? Read it [here](https://yuzu-mirror.github.io/entry/yuzu-progress-report-2018-p1)***
|
||||
</h5>
|
||||
<!--more-->
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ Recently we have had new features like Joystick Hot-plugging support and Touch I
|
|||
While Joystick hot-plugging allows us to connect/disconnect controllers on-the-go, without crashing the emulator, Touch Input handling allows us to use a physical touch screen for input, in the place of a mouse.
|
||||
|
||||
Web Services & Telemetry features are used to gather anonymous user statistics and for other backend stuff like user authentication.
|
||||
We now have a [Compatibility Database](https://yuzu-emu.org/game/) which lists the playability information for various games.
|
||||
We now have a [Compatibility Database](https://yuzu-mirror.github.io/game/) which lists the playability information for various games.
|
||||
Mind you that this list is a work-in-progress and is community driven.
|
||||
Play games on yuzu and while playing, go to `Help -> Report Compatibility` and submit info to help improve the database.
|
||||
`Discord Rich Presence`, a novelty feature, was also added so that yuzu fans could show off in their discord statuses.
|
||||
|
@ -461,7 +461,7 @@ His other notable works include:
|
|||
* Added support for `LayeredFS` mods - which brings infinite possibilities for games in yuzu.
|
||||
* Added support for packed updates - which are basically `XCI` files with both base game and updates.
|
||||
* Implemented DLC loading.
|
||||
* Added support for full key-derivation, so that you don't need 3rd party tools for dumping keys, only our [quickstart](https://yuzu-emu.org/help/quickstart/) guide.
|
||||
* Added support for full key-derivation, so that you don't need 3rd party tools for dumping keys, only our [quickstart](https://yuzu-mirror.github.io/help/quickstart/) guide.
|
||||
* Added support for loading IPS patches.
|
||||
* Added support for the more easier IPSwitch format patches.
|
||||
* Implemented save data types - `TemporaryStorage` and `DeviceSaveData`.
|
||||
|
|
|
@ -12,7 +12,7 @@ Howdy yuz-ers! Another month gone, another progress report written. From new fir
|
|||
|
||||
## Project Eleuthia
|
||||
|
||||
As described in [its own dedicated article](https://yuzu-emu.org/entry/yuzu-applet-overlays/), [Morph](https://github.com/Morph1984) and [Rei](https://github.com/Its-Rei) have been very busy [*rei*mplementing the applets](https://github.com/yuzu-emu/yuzu/pull/6133) yuzu uses.
|
||||
As described in [its own dedicated article](https://yuzu-mirror.github.io/entry/yuzu-applet-overlays/), [Morph](https://github.com/Morph1984) and [Rei](https://github.com/Its-Rei) have been very busy [*rei*mplementing the applets](https://github.com/yuzu-emu/yuzu/pull/6133) yuzu uses.
|
||||
|
||||
This first step implements the `On-Screen Keyboard` (or OSK) that games use, and the `Error Display` yuzu uses to alert the user to bugs, missing data, or crashes.
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ Hello yuz-ers, the month of April has been amazing! We'll discuss CPU and Kernel
|
|||
|
||||
## Saving Princess Peach yet again
|
||||
|
||||
Continuing his work to better support the [official](https://yuzu-emu.org/entry/yuzu-progress-report-mar-2022/#the-vulkan-emulator) GameCube/Wii and Nintendo 64 emulators (codenamed `Hagi` and `Hovercraft` respectively), [byte[]](https://github.com/liamwhite) has introduced several new PRs to further improve the compatibility of the titles included within `Super Mario 3D All-Stars`.
|
||||
Continuing his work to better support the [official](https://yuzu-mirror.github.io/entry/yuzu-progress-report-mar-2022/#the-vulkan-emulator) GameCube/Wii and Nintendo 64 emulators (codenamed `Hagi` and `Hovercraft` respectively), [byte[]](https://github.com/liamwhite) has introduced several new PRs to further improve the compatibility of the titles included within `Super Mario 3D All-Stars`.
|
||||
|
||||
byte[] first implemented support for GLSL in `Super Mario Sunshine`, as not everyone can run Vulkan.
|
||||
This is achieved by adding {{< gh-hovercard "8133" "support for indirect addressing" >}} in OpenGL.
|
||||
|
@ -116,7 +116,7 @@ He fixed the reported issues and further cleaned up the code to improve code qua
|
|||
{{< gh-hovercard "8137" "See the code changes for the NVFlinger rewrite here" >}}.
|
||||
|
||||
`Xenoblade Chronicles 2` and `Hyrule Warriors: Age of Calamity` would experience interesting issues which were caused by the new `GPU Garbage Collector` introduced as part of `Project Y.F.C.`.
|
||||
We talked about those changes back in [January](https://yuzu-emu.org/entry/yuzu-progress-report-jan-2022/#other-graphical-fixes).
|
||||
We talked about those changes back in [January](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jan-2022/#other-graphical-fixes).
|
||||
|
||||
As you can see on the top bar below, `Xenoblade Chronicles 2` would use exorbitant amounts of VRAM in OpenGL (top bar).
|
||||
The bottom bar shows the result after the fixes were implemented.
|
||||
|
@ -142,7 +142,7 @@ Thankfully, Morph added the {{< gh-hovercard "8267" "magic line to the code" >}}
|
|||
## Skyline framework: Part 3
|
||||
|
||||
There has been important progress in getting the [Skyline](https://github.com/skyline-dev/skyline) modding framework working.
|
||||
[Here are](https://yuzu-emu.org/entry/yuzu-progress-report-nov-2021/#skyline-framework-part-1) the [two links](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2021/#skyline-framework-part-2) if you missed our previous progress reports on the subject.
|
||||
[Here are](https://yuzu-mirror.github.io/entry/yuzu-progress-report-nov-2021/#skyline-framework-part-1) the [two links](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2021/#skyline-framework-part-2) if you missed our previous progress reports on the subject.
|
||||
|
||||
[tech-ticks](https://github.com/tech-ticks) has been quite busy {{< gh-hovercard "8171" "working on the finishing touches" >}}.
|
||||
The latest changes include:
|
||||
|
|
|
@ -17,7 +17,7 @@ Poor Melia up there.
|
|||
And that’s exactly what we did.
|
||||
|
||||
A more accurate name for this change would be “a rewrite of the Buffer Cache Rewrite”, {{< gh-hovercard "10084" "perhaps rBCR for short?" >}}
|
||||
Essentially, Blinkhawk rewrote most of the old buffer cache changes that [Rodrigo](https://github.com/ReinUsesLisp) introduced [two years ago](https://yuzu-emu.org/entry/yuzu-bcr/), taking into account the new demands of recent games and the issues found with the original BCR.
|
||||
Essentially, Blinkhawk rewrote most of the old buffer cache changes that [Rodrigo](https://github.com/ReinUsesLisp) introduced [two years ago](https://yuzu-mirror.github.io/entry/yuzu-bcr/), taking into account the new demands of recent games and the issues found with the original BCR.
|
||||
|
||||
Part of the work {{< gh-hovercard "10088" "also involves:" >}}
|
||||
|
||||
|
@ -89,7 +89,7 @@ For those interested in trying it, the toggle is available in `Emulation > Confi
|
|||
|
||||
[vonchenplus](https://github.com/vonchenplus) continues to work on making the {{< gh-hovercard "10008" "code match the information NVIDIA has made public" >}} in their latest documentation.
|
||||
|
||||
You may remember [Wollnashorn](https://github.com/Wollnashorn) from their role in [overhauling the Vulkan pipeline cache](https://yuzu-emu.org/entry/yuzu-progress-report-jan-2023/#new-challenger-approaching).
|
||||
You may remember [Wollnashorn](https://github.com/Wollnashorn) from their role in [overhauling the Vulkan pipeline cache](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jan-2023/#new-challenger-approaching).
|
||||
Now, Wollnashorn presents us with a technique to bypass hardware limitations in order to make `The Legend of Zelda: Breath of the Wild` render accurately on non-NVIDIA hardware.
|
||||
|
||||
Object edges, especially grass blades, had distinct black borders on AMD and Intel GPUs.
|
||||
|
@ -152,7 +152,7 @@ Fixing this special case solved the depth-of-field rendering issues in `Kirby St
|
|||
>}}
|
||||
|
||||
Still on fire, and with more work to come, Blinkhawk hasn’t stopped.
|
||||
For something light, he decided to refactor a big part of [Accelerate DMA](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2023/#project-yfc-175) to do {{< gh-hovercard "10082" "texture downloads" >}} through the texture cache instead.
|
||||
For something light, he decided to refactor a big part of [Accelerate DMA](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2023/#project-yfc-175) to do {{< gh-hovercard "10082" "texture downloads" >}} through the texture cache instead.
|
||||
The result is a return to the performance `Pokémon Sword & Shield` and `Hyrule Warriors: Age of Calamity` had before the old Y.F.C 1.75 changes.
|
||||
Add up the gains from Y.F.C 1.90, and you have a winner for low-end systems!
|
||||
|
||||
|
@ -195,7 +195,7 @@ Properly {{< gh-hovercard "10056" "returning this error as a result" >}} is enou
|
|||
"./igs.png| Nothing beats the classics (IGS Classic Arcade Collection)"
|
||||
>}}
|
||||
|
||||
One of the options made available to our [LDN](https://yuzu-emu.org/entry/ldn-is-here/) users is the ability to [create private rooms](https://yuzu-emu.org/help/feature/multiplayer/), providing hosts with several options to configure their servers as they want.
|
||||
One of the options made available to our [LDN](https://yuzu-mirror.github.io/entry/ldn-is-here/) users is the ability to [create private rooms](https://yuzu-mirror.github.io/help/feature/multiplayer/), providing hosts with several options to configure their servers as they want.
|
||||
|
||||
[twitchax](https://github.com/twitchax) knows that for certain server hosts, such as `fly.io`, a {{< gh-hovercard "10068" "custom bind address" >}} is needed.
|
||||
They implemented the functionality and now users can pass the `--bind-address` argument to the room’s configuration.
|
||||
|
@ -298,7 +298,7 @@ You can be sure I’ll be nagging our GPU devs until it gets added.
|
|||
|
||||
### AMD, delivering on their promises
|
||||
|
||||
[Last month,](https://yuzu-emu.org/entry/yuzu-progress-report-mar-2023/#amd-2332-and-newer-drivers) we mentioned that AMD introduced a regression that caused graphical corruption and crashes with some games.
|
||||
[Last month,](https://yuzu-mirror.github.io/entry/yuzu-progress-report-mar-2023/#amd-2332-and-newer-drivers) we mentioned that AMD introduced a regression that caused graphical corruption and crashes with some games.
|
||||
|
||||
We’re happy to announce that since driver version 23.4.2 and later the issue is resolved for Vega and newer, allowing Radeon Windows users to fully benefit from the new Vulkan extensions supported by the latest drivers, reducing shader building stuttering to a minimum.
|
||||
Just as AMD promised, except...
|
||||
|
|
|
@ -71,7 +71,7 @@ byte[] additionally identified a case of the opposite, where a format was suppor
|
|||
|
||||
A few GPU changes not related to Xenoblade also made it in this month.
|
||||
|
||||
After years, since the beginning of our [Vulkan backend](https://yuzu-emu.org/entry/yuzu-vulkan/), yuzu finally added {{< gh-hovercard "8735" "support for VSync in Vulkan" >}} by new contributor [djrobx](https://github.com/djrobx).
|
||||
After years, since the beginning of our [Vulkan backend](https://yuzu-mirror.github.io/entry/yuzu-vulkan/), yuzu finally added {{< gh-hovercard "8735" "support for VSync in Vulkan" >}} by new contributor [djrobx](https://github.com/djrobx).
|
||||
As described by the pull request adding it, if the emulation and display are very close to precise sync, there can be fits of juddering when the newly generated frames don't decisively fall as next to be displayed.
|
||||
This change allows yuzu to completely synchronize frames with the monitor refresh rate, preventing any juddering.
|
||||
Thank you very much!
|
||||
|
@ -267,7 +267,7 @@ If any user suffered from this and can’t remove the files, open the Command Pr
|
|||
#### Intel ARC joins the fun
|
||||
|
||||
We received information that early adopters of A380 Intel GPUs had issues running their games using Vulkan.
|
||||
Since this hardware is not globally available yet, it’s not easy for our developers and testers to get their hands on it, so please [post issues in our GitHub](https://github.com/yuzu-emu/yuzu/issues) including [log files](https://yuzu-emu.org/help/reference/log-files/), or contact us on our [forums](https://community.citra-emu.org/c/yuzu-support/14) or our [Discord server](https://discord.gg/u77vRWY).
|
||||
Since this hardware is not globally available yet, it’s not easy for our developers and testers to get their hands on it, so please [post issues in our GitHub](https://github.com/yuzu-emu/yuzu/issues) including [log files](https://yuzu-mirror.github.io/help/reference/log-files/), or contact us on our [forums](https://community.citra-emu.org/c/yuzu-support/14) or our [Discord server](https://discord.gg/u77vRWY).
|
||||
We’ll ask for more information, if needed, to find the reason for this.
|
||||
Hurray for the early adopter woes.
|
||||
|
||||
|
@ -319,7 +319,7 @@ Working on the finishing touches for `Project London`, Tobi has not been passive
|
|||
"./ldn.png| The most fun ever doing internal testing"
|
||||
>}}
|
||||
|
||||
Oh! How could we almost forget? `Project London`, LDN support, is _finally_ out now! More information in [the dedicated article](https://yuzu-emu.org/entry/ldn-is-here/) and [Multiplayer Guide](https://yuzu-emu.org/help/feature/multiplayer/).
|
||||
Oh! How could we almost forget? `Project London`, LDN support, is _finally_ out now! More information in [the dedicated article](https://yuzu-mirror.github.io/entry/ldn-is-here/) and [Multiplayer Guide](https://yuzu-mirror.github.io/help/feature/multiplayer/).
|
||||
We’ll recap the release in the next Progress Report.
|
||||
|
||||
That’s all folks! Thank you so much for sticking with us, and I hope to see you all next time!
|
||||
|
|
|
@ -15,12 +15,12 @@ We keep trying with the time machine, but we’re running out of bananas to micr
|
|||
|
||||
## PSA for NVIDIA users: Part 2
|
||||
|
||||
As mentioned [two months ago](https://yuzu-emu.org/entry/yuzu-progress-report-oct-2021/#psa-for-nvidia-users), NVIDIA users have been experiencing issues when using GLSL due
|
||||
As mentioned [two months ago](https://yuzu-mirror.github.io/entry/yuzu-progress-report-oct-2021/#psa-for-nvidia-users), NVIDIA users have been experiencing issues when using GLSL due
|
||||
to the changes introduced by NVIDIA dropping support for Kepler cards in the 49X series of drivers.
|
||||
|
||||
We’re happy to announce that we have a [set of workarounds](https://github.com/yuzu-emu/yuzu/pull/7629) implemented by [epicboy](https://github.com/ameerj) that solve all
|
||||
known issues.
|
||||
These are already available for both Mainline and [Early Access](https://yuzu-emu.org/help/early-access/).
|
||||
These are already available for both Mainline and [Early Access](https://yuzu-mirror.github.io/help/early-access/).
|
||||
|
||||
The root of the problem in NVIDIA’s drivers seems to be in negation of integer and floating point values, and bitwise conversions of input values.
|
||||
|
||||
|
@ -34,7 +34,7 @@ In our example, `y` would get the value of `0 - x`.
|
|||
|
||||
The bitwise conversion issue is more complex, but we talked about it in the past.
|
||||
Back in August,
|
||||
[we mentioned how Intel had issues in Vulkan](https://yuzu-emu.org/entry/yuzu-progress-report-aug-2021/#another-terrible-implementation-and-other-graphical-fixes)
|
||||
[we mentioned how Intel had issues in Vulkan](https://yuzu-mirror.github.io/entry/yuzu-progress-report-aug-2021/#another-terrible-implementation-and-other-graphical-fixes)
|
||||
affecting Mario’s legendary moustache.
|
||||
|
||||
`GetAttribute` returns a float value, so a conversion is needed when working with integer values.
|
||||
|
@ -191,7 +191,7 @@ german77 also added support for the `SetNpadJoyAssignmentMode` series of service
|
|||
This change [also adds support for](https://github.com/yuzu-emu/yuzu/pull/7521) dual Joy-Con pairs with a single Joy-Con connected, which is something that some
|
||||
games seem to do.
|
||||
|
||||
After the release of `Project Kraken`, [the input rewrite](https://yuzu-emu.org/entry/yuzu-progress-report-nov-2021#projekt-kraken), analog triggers were accidentally broken.
|
||||
After the release of `Project Kraken`, [the input rewrite](https://yuzu-mirror.github.io/entry/yuzu-progress-report-nov-2021#projekt-kraken), analog triggers were accidentally broken.
|
||||
A simple bug slipped by, causing them to only work when the joysticks were moved.
|
||||
[Two lines of code were changed](https://github.com/yuzu-emu/yuzu/pull/7583), and the issue was made no more.
|
||||
|
||||
|
@ -210,7 +210,7 @@ Well, [not any more](https://github.com/yuzu-emu/yuzu/pull/7647)! Again thanks t
|
|||
|
||||
## Flatpak fixes
|
||||
|
||||
Following up from our previous mention [last month](https://yuzu-emu.org/entry/yuzu-progress-report-nov-2021/#graphical-fixes), [liushuyu](https://github.com/liushuyu)
|
||||
Following up from our previous mention [last month](https://yuzu-mirror.github.io/entry/yuzu-progress-report-nov-2021/#graphical-fixes), [liushuyu](https://github.com/liushuyu)
|
||||
continues to fight against the weirdness of [Flatpak](https://flatpak.org/).
|
||||
|
||||
[NVDEC requirements are now more flexible](https://github.com/yuzu-emu/yuzu/pull/7565), the CUDA libraries are no longer mandatory, without actually affecting CUDA
|
||||
|
|
|
@ -76,7 +76,7 @@ But that’s not the whole story, so let’s elaborate further.
|
|||
|
||||
`SMAA`, or enhanced subpixel morphological antialiasing, is an improvement over [MLAA](https://en.wikipedia.org/wiki/Morphological_antialiasing) developed by the Spanish Universidad de Zaragoza and video game studio Crytek, of Crysis fame.
|
||||
|
||||
[BreadFish](https://github.com/breadfish64) implemented the original OpenGL version, intending to release it as part of the [resolution scaler](https://yuzu-emu.org/entry/yuzu-art/). As it turns out, implementing `SMAA` for Vulkan is no joke, and after being nagged by your writer, byte[] had to work 2 weeks to get it in shape.
|
||||
[BreadFish](https://github.com/breadfish64) implemented the original OpenGL version, intending to release it as part of the [resolution scaler](https://yuzu-mirror.github.io/entry/yuzu-art/). As it turns out, implementing `SMAA` for Vulkan is no joke, and after being nagged by your writer, byte[] had to work 2 weeks to get it in shape.
|
||||
|
||||
`SMAA`, being based on `MLAA`, intends to be a post-processing (aka shader-based) option focused on quality over performance by analyzing adjacent pixels, unlike `FXAA` which just blurs the entire screen.
|
||||
The `SMAA` filter is implemented using render passes and it produces its best results when combined with FSR filtering.
|
||||
|
|
|
@ -175,7 +175,7 @@ With these changes, AMD users suffering from the Pentelas/DLC vertex explosion b
|
|||
|
||||
But you know what would help even more? If epicboy also added more optimizations for the AMD proprietary OpenGL driver. {{< gh-hovercard "12437" "Which is exactly what he did." >}}
|
||||
|
||||
With the release of the new OpenGL driver back in [July of 2022](https://yuzu-emu.org/entry/yuzu-progress-report-jul-2022/#amd-opengl-25-years-in-the-making), several unsavoury workarounds that yuzu code had for the red vendor could be removed (and now have been), improving performance.
|
||||
With the release of the new OpenGL driver back in [July of 2022](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jul-2022/#amd-opengl-25-years-in-the-making), several unsavoury workarounds that yuzu code had for the red vendor could be removed (and now have been), improving performance.
|
||||
|
||||
## Android adventures, and kernels with benefits
|
||||
|
||||
|
|
|
@ -159,7 +159,7 @@ As it turns out, for some reason the configuration file was not resetting the fr
|
|||
Previously, yuzu dumped the base `exeFS`, which only includes data from the base game, missing any new addition from updates or DLCs.
|
||||
Instead, by {{< gh-hovercard "7899" "dumping the patched `exeFS`" >}}, like [EliEron](https://github.com/EliEron) {{< gh-hovercard "4341" "suggested in the past" >}}, users will have access to update files!
|
||||
|
||||
[toastUnlimited](https://github.com/lat9nq) found out that `Splatoon 2` crashes when accessing the inventory in the [LAN lobby](https://yuzu-emu.org/entry/yuzu-progress-report-aug-2021/#lan-party-time).
|
||||
[toastUnlimited](https://github.com/lat9nq) found out that `Splatoon 2` crashes when accessing the inventory in the [LAN lobby](https://yuzu-mirror.github.io/entry/yuzu-progress-report-aug-2021/#lan-party-time).
|
||||
{{< gh-hovercard "7887" "Stubbing the `IsUsbFullKeyControllerEnabled` function" >}} is all that was needed.
|
||||
Splat your friends with impunity!
|
||||
|
||||
|
|
|
@ -49,7 +49,7 @@ By getting rid of this undesired behaviour, the `gpu_thread` is back to only con
|
|||
|
||||
Even from the shadows, [epicboy](https://github.com/ameerj) still gifts us a handful of new toys. A true Eminence in Shadow.
|
||||
|
||||
Avid readers may remember that [MSAA image uploads](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2021/) hold a weird spot in Switch emulation.
|
||||
Avid readers may remember that [MSAA image uploads](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2021/) hold a weird spot in Switch emulation.
|
||||
There’s a conflict between what the Switch can do with its native NVN API, and what our available graphics APIs (OpenGL and Vulkan) allow.
|
||||
|
||||
Both OpenGL and Vulkan are very restrictive regarding {{< gh-hovercard "9746" "MSAA texture" >}} uploads and copies, leaving epicboy with the only remaining tool available. Yep, you’re right! Time to use a compute shader!
|
||||
|
@ -163,7 +163,7 @@ Now instead of pushing the game’s requests to the services, the services wait
|
|||
All this processing is done, for the most part, in what would be the emulated `core 3` of the Switch, instead of all over the place with one thread per service.
|
||||
Games usually only have access to cores 0 to 2, so we're now dedicating the last core for system service processing, just as the actual Switch operating system does!
|
||||
|
||||
This part of CPU emulation is one of the main reasons we recommend at least 6 cores in our [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements), 4 for uninterrupted emulation of the Switch’s CPU, and extras for other processes and tasks. Just a 4 core CPU will be usually overburdened. HT/SMT may help, but that will always depend on the workload at any given moment.
|
||||
This part of CPU emulation is one of the main reasons we recommend at least 6 cores in our [hardware requirements](https://yuzu-mirror.github.io/help/quickstart/#hardware-requirements), 4 for uninterrupted emulation of the Switch’s CPU, and extras for other processes and tasks. Just a 4 core CPU will be usually overburdened. HT/SMT may help, but that will always depend on the workload at any given moment.
|
||||
A SMT/HT thread can’t improve performance in a significant way if the core is already saturated.
|
||||
|
||||
[bunnei](https://github.com/bunnei) chimed in too, fixing a mistake in {{< gh-hovercard "9773" "memory mapping." >}}
|
||||
|
@ -187,7 +187,7 @@ This time, the recently released update 1.2.0 wouldn’t boot on yuzu. After inv
|
|||
Some code changes later, and german77 fixed the issue! Now anyone can enjoy the reduced NPC count and lower draw distance.
|
||||
|
||||
Even [your writer](https://github.com/goldenx86) tried to give a hand (emphasis on tried).
|
||||
[As reported in the past](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2022/#cpu-requirement-changes-with-free-performance), we applied `Link-time Optimization` to all of yuzu’s subprojects. This meant that every section like audio, input, UI, etc. used LTO at build time, trying to squeeze out every possible bit of performance.
|
||||
[As reported in the past](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2022/#cpu-requirement-changes-with-free-performance), we applied `Link-time Optimization` to all of yuzu’s subprojects. This meant that every section like audio, input, UI, etc. used LTO at build time, trying to squeeze out every possible bit of performance.
|
||||
This caused an unexpected problem: RAM consumption while building increased enough to cause our buildbot to cry for help, causing builds on our Azure DevOps CI to randomly run out of memory.
|
||||
|
||||
byte[] suggested that I instead profile which subprojects would provide the most performance boosts, and to only apply LTO to those.
|
||||
|
@ -229,7 +229,7 @@ The user can adjust the sensitivity of mouse motion with the same setting used f
|
|||
>}}
|
||||
|
||||
But did german77 focus on nothing but `Metroid Prime Remastered`? No.
|
||||
Continuing the work started in [December of 2022](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2022/#new-joy-con-driver-and-other-input-improvements), {{< gh-hovercard "9759" "support for Pro Controllers" >}} within the new custom “Joy-Con” driver.
|
||||
Continuing the work started in [December of 2022](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2022/#new-joy-con-driver-and-other-input-improvements), {{< gh-hovercard "9759" "support for Pro Controllers" >}} within the new custom “Joy-Con” driver.
|
||||
Since the option is experimental, it only works properly on official Switch Pro Controllers and not with third party controllers, so it’s disabled by default.
|
||||
Owners of *real* Pro Controllers are encouraged to enable this option, as it will provide much improved motion and HD Rumble support.
|
||||
|
||||
|
@ -290,14 +290,14 @@ A small mistake caused the web applet to lose the ability to redraw and zoom its
|
|||
Per-game settings are very useful, but also very tricky to get right codewise.
|
||||
[m-HD](https://github.com/m-HD) greets us by adding a few missing graphical settings to the list, solving conflicting issues when setting the fullscreen mode, resolution scaling, filter, and antialiasing values in the {{< gh-hovercard "9784" "per-game" >}} configuration window.
|
||||
|
||||
german77 then properly implemented per-game configuration support for the `Force maximum clocks` {{< gh-hovercard "9863" "setting" >}} AMD GPUs [benefit](https://yuzu-emu.org/entry/yuzu-progress-report-jan-2023/) so much from.
|
||||
german77 then properly implemented per-game configuration support for the `Force maximum clocks` {{< gh-hovercard "9863" "setting" >}} AMD GPUs [benefit](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jan-2023/) so much from.
|
||||
|
||||
While we are constantly working to improve the user experience, yuzu sometimes does crash. That’s expected of any first generation emulator, but what shouldn’t happen is not saving changes made to the configuration settings after a crash or a force close.
|
||||
The problem was in our Qt UI, and german77 worked to properly tell Qt to save and sync the configuration to file, avoiding any {{< gh-hovercard "9817" "configuration change loss" >}} after a force close.
|
||||
|
||||
## General fixes
|
||||
|
||||
[MonsterDruide1](https://github.com/MonsterDruide1) continues to do wonders with the [LDN](https://yuzu-emu.org/entry/ldn-is-here/) code.
|
||||
[MonsterDruide1](https://github.com/MonsterDruide1) continues to do wonders with the [LDN](https://yuzu-mirror.github.io/entry/ldn-is-here/) code.
|
||||
This time, proper error handling.
|
||||
One of the possible errors when handling TCP connections is `ECONNRESET`, which happens when the other end closes the connection abruptly.
|
||||
Old-school gamers call this “rage quitting”.
|
||||
|
@ -370,7 +370,7 @@ Frustratingly, this isn’t a problem with the Mesa Linux drivers, or the old Ge
|
|||
I’ve been kidnapped by our devs, so no leaks this time. I promise more for next month!
|
||||
|
||||
There is one thing I’m allowed to mention, recent core timing changes have reduced CPU use by 5-20% across the board on Windows depending on the total thread count. This means better performance and reduced power consumption, especially benefiting mobile devices like laptops and handhelds.
|
||||
This change is already in both [Mainline](https://yuzu-emu.org/downloads/) and [Early Access](https://yuzu-emu.org/help/early-access/), but we’ll talk more about it and other nice things next month.
|
||||
This change is already in both [Mainline](https://yuzu-mirror.github.io/downloads/) and [Early Access](https://yuzu-mirror.github.io/help/early-access/), but we’ll talk more about it and other nice things next month.
|
||||
|
||||
That’s all folks!
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ Welcome yuz-ers, to the first progress report of 2021! We have quite a bit in st
|
|||
|
||||
## The Buffer Cache Rewrite
|
||||
|
||||
While we have a [dedicated article detailing the improvements from the Buffer Cache Rewrite](https://yuzu-emu.org/entry/yuzu-bcr/) [(BCR)](https://github.com/yuzu-emu/yuzu/pull/5741), [Rodrigo](https://github.com/ReinUsesLisp) didn't sit idle and continued to improve the buffer cache. These new changes and improvements deserve some time in the spotlight. For the full context, we advise reading the dedicated article before continuing.
|
||||
While we have a [dedicated article detailing the improvements from the Buffer Cache Rewrite](https://yuzu-mirror.github.io/entry/yuzu-bcr/) [(BCR)](https://github.com/yuzu-emu/yuzu/pull/5741), [Rodrigo](https://github.com/ReinUsesLisp) didn't sit idle and continued to improve the buffer cache. These new changes and improvements deserve some time in the spotlight. For the full context, we advise reading the dedicated article before continuing.
|
||||
|
||||
{{< single-title-imgs
|
||||
"The BCR offers performance and rendering improvements (Xenoblade Chronicles Definitive Edition)"
|
||||
|
@ -46,7 +46,7 @@ We recommend users to play with this setting to find the optimal performance, bu
|
|||
"./bcr.png| While there are big improvements across the board, this graph shows the limitations of integrated GPUs constantly fighting the CPU for RAM resources. Having your own fast dedicated on-board VRAM is very important for performance."
|
||||
>}}
|
||||
|
||||
Analysis time. If you compare this graph to the one of the RX550 in the [BCR artricle,](https://yuzu-emu.org/entry/yuzu-bcr/) you will notice that a small integrated Vega manages to beat a dedicated Polaris card in `Fire Emblem: Three Houses` by a few frames.
|
||||
Analysis time. If you compare this graph to the one of the RX550 in the [BCR artricle,](https://yuzu-mirror.github.io/entry/yuzu-bcr/) you will notice that a small integrated Vega manages to beat a dedicated Polaris card in `Fire Emblem: Three Houses` by a few frames.
|
||||
This is because newer GPU architectures offer features that are useful for Switch emulation. Ray tracing is not the only cool kid in town!
|
||||
|
||||
The Tegra X1 SoC in the Nintendo Switch offers native support for FP16 with a 2:1 performance ratio, allowing games to double their performance over regular FP32 when doing floating point calculations. A simple way to achieve a higher frame rate on limited hardware.
|
||||
|
@ -54,7 +54,7 @@ Vega (GCN 5.0), Turing, Gen 9 Intel Graphics and newer offer native support for
|
|||
Series like Polaris (GCN 4.0), Pascal and older may offer support in their drivers but don’t provide a performance advantage, and in the case of Pascal, it reduces performance considerably (64 times slower than FP32).
|
||||
In those cases FP32 is used to emulate FP16, obviously resulting in no performance gains.
|
||||
|
||||
This is the main reason our [Hardware Requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements) lists Gen 9.5, Vega, and Turing cards, as the recommended GPUs. Maxwell v2, Vega, Gen9 and later series also offer `conservative rasterization`, a very useful feature that yuzu can take advantage of in the future.
|
||||
This is the main reason our [Hardware Requirements](https://yuzu-mirror.github.io/help/quickstart/#hardware-requirements) lists Gen 9.5, Vega, and Turing cards, as the recommended GPUs. Maxwell v2, Vega, Gen9 and later series also offer `conservative rasterization`, a very useful feature that yuzu can take advantage of in the future.
|
||||
|
||||
## General bug fixes and improvements
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ What a month we've had, yuz-ers. This time, we offer you a plethora of kernel ch
|
|||
|
||||
[It’s not over yet](https://www.youtube.com/watch?v=g02QU-xPV1I).
|
||||
|
||||
[As you know](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2021/#paint-me-like-one-of-your-french-bits), regular NVIDIA desktop and laptop GPUs don't support decoding ASTC textures, so yuzu makes use of the compute capabilities of the GPU to parallelize the process. However, the recent release of the 511.XX drivers introduced an issue that affected our compute shader based accelerated ASTC texture decoding.
|
||||
[As you know](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2021/#paint-me-like-one-of-your-french-bits), regular NVIDIA desktop and laptop GPUs don't support decoding ASTC textures, so yuzu makes use of the compute capabilities of the GPU to parallelize the process. However, the recent release of the 511.XX drivers introduced an issue that affected our compute shader based accelerated ASTC texture decoding.
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
"Crispy (Super Mario Odyssey)"
|
||||
|
|
|
@ -101,7 +101,7 @@ Your writer has a stupid idea, and byte[] is the one that ends up listening to m
|
|||
This routine worked successfully with SMAA for Vulkan, unsuccessfully with increasing the staging buffer size to take advantage of ReBAR, sadly, and this time, it _almost worked_ with `Turbo mode`, or its official/boring name, {{< gh-hovercard "9552" "Force maximum clocks." >}}
|
||||
|
||||
You might be able to see where this is going.
|
||||
[A year ago,](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future) Patreon funding got your writer access to an RX 6500 to help with testing and debugging.
|
||||
[A year ago,](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future) Patreon funding got your writer access to an RX 6500 to help with testing and debugging.
|
||||
That card died a horrible, premature death (and no one misses it), but before kicking the bucket, it allowed us to learn that RDNA and RDNA2 hardware from AMD suffer from serious downclocking issues if you’re not constantly shoving work to the GPU.
|
||||
Thankfully, due to the cryptomining crash, an RX 6600 took its place for no extra cost.
|
||||
In your face, miners.
|
||||
|
@ -245,14 +245,14 @@ Baby steps!
|
|||
|
||||
## General changes
|
||||
|
||||
byte[] {{< gh-hovercard "9561" " triggered the scheduled mandatory Dynarmic update," >}} blessing us with [fastmem and page table support](https://yuzu-emu.org/entry/yuzu-fastmem/) for ARM64 devices, boosting performance considerably.
|
||||
byte[] {{< gh-hovercard "9561" " triggered the scheduled mandatory Dynarmic update," >}} blessing us with [fastmem and page table support](https://yuzu-mirror.github.io/entry/yuzu-fastmem/) for ARM64 devices, boosting performance considerably.
|
||||
Anyone with an ARM64 device running a “normal” GPU (not mobile-tier hardware) interested in testing yuzu, feel free to install our official [Flatpak](https://flathub.org/apps/details/org.yuzu_emu.yuzu).
|
||||
|
||||
[german77](https://github.com/german77) stumbled upon an issue which was causing input threads to randomly crash yuzu for seemingly no reason, but only on shutdown.
|
||||
byte[] found that `CoreTiming` had the same logic issue that he fixed last month in the kernel code when adding `KHardwareTimer`: callbacks could be removed while in-progress, which could cause the input threads to continue using memory after it had been freed.
|
||||
With this code changed to {{< gh-hovercard "9619" "wait until any in-progress callbacks are finished before removal," >}} this issue should be solved for good.
|
||||
|
||||
After the merge of german77's impressive Joy-Con driver release [last month](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2022/#new-joy-con-driver-and-other-input-improvements), [Morph](https://github.com/Morph1984) noticed that yuzu was often taking a significantly longer amount of time to shutdown, sometimes more than 5 seconds longer than it should have been allowed to.
|
||||
After the merge of german77's impressive Joy-Con driver release [last month](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2022/#new-joy-con-driver-and-other-input-improvements), [Morph](https://github.com/Morph1984) noticed that yuzu was often taking a significantly longer amount of time to shutdown, sometimes more than 5 seconds longer than it should have been allowed to.
|
||||
He discovered that this was due to sleep calls in the Joy-Con driver to poll for new devices that weren't being cancelled on shutdown, and with help from byte[], he {{< gh-hovercard "9677" "implemented a proper fix" >}} so that they would immediately stop waiting when shutdown was signalled.
|
||||
|
||||
More battles won for the Shutdown Wars, with seemingly no end in sight!
|
||||
|
|
|
@ -83,7 +83,7 @@ Thanks to help from [gdkchan](https://github.com/gdkchan) and [Blinkhawk](https:
|
|||
|
||||
[epicboy](https://github.com/ameerj) is working on [implementing support for GameCube adapters](https://github.com/yuzu-emu/yuzu/pull/4137), allowing players to use original GameCube controllers! Veteran Smash players will surely enjoy it.
|
||||
|
||||
[`Project Prometheus`](https://yuzu-emu.org/entry/yuzu-prometheus/) introduced so many changes that we are still working on reaching feature parity with the original single-core implementation. [ogniK](https://github.com/ogniK5377) [improved the audio timing](https://github.com/yuzu-emu/yuzu/pull/4219), fixing audio bugs that were introduced with the implementation of the new multicore and single-core emulation methods.
|
||||
[`Project Prometheus`](https://yuzu-mirror.github.io/entry/yuzu-prometheus/) introduced so many changes that we are still working on reaching feature parity with the original single-core implementation. [ogniK](https://github.com/ogniK5377) [improved the audio timing](https://github.com/yuzu-emu/yuzu/pull/4219), fixing audio bugs that were introduced with the implementation of the new multicore and single-core emulation methods.
|
||||
|
||||
Since its introduction, enabling multicore was the only way to reach stable gameplay on Linux systems, as the single-core option would lead to a crash in every game. Thanks to [comex's report](https://github.com/yuzu-emu/yuzu/issues/4424), [Lioncache](https://github.com/lioncash) fixed it by [using the return value of Lock() in the nvflinger surface compositor](https://github.com/yuzu-emu/yuzu/pull/4426). Thanks to this fix, games that are not yet stable with multicore, like `Luigi’s Mansion 3`, can now be safely played in the Tux OS (Linux).
|
||||
|
||||
|
|
|
@ -22,11 +22,11 @@ After being in development for six months, and spanning almost 50,000 lines of n
|
|||
Fixing an innumerable amount of rendering bugs, reducing shader build times, improving compatibility, and increasing performance by over 30% for all GPU vendors, Hades is easily
|
||||
one of the biggest changes made to yuzu to date.
|
||||
|
||||
[We have a dedicated article explaining the process in technical detail](https://yuzu-emu.org/entry/yuzu-hades/), so we will be focusing only on the end user changes and some
|
||||
[We have a dedicated article explaining the process in technical detail](https://yuzu-mirror.github.io/entry/yuzu-hades/), so we will be focusing only on the end user changes and some
|
||||
recommendations to help you get the best experience out of this new feature that both Early Access and Mainline users can enjoy.
|
||||
|
||||
While we keep OpenGL as the default graphics API for compatibility reasons (outdated drivers won’t affect it as much, and it lets Nvidia Fermi GPU users run yuzu out of the box), we
|
||||
strongly recommend testing your games with the Vulkan API first. Vulkan performance and compatibility have improved significantly (especially if paired with the [Texture Reaper](https://yuzu-emu.org/entry/yuzu-progress-report-jun-2021/#project-texture-reaper), the GPU Cache Garbage Collector), additionally, rendering and shader build performance almost always beat OpenGL.
|
||||
strongly recommend testing your games with the Vulkan API first. Vulkan performance and compatibility have improved significantly (especially if paired with the [Texture Reaper](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jun-2021/#project-texture-reaper), the GPU Cache Garbage Collector), additionally, rendering and shader build performance almost always beat OpenGL.
|
||||
This applies not only for AMD and Intel GPU users, but also Nvidia users.
|
||||
|
||||
There is an exception, however. The Intel Linux Vulkan driver is not stable at the moment, but we’re investigating the cause of the issue. For now, Intel Linux users should
|
||||
|
@ -151,12 +151,12 @@ To avoid confusion with the FPS unlimiter, the old Frame limit was [renamed to S
|
|||
"./fpscap.png| You can find the new options here"
|
||||
>}}
|
||||
|
||||
From before the [release of the texture cache rewrite](https://yuzu-emu.org/entry/yuzu-tcr/), a regression has existed that caused users' screenshots to save in the wrong directory.
|
||||
From before the [release of the texture cache rewrite](https://yuzu-mirror.github.io/entry/yuzu-tcr/), a regression has existed that caused users' screenshots to save in the wrong directory.
|
||||
Turns out [a single directory separator was missing in the code](https://github.com/yuzu-emu/yuzu/pull/6709).
|
||||
Now, screenshots will work correctly by either pressing the `Ctrl + P` hotkey, or via selecting the `Tools > Capture Screenshot…` menu option, and save in the selected folder.
|
||||
|
||||
epicboy also [added support for taking screenshots in the Vulkan API](https://github.com/yuzu-emu/yuzu/pull/6720), solving an old issue from way back when
|
||||
[Vulkan was first implemented](https://yuzu-emu.org/entry/yuzu-vulkan/) two years ago. How time flies...
|
||||
[Vulkan was first implemented](https://yuzu-mirror.github.io/entry/yuzu-vulkan/) two years ago. How time flies...
|
||||
|
||||
Finally, before being dragged against his will to work on Hades, epicboy was working on improving the performance of our compute shader accelerated ASTC decoder.
|
||||
By reducing the size of the workgroup, making some code simplifications, moving some look up tables, and other changes,
|
||||
|
@ -172,7 +172,7 @@ One of the remaining issues with `Hyrule Warriors: Age of Calamity`, `Fire Emble
|
|||
GPU accuracy when loading specific levels.
|
||||
In Blink’s own words, [a simple fix](https://github.com/yuzu-emu/yuzu/pull/6627), and the problem was solved.
|
||||
|
||||
Another old regression introduced by the [Buffer Cache Rewrite](https://yuzu-emu.org/entry/yuzu-bcr/) affected particles in games like `The Legend of Zelda: Breath of the Wild`, the rendering of the BowWow in
|
||||
Another old regression introduced by the [Buffer Cache Rewrite](https://yuzu-mirror.github.io/entry/yuzu-bcr/) affected particles in games like `The Legend of Zelda: Breath of the Wild`, the rendering of the BowWow in
|
||||
`The Legend of Zelda: Link’s Awakening` and caused vertex explosions in Unreal Engine 4 games like `Yoshi’s Crafted World`, `BRAVELY DEFAULT 2` and similar.
|
||||
[Tuning how to handle high downloads and not fully waiting for command buffers to finish](https://github.com/yuzu-emu/yuzu/pull/6557) solved these issues.
|
||||
To make the best out of this change, High GPU accuracy needs to be enabled.
|
||||
|
|
|
@ -213,7 +213,7 @@ In order to improve the ridiculous memory usage, byte[] {{< gh-hovercard "8684"
|
|||
While this doesn’t solve the issue entirely, testing shows a 5GB reduction in RAM usage from just a single code line addition.
|
||||
|
||||
Let’s stay on the subject of GPU emulation for a bit longer.
|
||||
In a past Progress Report, we explained how [toastUnlimited](https://github.com/lat9nq) [implemented a status check system](https://yuzu-emu.org/entry/yuzu-progress-report-may-2022/#vulkan-by-default) to ensure good Vulkan compatibility when opening yuzu for the first time.
|
||||
In a past Progress Report, we explained how [toastUnlimited](https://github.com/lat9nq) [implemented a status check system](https://yuzu-mirror.github.io/entry/yuzu-progress-report-may-2022/#vulkan-by-default) to ensure good Vulkan compatibility when opening yuzu for the first time.
|
||||
|
||||
The original implementation worked by running a small Vulkan instance at boot, detecting if it crashed, and saving the result in the configuration file.
|
||||
On the next boot after the crash, yuzu informs the user and locks itself to only offer OpenGL.
|
||||
|
@ -321,11 +321,11 @@ Have fun ruining Bowser’s wedding!
|
|||
|
||||
## UI changes
|
||||
|
||||
A small regression from the [input rewrite](https://yuzu-emu.org/entry/yuzu-progress-report-nov-2021/#project-kraken) revealed itself just now.
|
||||
A small regression from the [input rewrite](https://yuzu-mirror.github.io/entry/yuzu-progress-report-nov-2021/#project-kraken) revealed itself just now.
|
||||
The WebApplet’s input bit was assumed incorrectly, causing user input to be completely ignored.
|
||||
Thankfully, Morph {{< gh-hovercard "8536" "found the reason" >}} and implemented the fix.
|
||||
|
||||
Last month, Docteh [renamed](https://yuzu-emu.org/entry/yuzu-progress-report-jun-2022/#ui-changes) the status bar’s DOCKED status (redundancy, yeah!).
|
||||
Last month, Docteh [renamed](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jun-2022/#ui-changes) the status bar’s DOCKED status (redundancy, yeah!).
|
||||
For consistency, [this dumb writer](https://github.com/goldenx86) decided to {{< gh-hovercard "8610" "do the same for the Controls configuration window," >}} for consistency.
|
||||
|
||||
{{< imgs
|
||||
|
@ -360,7 +360,7 @@ This is a new section to communicate and discuss new relevant bugs, fixes, and f
|
|||
|
||||
#### NVIDIA, missing the perfection that 472.12 was
|
||||
|
||||
[We mentioned last month](https://yuzu-emu.org/entry/yuzu-progress-report-jun-2022/#psa-for-amd-radeon-users-and-nvidia-tags-along) how the 516 series of drivers is detrimental to Maxwell and Pascal users, making Vulkan unstable.
|
||||
[We mentioned last month](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jun-2022/#psa-for-amd-radeon-users-and-nvidia-tags-along) how the 516 series of drivers is detrimental to Maxwell and Pascal users, making Vulkan unstable.
|
||||
We’re still debugging the issue, as it isn’t easy to catch, but a possible cause is suspected: GPU accelerated `ASTC` texture decoding.
|
||||
If you own a Maxwell or Pascal GPU, must remain on the latest driver update, and want to test if you can make Vulkan stable again, try disabling `Accelerate ASTC Texture Decoding` in `Emulation > Configure… > Graphics`.
|
||||
Please report your results on our [forums](https://community.citra-emu.org/c/yuzu-support/14) or [Discord server](https://discord.gg/u77vRWY).
|
||||
|
@ -424,7 +424,7 @@ As a bonus, while not being very stable, the SPIR-V shader back-end can be used
|
|||
Another lesson learned from this is that some games, like `Legend of Zelda: Breath of the Wild`, just outright prefer NVIDIA's mature OpenGL driver. Ara ara.
|
||||
|
||||
Lastly, to end this Red Team section.
|
||||
[In the past](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future), we reported a way to defeat RDNA2’s overcorrecting power manager in order to get decent framerates.
|
||||
[In the past](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future), we reported a way to defeat RDNA2’s overcorrecting power manager in order to get decent framerates.
|
||||
This method, while simple, has a downside: It’s an overclock.
|
||||
Or at least counts as one.
|
||||
|
||||
|
|
|
@ -171,7 +171,7 @@ Free performance is free performance.
|
|||
### AMD
|
||||
|
||||
It's July and we have another new AMD GPU driver with yet another extension causing issues.
|
||||
If you recall from our [June progress report](https://yuzu-emu.org/entry/yuzu-progress-report-jun-2023/#amd), we reported that the latest AMD drivers had broken a Vulkan feature - `extendedDynamicState3ColorBlendEquation`, and we had to temporarily disable usage of it on AMD driver version `23.5.2` and above.
|
||||
If you recall from our [June progress report](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jun-2023/#amd), we reported that the latest AMD drivers had broken a Vulkan feature - `extendedDynamicState3ColorBlendEquation`, and we had to temporarily disable usage of it on AMD driver version `23.5.2` and above.
|
||||
|
||||
Fast-forward to July, and it's still broken for some.
|
||||
Giving credit where due, AMD ***did*** fix this issue with driver version `23.7.2`, but only for `RDNA2` GPUs (RX 6000 series). `GCN4`, also known as `Polaris` (RX 400 and 500 series), are confirmed to still be broken.
|
||||
|
|
|
@ -161,7 +161,7 @@ While rewriting the kernel for Prometheus, [Blinkhawk](https://github.com/Fernan
|
|||
"./toad.png| Good performance even on low-end hardware!"
|
||||
>}}
|
||||
|
||||
Additionally, the merge of this work into the Master branch also means that Multicore support is now working in Mainline! Thanks [Blinkhawk](https://github.com/FernandoS27) for all your hard work on this! Please refer to our previous [May progress report](https://yuzu-emu.org/entry/yuzu-progress-report-may-2020/) and the dedicated [Project Prometheus article](https://yuzu-emu.org/entry/yuzu-prometheus/) to read more about this crucial new feature.
|
||||
Additionally, the merge of this work into the Master branch also means that Multicore support is now working in Mainline! Thanks [Blinkhawk](https://github.com/FernandoS27) for all your hard work on this! Please refer to our previous [May progress report](https://yuzu-mirror.github.io/entry/yuzu-progress-report-may-2020/) and the dedicated [Project Prometheus article](https://yuzu-mirror.github.io/entry/yuzu-prometheus/) to read more about this crucial new feature.
|
||||
|
||||
## Future projects
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ tons of kernel changes, UI improvements, and more!
|
|||
|
||||
## Project Texture Reaper
|
||||
|
||||
An old debt we owed since the release of the [Texture Cache Rewrite](https://yuzu-emu.org/entry/yuzu-tcr/) was `Project Texture Reaper`, a `GPU Cache Garbage Collector`,
|
||||
An old debt we owed since the release of the [Texture Cache Rewrite](https://yuzu-mirror.github.io/entry/yuzu-tcr/) was `Project Texture Reaper`, a `GPU Cache Garbage Collector`,
|
||||
originally started by [Rodrigo](https://github.com/ReinUsesLisp) and finished by [Blinkhawk](https://github.com/FernandoS27) with new and very important optimizations.
|
||||
|
||||
[This garbage collector](https://github.com/yuzu-emu/yuzu/pull/6465) has the task of freeing VRAM space by removing the least used resources (textures and buffers),
|
||||
|
@ -60,7 +60,7 @@ Originally, implementing `fastmem` in yuzu wasn't considered an option as there
|
|||
However, due to a lack of documentation of this feature (thanks Microsoft), our devs didn't know they could use it.
|
||||
We'd like to thank [BreadFish64](https://github.com/BreadFish64/) for informing our devs about this change, and [bylaws](https://github.com/bylaws) for [updating Microsoft's documentation regarding this behaviour](https://github.com/MicrosoftDocs/sdk-api/pull/799).
|
||||
As previously mentioned, this feature is incompatible with Windows versions older than 1803. Using an older Windows version will cause yuzu to fallback to the old `MMU` implementation — although this requirement could change in the future.
|
||||
If you are interested in a more detailed explanation of how it works and the limitations that prevented its implementation, feel free to read the [dedicated article for fastmem](https://yuzu-emu.org/entry/yuzu-fastmem/).
|
||||
If you are interested in a more detailed explanation of how it works and the limitations that prevented its implementation, feel free to read the [dedicated article for fastmem](https://yuzu-mirror.github.io/entry/yuzu-fastmem/).
|
||||
|
||||
{{< single-title-imgs
|
||||
"Some of the measured performance gains, in FPS"
|
||||
|
@ -159,7 +159,7 @@ Some examples of games that have full dynamic FPS support are:
|
|||
ASTC texture decoding is a complex topic when it comes to emulation, as no desktop graphics card has the required hardware support needed to process these heavily compressed textures.
|
||||
The only exception is Intel with their integrated HD Graphics and UHD Graphics series.
|
||||
|
||||
[In the past,](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2021/) epicboy implemented a way to accelerate ASTC texture decoding via the use of `Compute Shaders`,
|
||||
[In the past,](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2021/) epicboy implemented a way to accelerate ASTC texture decoding via the use of `Compute Shaders`,
|
||||
improving decoding performance considerably thanks to taking advantage of the great computing power of modern GPUs.
|
||||
|
||||
The issue is that in some games, `Astral Chain` for example, a synchronization issue caused yuzu to try to access a texture before its decoding was finished, resulting in
|
||||
|
@ -167,7 +167,7 @@ driver panics and application crashes.
|
|||
[Implementing various optimizations and enhancements to the GPU accelerated decoder](https://github.com/yuzu-emu/yuzu/pull/6496) solved those crashes, even on a simple GT
|
||||
730, a card 41.5x times weaker than an RTX 2080 SUPER in compute performance.
|
||||
|
||||
Now that [Project Hades](https://yuzu-emu.org/entry/yuzu-hades/) is finished, there are plans to implement performance optimizations on the ASTC GPU accelerated decoder.
|
||||
Now that [Project Hades](https://yuzu-mirror.github.io/entry/yuzu-hades/) is finished, there are plans to implement performance optimizations on the ASTC GPU accelerated decoder.
|
||||
|
||||
Prior to this work, [a toggle to disable the GPU accelerated decoder](https://github.com/yuzu-emu/yuzu/pull/6464) was added for debugging purposes.
|
||||
It’s no longer needed, but if anyone is curious about how much of a difference decoding with the CPU makes, the option is in `Emulation > Configure… > Graphics >
|
||||
|
@ -295,7 +295,7 @@ Maide [put a stop to this](https://github.com/yuzu-emu/yuzu/pull/6402), improvin
|
|||
|
||||
## Future projects
|
||||
|
||||
With Project Hades [(our new shader decompiler)](https://yuzu-emu.org/entry/yuzu-hades/), Rodrigo continues with his crazy experiments, bunnei has yet more kernel changes in the oven, and german77 and Morph continue
|
||||
With Project Hades [(our new shader decompiler)](https://yuzu-mirror.github.io/entry/yuzu-hades/), Rodrigo continues with his crazy experiments, bunnei has yet more kernel changes in the oven, and german77 and Morph continue
|
||||
to work on their top secret projects.
|
||||
|
||||
More GPU related optimizations are underway, and users should keep a keen eye on the horizon.
|
||||
|
|
|
@ -12,7 +12,7 @@ Dear yuz-ers, we had fantastic progress during June! Driver bugs are being squas
|
|||
|
||||
## PSA for AMD Radeon users (and NVIDIA tags along)
|
||||
|
||||
Let’s begin with a driver bug we [mentioned last month](https://yuzu-emu.org/entry/yuzu-progress-report-may-2022/#graphical-changes-driver-issues-and-the-nostalgia-bliss-that-is-the-good-old-64).
|
||||
Let’s begin with a driver bug we [mentioned last month](https://yuzu-mirror.github.io/entry/yuzu-progress-report-may-2022/#graphical-changes-driver-issues-and-the-nostalgia-bliss-that-is-the-good-old-64).
|
||||
The Vulkan extension `VK_KHR_push_descriptor` finally arrived for AMD hardware with driver version 22.5.2 for Windows, but it wasn’t stable. Radeon users would tell you that any game would crash in Vulkan after updating.
|
||||
To mitigate this, [toastUnlimited](https://github.com/lat9nq) implemented an extension block for the specific Vulkan driver version AMD reports for 22.5.2 (and its equivalent Linux AMDVLK package), 2.0.226.
|
||||
|
||||
|
@ -54,7 +54,7 @@ Now, thanks to this great find by bylaws, the Dovahkiin can finally wake up in t
|
|||
|
||||
You can see we have some rendering issues to solve.
|
||||
|
||||
One of our recent important rendering changes was the [NVFlinger rewrite](https://yuzu-emu.org/entry/yuzu-progress-report-mar-2022/#graphical-changes-and-optimizations), who would have guessed that coding an implementation closer to the Switch would result in a smoother gaming experience?
|
||||
One of our recent important rendering changes was the [NVFlinger rewrite](https://yuzu-mirror.github.io/entry/yuzu-progress-report-mar-2022/#graphical-changes-and-optimizations), who would have guessed that coding an implementation closer to the Switch would result in a smoother gaming experience?
|
||||
|
||||
However, after its release, user reports mentioned timing and frame pacing issues in games like `Super Smash Bros. Ultimate`.
|
||||
Match time would pass increasingly slower, around a second longer per minute on Ryzen systems, and exacerbated with Intel Alder Lake CPUs (12th gen).
|
||||
|
@ -66,7 +66,7 @@ Weird CPU architectures aside, while the issue is solved, Intel Alder Lake users
|
|||
|
||||
While still on the topic of NVFlinger goodies, we present a highly requested feature!
|
||||
Veteran users will remember that during its single threaded days, yuzu would allow control over game speed.
|
||||
With the arrival of multicore, known at the time as [Project Prometheus](https://yuzu-emu.org/entry/yuzu-prometheus/), this feature was only available in single core mode, to the chagrin of many people. How time flies!
|
||||
With the arrival of multicore, known at the time as [Project Prometheus](https://yuzu-mirror.github.io/entry/yuzu-prometheus/), this feature was only available in single core mode, to the chagrin of many people. How time flies!
|
||||
|
||||
{{< gh-hovercard "8508" "yuzu now has control over the frame time calculation," >}} allowing a new method to unlimit the framerate regardless of the CPU emulation mode!
|
||||
You can find the option in `Emulation > Configure… > General > Limit Speed Percent`.
|
||||
|
@ -86,7 +86,7 @@ Unfortunately, he soon ran into more trouble, as it was exceedingly difficult to
|
|||
The source of the pain was not having any way to use a debugger with the emulated games.
|
||||
|
||||
Originally, yuzu inherited a `GDB-compatible debugger interface` from [Citra](https://citra-emu.org), but it was lacking many important features.
|
||||
And even that had to be deprecated during [Project Prometheus](https://yuzu-emu.org/entry/yuzu-prometheus/) (multicore emulation) because of its inherent shortcomings.
|
||||
And even that had to be deprecated during [Project Prometheus](https://yuzu-mirror.github.io/entry/yuzu-prometheus/) (multicore emulation) because of its inherent shortcomings.
|
||||
|
||||
* It only worked with single core mode
|
||||
* It was _slow_ - it could sometimes take 30+ minutes to boot a game, particularly if you had any logging scripts
|
||||
|
@ -160,7 +160,7 @@ The debugger interface is now thread-stable, edge cases in stepping and pausing
|
|||
|
||||
When talking about user interface and experience, you can always count on [Docteh](https://github.com/Docteh).
|
||||
|
||||
[In a repeat of what Morph fixed back in February](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2022/#general-bugfixes-and-ui-changes), Docteh found out that after a crash, the yuzu main window may reopen in some kind of borderless fullscreen… *thing*.
|
||||
[In a repeat of what Morph fixed back in February](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2022/#general-bugfixes-and-ui-changes), Docteh found out that after a crash, the yuzu main window may reopen in some kind of borderless fullscreen… *thing*.
|
||||
The culprit was {{< gh-hovercard "8400" "the `UILayout\geometry` value in yuzu’s qt-config.ini file." >}}
|
||||
A slap in the face and the issue should be gone for good. Ouch.
|
||||
|
||||
|
|
|
@ -432,7 +432,7 @@ If you want to download a previous version, test experimental features, or avoid
|
|||
|
||||
## Making CPUs go the opposite of BRRR, AMD edition
|
||||
|
||||
[Back in March](https://yuzu-emu.org/entry/yuzu-progress-report-mar-2023/#making-cpus-go-the-opposite-of-brrrr), we explained why Windows is not accurate enough when very high precision timers are required, so in order to improve performance, power consumption, and temperatures on x86_64 CPUs, specific CPU instructions are needed to reduce the time the CPU spends improperly idling.
|
||||
[Back in March](https://yuzu-mirror.github.io/entry/yuzu-progress-report-mar-2023/#making-cpus-go-the-opposite-of-brrrr), we explained why Windows is not accurate enough when very high precision timers are required, so in order to improve performance, power consumption, and temperatures on x86_64 CPUs, specific CPU instructions are needed to reduce the time the CPU spends improperly idling.
|
||||
We have a big mistake to correct here. We said only Intel offered such instructions starting with Alder Lake, and that AMD didn’t offer any.
|
||||
|
||||
Fortunately, we were wrong! AMD does indeed have its own implementation, the `monitorx` and `mwaitx` instructions pair, which have been out since *2015*, predating Ryzen!
|
||||
|
@ -486,7 +486,7 @@ Thank you!
|
|||
## Input improvements
|
||||
|
||||
The work to make Amiibos and their Near-Field Communication (NFC) behave the same as on real Switch hardware continues.
|
||||
With the proper implementation finished [last month](https://yuzu-emu.org/entry/yuzu-progress-report-may-2023/#input-and-amiibo-improvements), german77 has focused on the last items on the checklist.
|
||||
With the proper implementation finished [last month](https://yuzu-mirror.github.io/entry/yuzu-progress-report-may-2023/#input-and-amiibo-improvements), german77 has focused on the last items on the checklist.
|
||||
|
||||
First of all, backup support.
|
||||
On the Switch, Amiibo data is stored in the console every time data is loaded or saved.
|
||||
|
@ -539,7 +539,7 @@ Thanks!
|
|||
|
||||
Yes, there’s more progress by byte[] in fixing the current file system implementation while we wait for `Project Gaia`.
|
||||
|
||||
The [previously reported](https://yuzu-emu.org/entry/yuzu-progress-report-may-2023/#project-gaia-lite) “algorithmic complexity issue” when loading mods was working like a charm on Linux, but Windows always has to be difficult.
|
||||
The [previously reported](https://yuzu-mirror.github.io/entry/yuzu-progress-report-may-2023/#project-gaia-lite) “algorithmic complexity issue” when loading mods was working like a charm on Linux, but Windows always has to be difficult.
|
||||
A {{< gh-hovercard "10588" "memory cache" >}} was added to fully realise the load time benefits on Microsoft’s OS too.
|
||||
|
||||
In another single-line-of-code revelation, byte[] discovered that {{< gh-hovercard "10718" "increasing the size of the buffer" >}} when copying files can more than triple the installation speed of updates and DLCs.
|
||||
|
|
|
@ -88,7 +88,7 @@ As always, these changes make it easier to support any future hardware revisions
|
|||
Bunnei also fixed [a memory leak](https://github.com/yuzu-emu/yuzu/pull/6036) caused by `dummy threads`.
|
||||
These dummies are used by yuzu to interact with our emulated kernel.
|
||||
Every "real" emulated thread has a dummy associated with it.
|
||||
As explained in the [previous progress report](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2021/), yuzu utilizes fibers in order to emulate threads.
|
||||
As explained in the [previous progress report](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2021/), yuzu utilizes fibers in order to emulate threads.
|
||||
However, these dummy threads don't actually use fibers.
|
||||
With this change, bunnei removed some unnecessary memory overhead by removing the creation of fibers (which would only be needed for "real" emulated threads), thus reducing the memory usage by a bit.
|
||||
|
||||
|
|
|
@ -188,7 +188,7 @@ If video playback feels smoother, you now know the reason! Thanks epicboy!
|
|||
This is a very common issue caused mostly by very outdated GPU drivers installed by Windows Update, or custom slower drivers provided by laptop manufacturers that are used to lie on battery life metrics or keep up with cheapened cooling solutions.
|
||||
This most commonly affects Intel GPUs, but Vega based Radeon GPUs can also suffer from it occasionally.
|
||||
|
||||
Another popular reason for this issue, as mentioned in [previous reports](https://yuzu-emu.org/entry/yuzu-progress-report-dec-2021/#ui-changes), is outdated Vulkan injectors breaking support altogether.
|
||||
Another popular reason for this issue, as mentioned in [previous reports](https://yuzu-mirror.github.io/entry/yuzu-progress-report-dec-2021/#ui-changes), is outdated Vulkan injectors breaking support altogether.
|
||||
Software like OBS Studio, OBS Streamlabs, Bandicam, Action!, Overwolf, GShade, iCUE, MSI Afterburner, or *anything* with an overlay that injects into Vulkan can completely break rendering if it is outdated, or the developers don’t keep up with recent Vulkan releases.
|
||||
|
||||
{{< gh-hovercard "7986" "toast’s fixes solve 2 different scenarios" >}}.
|
||||
|
|
|
@ -14,7 +14,7 @@ Hi yuz-ers! We've been working hard as usual, and this March saw improvements in
|
|||
One of the biggest changes this month is the set of improvements in CPU accuracy.
|
||||
This requires some backtracking so let’s rewind a little bit.
|
||||
|
||||
Back in [July,](https://yuzu-emu.org/entry/yuzu-progress-report-jul-2022/#core-timing-or-how-to-suffer-so-much-with-a-fix) we explained how `CoreTiming` operates in its current form, using a host timer.
|
||||
Back in [July,](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jul-2022/#core-timing-or-how-to-suffer-so-much-with-a-fix) we explained how `CoreTiming` operates in its current form, using a host timer.
|
||||
A thread called `HostTiming` is used to process HLE events such as input and audio.
|
||||
However, some of these events, like audio, require a high level of timer precision to behave the way games expect, more than Windows would usually allow.
|
||||
|
||||
|
@ -106,7 +106,7 @@ With some trial and error, and some big help from the great [bylaws](https://git
|
|||
"./sosfix.png"
|
||||
>}}
|
||||
|
||||
[epicboy](https://github.com/ameerj) strikes again with his ninja updates. This time he gives some love to the *still thriving* OpenGL gang, bringing all the goodies of {{< gh-hovercard "9913" "AccelerateDMA," >}} which we discussed in the [last report](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2023/#project-yfc-175).
|
||||
[epicboy](https://github.com/ameerj) strikes again with his ninja updates. This time he gives some love to the *still thriving* OpenGL gang, bringing all the goodies of {{< gh-hovercard "9913" "AccelerateDMA," >}} which we discussed in the [last report](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2023/#project-yfc-175).
|
||||
|
||||
This means that OpenGL users, especially those with Fermi and Kepler GPUs, can enjoy the speed boost of this pseudo-Y.F.C. 2 change, making games such as `Metroid Prime Remastered` run much faster.
|
||||
No more waiting for Samus to load her arm cannon.
|
||||
|
@ -120,14 +120,14 @@ Your writer observes a 3-5% performance increase in `The Legend of Zelda: Breath
|
|||
"./botw.png| From 54 to 57 FPS in one of the heaviest spots in the game, OpenGL still has life in it! For now… (The Legend of Zelda: Breath of the Wild)"
|
||||
>}}
|
||||
|
||||
bylaws came to the rescue again, pointing out that our old Vulkan scheduler implementation had some regressions [back in October](https://yuzu-emu.org/entry/yuzu-progress-report-oct-2022/#graphics-and-general-bug-fixes) of last year, when [byte[]](https://github.com/liamwhite) worked on making homebrew apps work with Vulkan.
|
||||
bylaws came to the rescue again, pointing out that our old Vulkan scheduler implementation had some regressions [back in October](https://yuzu-mirror.github.io/entry/yuzu-progress-report-oct-2022/#graphics-and-general-bug-fixes) of last year, when [byte[]](https://github.com/liamwhite) worked on making homebrew apps work with Vulkan.
|
||||
|
||||
This meant that games and homebrew would have to wait for a frame to show up on screen before starting to render, which in some cases is a bad example of feedback looping at its worst.
|
||||
|
||||
By {{< gh-hovercard "9931" "waiting in the background" >}} for the queue to be emptied without having to wait for the frame to be presented, byte[] fixed the regression.
|
||||
Thanks bylaws!
|
||||
|
||||
Remember that lovely game we talked about [last month?](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2023/#other-gpu-and-video-changes)
|
||||
Remember that lovely game we talked about [last month?](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2023/#other-gpu-and-video-changes)
|
||||
The one for all ages! Totally safe to play with your family.
|
||||
|
||||
[vonchenplus](https://github.com/vonchenplus) decided to make it playable, so ~~weebs~~ players around the world could enjoy the amazing gameplay of `Moero Crystal H`, by {{< gh-hovercard "9943" "fixing" >}} some errors in how yuzu processed the inline index and draw texture commands.
|
||||
|
@ -163,7 +163,7 @@ We need more information to fully understand the issue, but for now, {{< gh-hove
|
|||
"./xcfix.png"
|
||||
>}}
|
||||
|
||||
The other long-standing issue affecting the Xenoblade trilogy (well, Definitive Edition and 2 at least) has been plaguing yuzu since the legendary [Texture Cache Rewrite](https://yuzu-emu.org/entry/yuzu-tcr/).
|
||||
The other long-standing issue affecting the Xenoblade trilogy (well, Definitive Edition and 2 at least) has been plaguing yuzu since the legendary [Texture Cache Rewrite](https://yuzu-mirror.github.io/entry/yuzu-tcr/).
|
||||
It was the random "rainbow mode" that could happen anytime during gameplay, or in a specific late-game cutscene in `Xenoblade Chronicles 2` that I won’t spoil for new players.
|
||||
If you played it in yuzu, you know which one.
|
||||
It makes you wonder if you’re in [Rapture](https://tvtropes.org/pmwiki/pmwiki.php/VideoGame/Bioshock).
|
||||
|
@ -179,7 +179,7 @@ Another observed problem was excessive lighting making the whole scene unreadabl
|
|||
>}}
|
||||
|
||||
Maide found that the issue was caused by {{< gh-hovercard "10004" "replacing" >}} fresh guest data with stale host data in the environment lighting cubemaps.
|
||||
The solution is to only copy data that has been marked as GPU-modified, following the behaviour of the [Buffer Cache Rewrite](https://yuzu-emu.org/entry/yuzu-bcr/).
|
||||
The solution is to only copy data that has been marked as GPU-modified, following the behaviour of the [Buffer Cache Rewrite](https://yuzu-mirror.github.io/entry/yuzu-bcr/).
|
||||
|
||||
{{< single-title-imgs-compare
|
||||
"This isn’t 2009, we don’t need this much bloom, thank you very much (Xenoblade Chronicles: Definitive Edition)"
|
||||
|
|
|
@ -14,7 +14,7 @@ stability improvements, bug fixes and graphical corrections.
|
|||
|
||||
## The worst kept secret
|
||||
|
||||
It has its own [article](https://yuzu-emu.org/entry/yuzu-prometheus/), and it had been guessed to hell and back before the official announcement.
|
||||
It has its own [article](https://yuzu-mirror.github.io/entry/yuzu-prometheus/), and it had been guessed to hell and back before the official announcement.
|
||||
`Project Prometheus` is a proper multithreaded emulation of the 4 CPU cores the Nintendo Switch offers.
|
||||
This brings a massive performance boost to users with CPUs with 4 physical cores or more, but for this to happen, a lot of groundwork was needed.
|
||||
Besides changes previously discussed in past reports, old external libraries (which yuzu needs to operate) needed to be updated,
|
||||
|
@ -30,7 +30,7 @@ compared to the previous 2 or 3. You should expect a performance boost in a lot
|
|||
|
||||
Now, some clarifications are needed for this change. Multicore support can’t be merged into our [Mainline](https://github.com/yuzu-emu/yuzu-mainline) release for now due to incompatibilities between Multicore and the [Master](https://github.com/yuzu-emu/yuzu) branch of yuzu. Work is being done to resolve the conflicts, but please have patience.
|
||||
Additionally, users with 2 cores, and either 2 or 4 threads, should not enable multicore as it will most likely result in a performance
|
||||
loss for them due to the lack of physical cores on their CPUs. Our [hardware recommendations](https://yuzu-emu.org/help/quickstart/#hardware)
|
||||
loss for them due to the lack of physical cores on their CPUs. Our [hardware recommendations](https://yuzu-mirror.github.io/help/quickstart/#hardware)
|
||||
have been updated accordingly.
|
||||
|
||||
## Unreal Engine fixes
|
||||
|
|
|
@ -15,7 +15,7 @@ We have dozens of changes to discuss: Kernel fixes, input and UI improvements, g
|
|||
|
||||
`New Pokémon Snap`’s release resulted in tons of work needed to make the game playable. For starters, Snap experienced crashes during gameplay,
|
||||
an issue [epicboy](https://github.com/ameerj) was not happy about.
|
||||
The [buffer cache rewrite](https://yuzu-emu.org/entry/yuzu-bcr/) introduced an optimized fast path for `uniform bindings`, but the conditions to take advantage of it are that buffers must be both small and *non-null*. Turns out,
|
||||
The [buffer cache rewrite](https://yuzu-mirror.github.io/entry/yuzu-bcr/) introduced an optimized fast path for `uniform bindings`, but the conditions to take advantage of it are that buffers must be both small and *non-null*. Turns out,
|
||||
null buffers were not being explicitly checked for, causing instabilities along the way.
|
||||
[Properly checking for those zero sized buffers](https://github.com/yuzu-emu/yuzu/pull/6322) fixed the stability issues the new Snap was facing.
|
||||
|
||||
|
@ -46,7 +46,7 @@ something epicboy had no problem properly implementing for us.
|
|||
"./blits.png| Here’s a beautifully detailed example of the old out-of-bounds incorrect behaviour in red, and the correct result in blue, with the affected area moving to the next row, as it should"
|
||||
>}}
|
||||
|
||||
The result is quite noticeable in games that use this blit technique, such as `Shantae` and `Pixel Game Maker Series Werewolf Princess Kaguya`, which we mentioned in the [previous progress report](https://yuzu-emu.org/entry/yuzu-progress-report-apr-2021/).
|
||||
The result is quite noticeable in games that use this blit technique, such as `Shantae` and `Pixel Game Maker Series Werewolf Princess Kaguya`, which we mentioned in the [previous progress report](https://yuzu-mirror.github.io/entry/yuzu-progress-report-apr-2021/).
|
||||
|
||||
{{< single-title-imgs
|
||||
"Textures and text rendering correctly, notice the stairstepping on the right side of the left image"
|
||||
|
@ -259,7 +259,7 @@ toastUnlimited reluctantly [added the CPU tab to per-game settings.](https://git
|
|||
While we’re on this subject, some things need to be clarified about the CPU settings tab.
|
||||
Unsafe was originally only intended for CPUs that lacked the FMA instruction set, which causes games to run at very low framerates.
|
||||
Later on, a fix was discovered that could boost the performance of `Luigi’s Mansion 3` by reducing precision. This was described in
|
||||
[January’s progress report.](https://yuzu-emu.org/entry/yuzu-progress-report-jan-2021/)
|
||||
[January’s progress report.](https://yuzu-mirror.github.io/entry/yuzu-progress-report-jan-2021/)
|
||||
|
||||
As a result, we recommend users of CPUs that do have FMA to stick to `Accurate` and only force `Unsafe` for `Luigi’s Mansion 3`.
|
||||
Using `Unsafe` is known to cause precision issues, for example, exaggerating the hitboxes of characters in `Super Smash Bros. Ultimate`.
|
||||
|
|
|
@ -14,7 +14,7 @@ Greetings yuz-ers. This time around, we're covering small and incremental improv
|
|||
|
||||
Let’s first address the elephant in the room, shall we?
|
||||
|
||||
While working on dynarmic and kernel emulation, including improving the compatibility of 4 thread CPU systems, we made changes to [dynarmic](https://github.com/merryhime/dynarmic) and [fastmem](https://yuzu-emu.org/entry/yuzu-fastmem/) that broke support for Windows 10 revision 1803 and older, including Windows 7 and Windows 8/8.1.
|
||||
While working on dynarmic and kernel emulation, including improving the compatibility of 4 thread CPU systems, we made changes to [dynarmic](https://github.com/merryhime/dynarmic) and [fastmem](https://yuzu-mirror.github.io/entry/yuzu-fastmem/) that broke support for Windows 10 revision 1803 and older, including Windows 7 and Windows 8/8.1.
|
||||
|
||||
While fastmem was only ever designed to work with newer operating systems, the changes to dynarmic breaking support for older Windows versions was purely accidental.
|
||||
That being said, it is yet another sign of the times, and that a pre-Windows 10 experience in yuzu will continue to become more subpar.
|
||||
|
@ -33,7 +33,7 @@ For those that still prefer to not upgrade, [Mainline 990](https://github.com/yu
|
|||
|
||||
## Vulkan by default
|
||||
|
||||
[As previously discussed](https://yuzu-emu.org/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future), we have to circumvent issues like OEM-locked drivers (so common on Intel hardware, [it has its own official procedure](https://www.intel.com/content/www/us/en/support/articles/000056629/graphics.html)) and broken third party software limitations (outdated screen recorders are a common cause of broken rendering) in order to provide a smooth experience with Vulkan as the default API.
|
||||
[As previously discussed](https://yuzu-mirror.github.io/entry/yuzu-progress-report-feb-2022/#vulkan-is-the-future), we have to circumvent issues like OEM-locked drivers (so common on Intel hardware, [it has its own official procedure](https://www.intel.com/content/www/us/en/support/articles/000056629/graphics.html)) and broken third party software limitations (outdated screen recorders are a common cause of broken rendering) in order to provide a smooth experience with Vulkan as the default API.
|
||||
|
||||
The two main causes for Vulkan related crashes when trying to boot a game or opening yuzu’s configuration are:
|
||||
|
||||
|
@ -83,7 +83,7 @@ This process works by writing the pitch image data into GPU memory accessible by
|
|||
"./dmafix.png"
|
||||
>}}
|
||||
|
||||
byte[] also improved the way OpenGL interprets face flips depth, [replacing the previously reported fix](https://yuzu-emu.org/entry/yuzu-progress-report-apr-2022/#saving-princess-peach-yet-again).
|
||||
byte[] also improved the way OpenGL interprets face flips depth, [replacing the previously reported fix](https://yuzu-mirror.github.io/entry/yuzu-progress-report-apr-2022/#saving-princess-peach-yet-again).
|
||||
The face flips used by Super Mario 3D All-Stars and the Nintendo 64 emulation are an uncommon configuration on the GPU.
|
||||
The previous implementation had bad rendering in OpenGL, a complete black screen.
|
||||
|
||||
|
|
|
@ -37,7 +37,7 @@ Let’s begin with the most complex problem the Princess introduced the project
|
|||
As there isn't a single dedicated desktop or laptop graphics card that supports the native decoding of [ASTC textures](https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression) (with the exception of Intel iGPUs), yuzu is forced to transcode them on the fly into a safe and lossless format that all GPUs support; in this case, the `RGBA8` format.
|
||||
|
||||
This was perfectly fine until now (even on 2GB GPUs), since `ASTRAL CHAIN` was the only game that made "extensive" use of ASTC textures, shipping with 4K textures on a mobile device intended for 1080p and 720p screen resolutions.
|
||||
Our garbage collector, introduced two years ago with [Project Hades](https://yuzu-emu.org/entry/yuzu-hades/), which our veteran users know as “the memory Reaper”, was tuned for this worst case scenario at the time.
|
||||
Our garbage collector, introduced two years ago with [Project Hades](https://yuzu-mirror.github.io/entry/yuzu-hades/), which our veteran users know as “the memory Reaper”, was tuned for this worst case scenario at the time.
|
||||
|
||||
But what happens if a game with many more textures and a teletransportation system that allows the player to reach different regions in-game (and, in turn, load a truckload of new, different textures) releases?
|
||||
What if this hypothetical game made use of dozens and dozens of huge ASTC textures?
|
||||
|
@ -140,7 +140,7 @@ And for integrated GPU users with 16GB of system RAM or less, such as the Steam
|
|||
"./astcfix.mp4"
|
||||
>}}
|
||||
|
||||
That wraps up the list of changes made to memory management to allow `Tears of the Kingdom` to be playable in at least the components listed in our [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements).
|
||||
That wraps up the list of changes made to memory management to allow `Tears of the Kingdom` to be playable in at least the components listed in our [hardware requirements](https://yuzu-mirror.github.io/help/quickstart/#hardware-requirements).
|
||||
|
||||
These changes would not be necessary if GPUs just supported ASTC textures.
|
||||
Wouldn't you like your games to be no bigger than 100GB instead of having software features that ruin image quality, such as frame generation?
|
||||
|
@ -255,7 +255,7 @@ We’re following one of the most important rules of coding, “Make it work. Ma
|
|||
|
||||
As this is a particularly popular game (and for good reason), here are some recommendations that user reports and fixes have taught us.
|
||||
|
||||
- This game is very demanding on hardware. What we list in yuzu’s `recommended` [hardware requirements](https://yuzu-emu.org/help/quickstart/#hardware-requirements) is the minimum needed to sustain 30 FPS in most areas. A 6-core desktop Zen 2/11th gen Core, 16GB of RAM, and a GPU with at least 6GB of VRAM are the baseline for now.
|
||||
- This game is very demanding on hardware. What we list in yuzu’s `recommended` [hardware requirements](https://yuzu-mirror.github.io/help/quickstart/#hardware-requirements) is the minimum needed to sustain 30 FPS in most areas. A 6-core desktop Zen 2/11th gen Core, 16GB of RAM, and a GPU with at least 6GB of VRAM are the baseline for now.
|
||||
- The latest CPUs (Zen 4/13th gen Core, always speaking of desktop products) provide massive improvements in IPC, RAM bandwidth, and cache sizes. Where a Ryzen 7 5800X3D barely manages 55 FPS, a Ryzen 5 7600 reaches 90 FPS.
|
||||
- Normal GPU accuracy can be used to improve performance safely.
|
||||
- Unsafe CPU accuracy can improve performance at the cost of small inaccuracies.
|
||||
|
@ -274,9 +274,9 @@ As this is a particularly popular game (and for good reason), here are some reco
|
|||
|
||||
{{< gh-hovercard "10508" "Bet you didn’t expect this." >}}
|
||||
|
||||
That’s right, with the blessing from Skyline’s [bylaws](https://github.com/bylaws), help from Dolphin’s [t895](https://github.com/t895) and Citra’s [GPUCode](https://github.com/GPUCode), work from yuzu’s and Citra’s [flTobi](https://github.com/FearlessTobi), [bunnei](https://github.com/bunnei), [Merry](https://github.com/merryhime), [Flamboyant Ham](https://github.com/Schplee), [german77](https://github.com/german77), and more, yuzu is now [available for Android devices](https://yuzu-emu.org/downloads/#android)!
|
||||
That’s right, with the blessing from Skyline’s [bylaws](https://github.com/bylaws), help from Dolphin’s [t895](https://github.com/t895) and Citra’s [GPUCode](https://github.com/GPUCode), work from yuzu’s and Citra’s [flTobi](https://github.com/FearlessTobi), [bunnei](https://github.com/bunnei), [Merry](https://github.com/merryhime), [Flamboyant Ham](https://github.com/Schplee), [german77](https://github.com/german77), and more, yuzu is now [available for Android devices](https://yuzu-mirror.github.io/downloads/#android)!
|
||||
|
||||
We recommend that you read the dedicated yuzu on Android article [here](https://yuzu-emu.org/entry/yuzu-android/).
|
||||
We recommend that you read the dedicated yuzu on Android article [here](https://yuzu-mirror.github.io/entry/yuzu-android/).
|
||||
In this section, we will give you an overview of our future plans, some tips on settings and hardware requirements, and a realistic outlook on what you can expect from yuzu on Android right now.
|
||||
|
||||
The Android version of yuzu was not an easy feat. It took us almost eight months of hard work to make it happen.
|
||||
|
@ -422,7 +422,7 @@ It is also compatible with Adreno 600 series hardware, so it’s a simple global
|
|||
|
||||
There have been reports of users not being able to load custom drivers — we are still investigating this, but there's still a lot of work to do.
|
||||
|
||||
For those interested in playing with the source, we have a work-in-progress build guide [here](https://yuzu-emu.org/wiki/building-for-android/).
|
||||
For those interested in playing with the source, we have a work-in-progress build guide [here](https://yuzu-mirror.github.io/wiki/building-for-android/).
|
||||
|
||||
That’s all fo… What do you mean there’s still a whole article to write?
|
||||
Oh right, we have more to talk about!
|
||||
|
@ -771,7 +771,7 @@ We hope the 16GB version at least comes equipped with GDDR6X VRAM, which would i
|
|||
|
||||
### AMD
|
||||
|
||||
AMD has shown steady progress with each new driver release and, thanks to this, the experience on yuzu is in very good shape for Radeon owners, besides some documented hardware limitations causing graphical issues we've mentioned [in the past](https://yuzu-emu.org/entry/yuzu-progress-report-apr-2023/#amd-delivering-on-their-promises).
|
||||
AMD has shown steady progress with each new driver release and, thanks to this, the experience on yuzu is in very good shape for Radeon owners, besides some documented hardware limitations causing graphical issues we've mentioned [in the past](https://yuzu-mirror.github.io/entry/yuzu-progress-report-apr-2023/#amd-delivering-on-their-promises).
|
||||
|
||||
The main exception is a rendering issue affecting `Tears of the Kingdom`, which only happens with RDNA3 hardware, the RX 7000 series.
|
||||
|
||||
|
|
Loading…
Reference in a new issue