While a lot of our focus goes into the core emulation experience, we also recognize how important it is for users to be able to use the emulator. Dolphin now has several different User Interfaces (UIs) that are used across several platforms. A UI serves many purposes at the same time: from giving users access to the most important options, to relaying information to the users as they're using the program, and sometimes even communicating to developers what the program is doing at a given time.

Dolphin's Qt UI has been something we've teased on the Progress Report again and again without much of a payoff. This time it's different! We promise. In fact, The Qt UI is complete enough right now that many users could use it without major sacrifices. spycrab has lead the charge, banging through the todo list and checking them off one by one. Along with other contributors working on specific features, Dolphin's Qt UI saw a huge burst of activity this month!

While Qt is the most complete that it's ever been, it's still a comparatively new front-end and much less tested than the wxWidgets UI, and it's still not feature complete. As such, if you give it a try you may run into bugs, missing options, and other issues.

The Qt GUI is really starting to come together.

So what's new? Tons of missing functionality, missing panes, and missing settings were added to the UI, filling it out and finally making it complete enough that some developers have moved to using it part-time or even full-time as their main desktop UI! One of the compromises made to help push the Qt UI through development was to try and recreate everything that wxWidgets had. That way, we weren't redesigning Dolphin while also moving to a new interface. That being said, some liberties were taken to right some obvious wrongs in the wxWidgets UI.

DolphinWX allows you to edit and add Action Replay codes directly in the UI. This makes sense. However, the Gecko Code pane right next to it only allows you to view what codes are in the INI file with no ability to edit or add, only download from a database. Because this was nonsensical, spycrab implemented Gecko Code editing into the Qt UI, meaning you can edit, add, and remove codes as you please!

Adding Gecko Codes has never been easier!Managing Gecko Codes no longer requires a text editor.

Some of the silliest things in DolphinWX are simply because it's been around for well over a decade. Some parts of the UI have been renovated and cleaned up over the years, and other parts of the UI are pretty recognizeable to the original releases of Dolphin. The Memory Card Manager hasn't really changed much at all over the years and features an incredible amount of buttons for the simple tasks it tries to do. It also has rigid limits and makes it extremely hard to see the full information about saves. Many users and developers overjoyously eschewed the use of the archaic tool with the advent of GCI folders.

Early Dolphin UI Design 101: More buttons = better.Qt GUI greatly simplifies things and allows for the window size to be freely modified

Greatly simplifying the Memory Card Manager makes it more usable for exporting and managing memory cards. Considering some features like Tool Assisted Movies and netplay can often rely on carefully constructed memory cards for determinism, DolphinQt offers a preview into a simpler future.

Also it displays the savefile icon animations which is pretty awesome.

Note: Some UI elements were slightly modified to work around minor bugs and fit into the article better. Also, Dolphin has problems interpreting some of the strings in the saves. This is a bug present in DolphinWX as well, and not specific to the Qt UI.

Android users have it rough when it comes to using Dolphin. The AArch64 JIT still has quite a few bugs, the GUI is missing many critical features, they're running Dolphin on weaker hardware and many times the GPU drivers just aren't as mature as what we're used to on desktop computers. Last month, we saw some critical features finally ported to Dolphin Android, including the much overdo addition of GameINI support. While it would have been easy for everyone to rest on their laurels, several developers made major changes that brought some more much needed features to Dolphin Android. There were so many changes that directly impacted Dolphin Android this month that we probably could have put together a progress report for Android alone!

Most people think that the big problem with Dolphin Android is that phones are too slow, drivers are buggy, and Dolphin's AArch64 JIT just isn't mature enough to run games well. While all of those things have some truth, when one of Dolphin's biggest testers finally got an Android phone capable of using Dolphin, he was shocked at the state of things.

His phone, featuring a SnapDragon 835 gave him speeds that were more than playable in the games he was trying to use. The problem actually came from everything around emulation. He had complaints about flaws in the touchscreen controls, missing UI options, and other non-emulation issues. But by far his biggest complaint was struggling through a platforming section on the touchscreen controls only to lose it because he actually hit one of the Android System buttons to open up another app or minimize Dolphin. Let's just say, coming back to Dolphin after something like that usually meant your game was gone.

