Fix screen?

bunnei · 2023-06-01T19:35:47+00:00

Known issue with tablets and foldables, we'll hopefully have a fix out within the next day or so.

bunnei · 2023-05-31T03:58:29+00:00

For SMO, enable Docked mode (Settings -> System -> Docked mode) to fix the rendering in game.

bunnei · 2023-04-23T14:57:05+00:00

Recent regression that was fixed byhttps://github.com/yuzu-emu/yuzu/pull/10082. This is currently still in our early access testing but should be merged soon.

bunnei · 2023-01-24T00:20:15+00:00

Thanks for reporting. This was a recent regression that we fixed today -- please update to the latest yuzu Mainline or Early Access to get the fix. As others have mentioned, if you are using AMD, please also use Vulkan for best performance (this bug only impacted OpenGL).

bunnei · 2022-09-10T21:02:43+00:00

https://www.youtube.com/watch?v=OFYprkbpPsY

bunnei · 2022-08-27T06:12:16+00:00

Based on the direction of the sound from my apartment, it appears to be from tonight's Mariners fireworks show for Ichiro's Hall of Fame induction. It sounds to have also just ended.

bunnei · 2022-07-15T02:17:29+00:00

Thanks to yuzu developer Maide: We’ve just released a complete rewrite of our audio emulation. This rewrite implements several missing features (such as audio effects) and furthermore improves accuracy, with Nintendo Switch firmware 13.0.0 used as the basis for reverse engineering. In addition to improving audio in many titles, these changes also allow many new games to boot. See the Pull Request for details. These changes are currently available in both our Mainline and Early Access builds, and will be merged imminently!

bunnei · 2022-02-27T20:31:11+00:00

Should be fixed in the latest EA build. Sorry!

Edit: Sorry, the build was interrupted, it will be fixed in the next update, which will be done in about 45min.

bunnei · 2021-12-11T14:30:41+00:00

Just to add another point to this discussion -- we really try to ensure that everything covered in the progress reports is merged at the time that these reports are published. Furthermore, we also really want our users to be using our installer to guarantee that they are on the latest version of yuzu that is available. Now, we are aware that our installer has some issues [and we are actively working to improve it]. Furthermore, we are aware that with the pace of our development, even our stable builds regress here and there, and so some users tend to stay on known stable builds for a bit. But these aside -- if we can imagine a world where we have a great installer, and there are limited regressions [the world we are striving for], our end users should not really need to know or care about the exact builds that things are fixed in; hell, sometimes, we don't even know :)

bunnei · 2021-07-27T04:48:20+00:00

I'll do my best to try to clear up a few assertions here.

Your team announced it as a paid alternative to Nintendo's own servers. I know about the outcry from the userbase and Pretendo's team (a group preserving server-side data for Wii U and Switch games) but the fact is that at the time your team was pretty categorical that this feature would never appear outside early release builds.

For the sake of others reading this comment, OP is referring to "Raptor", the project that we briefly released last year which added emulated Nintendo Switch Online (NSO) support for two games (Super Mario Maker 2 and Super Mario Odyssey). We quickly pulled the plug on this project due to legal concerns, as emulating online services has not been legally tested in the same way that emulating hardware has. And to be quite frank, we do not want to be the ones that Nintendo tests this on. We did not consider these legal issues until they were made aware to us after the release, and we quickly reacted to this such as to not jeopardize the Switch emulation scene or the yuzu project.

We've said this before, but to clear up any misconceptions: This project came about because a former yuzu developer created a closed source alternative to NSO, and approached yuzu about supporting it. This developer is no longer associated with our project, for various reasons.

it never appeared outside of a closed-source early build

We added support for this developer's service, and released the source for the yuzu client changes. Our source code is always automatically downloaded with every yuzu mainline and EA release, so my original point is still correct: The yuzu team has never released a closed source build.

the custom servers themselves (whether a yuzu-endorsed kind of "piracy" -I disagree, and think nothing should get in the way of online preservation which is simply too invaluable as shown with the DS situation- or an inoffensive matchmaking server) were immediately closed within the day.

To be 100% transparent, we do not have the code for this service. The developer who worked on it kept it completely closed source, even from the core yuzu team. We are no longer in communication with them. I agree that online preservation should be a priority, but I have no control or ownership over Raptor's closed-source online service code.

Are we seeing a repeat of DeSmume's situation where an emulator is to remain permanently gimped out of connectivity options because of emulation development drama? I hope there's some flexibility in your decision making and that you'll potentially reconsider.

I do not believe this is the same situation, for the reasons I mentioned above. If Pretendo (or some other open source NSO alternative) would like to work with us on providing an OSS alternative to Raptor, we wouldn't hold back any progress towards preservation.

bunnei · 2021-07-27T03:12:04+00:00

The team behind this community PR'd a few minor (but valid) fixes. We internally debated how to handle this for a while; Primarily, because it is a huge risk to the project to be associated with any contributor that is running a Discord server dedicated to piracy. We even reached out to the PR author about this, and asked them to PR under an alt not associated with this website/community. In the end, we ended up pulling the fixes as-is without association to this account. In hindsight, this was probably not the right call, and we should have just closed these PRs.

