Cemu Emulator Plans For 2022 With Going Open-Source, Aiming For Linux Support

[phoronix]

Phoronix: Cemu Emulator Plans For 2022 With Going Open-Source, Aiming For Linux Support

Cemu as one of the leading Nintendo Wii U video game emulators is planning to go open-source this year and is also working on Linux support and related cross-platform advancements...

https://www.phoronix.com/scan.php?pa...emu-2022-Plans

[Danny3]

Good!
But why was it closed source in the first place, you had to pay to use it?

[mhalano]

You have my sword on that.

[HD7950]

Too late. You can play the best Wii-U games using Yuzu.

[Leopard]

Too late. You can play the best Wii-U games using Yuzu.

Yuzu is a Switch emulator, not Wii-U.

[qlum]

Good!
But why was it closed source in the first place, you had to pay to use it?

They basically have a patreon early access model where patreon supports get a version one week earlier.
I also think their motivation had something to do with not wanting to accept contributions at an earlier stage.
Especially distancing themselves from the mess of versions dolphin has become. Or at least this is what I remember from back when I was following cemu.

[tildearrow]

Good!
But why was it closed source in the first place, you had to pay to use it?

It was because according to the team they didn't want contributions from random people. Here:

I have a very strong vision on how the future of Cemu should look like. This includes potential contributors with whom I am already in talks with. I believe that for speedy progress, a small team of long-term, dedicated and skilled team members is better than a big team of temporary contributors. Why? Because every contributor first has to acquire the necessary knowledge about the emulated system. More knowledge means more effective emulator development since a lot of time can be saved by 1) fixing bugs faster 2) implementing features correctly on first attempt. For this approach open-source is simply not necessary. In fact, it is easier to get talented developers to join long-term when their name will have more meaning in the credits. I have also considered donation-driven development. It works very well for artists and comic authors, and I see it as a great incentive for emulator development too. But it would be problematic for a open-source project.

But of course there are other concerns as well, like development suddenly focusing on a direction which is not favorable to the original intentions of the emulator. Example: Focus on hacky solutions to get games into playable state earlier. I can see this happen in a open-source environment more likely, because piracy can become the main source for development motivation. Another example: Splatoon is moving towards playability fast, but online features are of low priority to avoid people using the emulator to cheat in online-play and ruin the experience for everyone. With open-source code there is no easy way to steer the development focus away.

Needless to say there are personal reasons as well. Like not wanting to lose control over the project and being slightly reluctant to share the code with people who have no respect for the effort and time it took to get this far. Not to mention the 1000 messages I received along the lines of "This emulator is doomed when it doesn't go open-source". It makes me want to prove them otherwise.

Oh and as I already stated, if development on Cemu gets stuck for a long period of time or if it is abandoned, the source code will be released anyway. I agree with the sentiment that the knowledge should not go to waste.

[bachchain]

There were rumors early on that CEMU used copyright/stolen work to accelerate its development and being closed source was an attempt to hide that.

[monkeynut]

There were rumors early on that CEMU used copyright/stolen work to accelerate its development and being closed source was an attempt to hide that.

If that's the case it reads more like "We'll release the source when we finish the rewrite".

[tildearrow]

Let's respond to the roadmap:

LLVM as a CPU JIT backend

This wouldn't be a good idea, even if LLVM outputs faster code than the custom recompiler.
Reason is because LLVM is not optimized for compilation times which means that unless ahead of time compilation is employed, this may lead to increased stutter and lag spikes.
ACO vs. LLVM benchmarks prove this.

Software fallback for H.264 decoding

I am surprised this has not been done yet, and the fact this uses a Windows-specific approach is more surprising.
Assuming there aren't any other weird details, FFmpeg would be a good option (plus it still has hardware decoding paths).

Cubeb audio backend

Yep. It will benefit Linux as well since Cubeb is able to use JACK.

Linux port

I agree. You may also harness the power of GCC/Clang which honestly are faster than Microsoft's C compiler.

Upgrading to modern C++, switching to makefile

A good solution is to use CMake. It generates Makefiles, Visual Studio projects and even Ninja build files (and Ninja has demonstrated faster build times than Make).
It will save you the trouble of having to deal with every possible build environment.

Going open-source

If you do open the code, please don't make it code drop open-source as it would prevent useful contributions from being made and takes away the "community" style of it.
ProtonMail for Android and SNES Tracker are two examples of code drop open-source in where all development happens in a bubble nobody can look at and it's terrible.
I am mentioning this since you do use the Patreon early access model...

A new shader decompiler

What? The shader recompilation approach is Wii U to GLSL to SPIR-V?!

Compatibility with all games

The fact you are able to run a great number of games is amazing already.