That, is what chased him from seriously using Dolphin Android - it was too hard to make progress in a game, and even when he did, one slightly off touch and the game could be gone. While saving every room in The Legend of Zelda: The Wind Waker will keep items, the game still resets the player to the beginning of a dungeon forcing you to traverse your way back to where you were.

mahdihijazi crafted a simple, yet elegant solution for this problem. In Android, Dolphin will now use a special savestate slot whenever you switch apps. If you return to Dolphin and for any reason the game was stopped, rather than losing everything, Dolphin will reload that savestate, potentially protecting you from losing hours of progress.

This may sound relatively minor for our desktop users, but for those using Android, this is a big one.

A series of very specific events allowed an extremely silly oversight to hit Dolphin Android. Firstly, we modified the way that WiiWare/Virtual Console titles were handled so that simply running them from the gamelist didn't corrupt the NAND. Now, if Dolphin didn't find the title installed on the NAND, it would install it to a temporary part of NAND, much like how Super Smash Bros. Brawl installed the Masterpieces. Secondly, Dolphin would let users know if they were going to install a WAD not signed by Nintendo. To launch those WADs, you'd need to hit "Yes" on the PanicAlert. This usually was nothing to worry about as older dumpers would fakesign the WADs anyway.

Where does this come to Android? Well, Android didn't have PanicAlerts! That's right, we unwittingly disabled the ability to boot WADs on Dolphin Android! Dolphin wouldn't proceed without user input, and the user had no way to actually input an answer! 34will quickly whipped up PanicAlert support for Android so that these WADs could be run on Android again. As a side note, other warnings and messages common in the desktop version of Dolphin should also pop up in Dolphin Android.

This is especially big news for Android users considering that many Virtual Console and WiiWare titles are extremely lightweight.

There are a few multi-disc GameCube games and one multi-disc Wii game. But, imagine you're an Android user suffering through the experimental nature of Dolphin on your phone only to get many hours into a game like Tales of Symphonia, Metal Gear Solid: Twin Snakes, or Resident Evil 4 only to be prompted to change disc. In the desktop versions of Dolphin, this is as simple as right clicking the disc you want to switch to and hitting "Change Disc." In Dolphin Android... you were stuck. If the game didn't allow you to save before changing disc, you had no way around it at all!

mahdihijazi again comes in big by adding support for Change Disc to the NVIDIA Shield T.V. and Mobile Android UIs. One of the reasons we know that Dolphin Android has serious users is that there was a sizeable number of complaints about this missing functionality. This means at least several users were not only playing games, but playing them far enough that they realized Dolphin Android was missing this functionality. Finally, those users can complete the final acts of their games.

This change isn't Android specific, but realistically only affects Android devices. GLES devices don't support blend_func_extended which Dolphin relied on for emulating GameCube dual-source blending. Instead, they relied on a fallback that was unceremoniously removed as part of cleanup. On top of being slow, this fallback was inaccurate and complicated the shader generation code, leading to more shaders, more context switching and more stuttering, especially since Ubershaders aren't a reasonable option on most Android devices. This is even more frustrating when we already know the Adreno hardware has the capability for blend_func_extended but doesn't expose it in the common drivers.

While desktop users continued on blissfully unaware, Android users were less than thrilled.

One day, users opened up games to find them too dark with no explanation.

Many, many months later, this wrong has finally been righted by JonnyH. He added support for dual-source blending through the shader_framebuffer_fetch extension that is commonly supported on GLES devices. While users may have had to deal with broken graphics for quite a while, the wait may have ended up being worth it. This new implementation is faster as we no longer have to split everything into two different draws and generates fewer shaders, which means less stuttering on these GPUs that aren't powerful enough for Ubershaders. All in all, while there was a slight delay, dual-source blending is once again working in the Android builds.

With all of these changes combined, Android for Dolphin is looking up! A lot of fixes to the GUI and configuration features added have left things in a much better state than before. As drivers improve and Dolphin on Android gets better, we may even see parity between Dolphin Android and the desktop builds!

...But there is still a long way to go.