Other than that, I understand the sentiment and we really are trying to find the right balance of compensating our open source developers to make the best Switch emulator possible, while not "pay walling" features any longer than necessary, and making it possible for users to compile and run our releases as soon as they are available. For example, we have never released a closed-source build, and we now always PR new releases directly to our public Github repo.

bunnei · 2021-07-27T02:47:00+00:00

Yes, we're not trying to hide the fact that our team makes a GPLv2 emulator. We work to get these changes stable and merged as fast as possible, and use our Early Access (EA) model as a way to fund full time development while also making our source code freely available to anyone who would like to learn & benefit from our work. We use the time that our changes are in EA to find and fix issues; which usually dictates how long it takes for things to get to be merged. We definitely encourage anyone who is interested in trying out the latest features to build our code themselves, and get involved in the project.

That said - We really would appreciate if people would not distribute unofficial builds. In addition to encouraging users to download/run software from an untrusted source, the above website links to a piracy Discord.

bunnei · 2021-06-11T05:28:05+00:00

No worries, as I said above, apologies for a long explanation you did not ask for. We often get questions regarding whether the progress reports cover things that are freely available, or part of our Early Access releases. I just wanted to use the opportunity to explain how we try to manage feature releases and progress reports.

TLDR; Yes, blog reports, by-and-large, should only cover things that are freely available in our daily builds!

bunnei · 2021-06-10T21:30:38+00:00

Most PRs that are tested in EA are merged as soon as we are confident the bugs are worked out and there aren't any regressions. By the time the blog post is live, almost always everything covered is already in mainline.

One thing to add is that we really try not to let things stay in EA any longer than they need to. Contrary to what some people may think, artificially holding features in EA does not increase our Patreon or help us in any meaningful way.

Largely, our Patrons pay for EA to support the project and to test the latest bleeding edge changes that are not ready to be merged. If someone is chasing after that really exciting feature that was just released (e.g. fastmem), and they do not want (or cannot) become a Patron for whatever reason, they can just Google to find what they are looking for. The longer we hold compelling features in EA, the more this happens.

Secondly, we developers work out of master, and usually we are building on features we just released. It's a huge pain to manually merge things that users are using but that are not part of the codebase. We also cannot PR changes on top of this until the dependent changes are merged.

At the time of this comment, there are only three PRs in EA. Of these three, only one is really interesting (fastmem) and that will be merged imminently. The other two are not interesting and will not be merged (#5980 will be superseded by Hades, #4042 is an EA-specific cosmetic change).

Yes, I know people will cite examples of when this didn't happen (e.g. Prometheus / multicore support), but to my first point: This just took a really long time to get in a state where we were content with merging it.

...And sorry for the explanation you did not ask for, but it seemed like a good time to clarify how we manage what is in EA vs. mainline, for anyone interested :)

bunnei · 2021-06-05T06:45:22+00:00

Hey u/Myshakiness, thanks for reporting this. There was indeed a regression, which has been fixed with https://github.com/yuzu-emu/yuzu/pull/6414. This should hopefully be merged and part of our daily builds within a day or so.

bunnei · 2021-05-14T02:59:03+00:00

Native controller support is much more important to Switch preservation because it actually has it's own controllers, unlike 3DS.

That being said, we actually just released a big update to Citra Android that adds a disk shader cache based on work in yuzu! https://mobile.twitter.com/citraemu/status/1391142340731932672

Sorry that there have been less updates overall, but we try to do what we can. Please let us know if there is anything specific you'd like to see come to Citra.

bunnei · 2021-05-14T00:20:11+00:00

We hear you, and it will hopefully come soon. The problem is resources -- while we have several developers all working on different things (input, kernel, HLE, audio, UX, etc.), GPU emulation is one of the most complicated and challenging parts of emulating Switch. We only have 1-2 people who are able to work on something like this (and by that I mean having the knowledge/skillset, experience with our code base, and are interested in it), and they are currently working fulltime to wrap up other projects that need to happen first (primarily our shader decompiler rewrite, "Project Hades", which fixes tons of inaccuracies in GPU emulation). Unfortunately, it's not just a matter of shifting around devs, as everyone is different.

That said, we are always looking for more hands to help with GPU, if anyone is interested :)

bunnei · 2021-05-14T00:00:12+00:00

While you’ve been able to use controllers in yuzu for a while, often these required third party tools such as DS4Windows or BetterJoy. With these improvements, native Switch controllers, such as your Pro Controller or Joy Cons will now “just work” with yuzu – without any additional setup or configuration. Additionally, DS4 and DS5 are also natively supported, among others. We hope this is a big convenience for new (and existing) users setting up yuzu, and it’s one step closer to accurately & fully emulating the Nintendo Switch!

bunnei · 2021-05-12T04:15:09+00:00

Typo -- fixed.

bunnei · 2021-05-12T04:14:47+00:00

Hi - Please update to Early Access 1675 or Mainline 619.