On a more serious note, be warned there are a lot of fake Dolphin Emulator downloads on the Google Play Store. Considering the experimental state of Dolphin Android, we are not currently hosting any builds on the Play Store. Users will need to navigate to the download section and download the .apk files from there. While this is a bit of an inconvenience, very, very few phones actually support Dolphin, and a lot of users were getting confused as to why the App wouldn't install from the Appstore. The most common reason? We require AArch64 and GLES3, and while most new high-end phones do have 64-bit processors, many come installed with a 32bit environment.

It's rare enough to see both Android and Qt progress in one month, but add macOS to the mix and we have a truly special month. VinDuv noticed that the DolphinBar wasn't working in macOS Sierra/High Sierra and took to finding out why.

Dolphin uses a library called HIDAPI to communicate with Wii Remotes — which are Human Interface Devices (HID) — through the DolphinBar on all platforms. If all things were created equal, the DolphinBar should behave exactly the same on all of operating systems. Yet, macOS users updating to Sierra were in for a rude awakening when their DolphinBars suddenly stopped working. What happened?

For some reason, IOKit changed the device location values, which made all four HIDs exposed by a DolphinBar have the same device path. As Dolphin relies on paths being unique to identify remotes, it was unable to use more than one Wii remote. Even worse, because a DolphinBar always exposes four devices even with fewer than four remotes connected, the only way to use a remote was to configure Dolphin to use four Real Wii Remotes. But even after going through all this trouble, it'd only ever show up as Remote 4.

After realizing this was the problem, VinDuv modified the path building code in HIDAPI to use the unique IDs provided by IOKit. For users stuck on older versions of macOS, the old codepath will remain so that they can continue using the DolphinBar.

While using the unique IDs did allow Dolphin to correctly detect and connect to Wii Remotes in the latest versions of macOS, that wasn't the only problem VinDuv handled. Once a Wii Remote was connected, Dolphin was getting error codes spammed in the logs, pointing toward something going wrong. In fact, the behavior was mostly expected, but, of course another difference between the HIDAPI implementations was tripping Dolphin up. When the DolphinBar has fewer than four Wii Remotes connected, Dolphin expects there to be read errors for the missing Wii Remotes - but they're a specific read error with a specific error code. On macOS, for some reason this error code wasn't being set, so Dolphin didn't know what was going wrong!

VinDuv alleviated this problem by forcing the correct error code in this situation. After a lengthy delay, the DolphinBar now works as it should in the latest versions of macOS.

When the new custom texture format was implemented, we noted that Dolphin would auto-convert old custom textures to the new format for compatibility, but warned that this would be removed in the future. Fast-forward three years and we've finally, completely removed it. If any users or custom texture pack creators want to convert old textures to the new format in the future, we recommend using 5.0.

Without arbitrary mipmap detection, at extreme resolutions Dolphin REALLY liked foam!Custom textures were unable to reproduce the correct look, since they were excluded from the arbitrary mipmap heuristic.

Prior to this point, custom texture users had no way to reconcile this. They could have crisp, ultra high resolution textures, but games that relied on correct mipmaps would be broken. Now you can have your cake and eat it too, as Dolphin will preserve mipmaps on custom textures and mark them when dumping the original textures. This makes it easier than ever to have custom textures that enhance your favorite game without breaking the subtle effects that made them beautiful in the first place.

Do note that versions of Dolphin before 5.0-6199 will not properly display these effects with custom textures. If you're curious on any aspects of custom texture support, there is a forum thread details all of the intricacies of the feature on the Dolphin Forums.

Auto-Adjust Window Size is a classic Dolphin feature that scales Dolphin's rendering window to whatever size the Internal Resolution is set to. So if a game renders at 640x480 at 1x native, the window will be 640x480; if 1280x960 at 2x native, the window will be 1280x960, and so on.

However, after Hybrid XFB was merged, users started to notice Auto-Adjust Window Size behaving a bit oddly. 1x Native was fine, but if you set it to 2x Native or above, the window would become HUGE!

Auto-Adjust Window Size at 1x Native scales the window to 1x Native, as expected.When you set it to 2x Native, you really wanted a 5x Native window, right?

It turns out that after Hybrid XFB, Auto-Adjust Window Size was applying the scale factor to the already scaled size, so anything other than 1x Native became as large as it had room. Whoops.