dolphin-emu.org - Entraes pa la serie Dolphin Progress Reporthttps://dolphin-emu.org/blog/series%23series-12024-02-11T07:03:49.869973+00:00Les caberes entraes pa la serie Dolphin Progress ReportZinniaDolphin Progress Report: November and December 2023, January 2024
2024-02-10T04:11:38+00:002024-02-11T07:03:49.869973+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2024/02/10/dolphin-progress-report-november-and-december-2023-january-2024/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/progressreportheader-january2024.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/progressreportheader-january2024mini.jpg" />
</header>
<p>With the conclusion of the holiday season, it's time for us at the blog to get back to work. And this time around, we have a smattering of changes covering just about everything you could imagine. For those looking to enjoy some of the latest homebrew with DSP-HLE, Dolphin now has support for the latest homebrew microcodes! For retail games, we also have a minor update to the Zelda-HLE microcode to fix a missing effect that's long overdue.</p>
<p>In some more important news, for those of you having disk space issues when running Dolphin on Windows since the last beta, a fix is now available. And for those looking for the clearest picture possible, Dolphin's mipmap heuristic has been backed down to allow for higher resolution mipmaps across more textures. And of course, if you're wanting that <em>perfect</em> image, Custom Aspect Ratios will allow for easier use of ultra-widescreen hacks and more!</p>
<p>Add to all of that a huge bugfix for <em>older</em> revision Steam Decks, another chapter in the Bounding Box saga, seeing a classic in an all new way, and <em>yet another chapter</em> in broken GPU drivers, and you've got yourself a Dolphin Progress Report.</p>
<p>Enjoy.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-20353-dsphle-support-2023-libaesnd-ucode-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20353/">5.0-20353 - DSPHLE: Support 2023 libaesnd uCode</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-20353-dsphle-support-2023-libaesnd-ucode-by-pokechu22" title="Permanent link">¶</a></h4>
<p><em>libasnd</em> and <em>libaesnd</em> are open source DSP microcodes for the GameCube and Wii, and are the standard DSP microcodes used by homebrew. When <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> <a href="https://dolphin-emu.org/blog/2022/07/07/dolphin-progress-report-may-and-june-2022/#50-16730-add-hle-version-of-libasnd-by-pokechu22">reimplemented the libasnd</a> <a href="https://dolphin-emu.org/blog/2022/09/13/dolphin-progress-report-july-and-august-2022/#50-16991-dsp-hle-implement-support-for-libaesnd-microcode-by-pokechu22">and libaesnd microcodes</a> in DSP-HLE back in 2022, we knew that if they were to ever be updated, the new versions would not automatically work in DSP-HLE. This is due to how DSP-HLE itself works - rather than emulating the DSP hardware and running the microcodes directly, DSP-HLE runs reimplementations of the microcodes themselves, made in C++. Thanks to a <a href="https://dolphin-emu.org/blog/2014/11/12/the-rise-of-hle-audio/">tremendous amount</a> <a href="https://dolphin-emu.org/blog/2015/08/19/new-era-hle-audio/">of work</a>, this is just as accurate as the hardware-emulating DSP-LLE, yet <em>many times faster</em>. However, since DSP-HLE doesn't actually run the microcodes, Dolphin checks the hash of the microcode in the game to know what to use. If the hash of the game's microcode doesn't match any of the reimplemented microcodes, DSP-HLE will fallback to the reimplemented AX microcode, and in the case of homebrew <em>probably not emit any sound at all.</em></p>
<p>This occurred in 2023, when libaesnd saw an update to address a few minor issues. These small fixes meant a new microcode version with a brand new hash which Dolphin did not recognize, resulting in audio not working under DSP-HLE in titles that used the new version of libaesnd. Specifically, it was the latest versions of the <a href="https://github.com/Mefiresu/RSDKv5-Decompilation">Sonic Mania Wii decompilation port</a> that brought this update to our attention. As a fairly new project in active development, they are consistently updating their microcodes, and they are the first software we are aware of to use the new updates.</p>
<p>Thankfully, the updates to libaesnd were relatively minor and <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> mostly just had to document what was changed and add the 2023 hash to the libaesnd code paths in DSP-HLE. With that, users can enjoy Mania's Chemical Plant Zone theme in DSP-HLE once again!</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/sLlOtAYekuQ" allowfullscreen></iframe></div>
<figcaption>Sonic Mania running in Dolphin, with sound in DSP-HLE!</figcaption>
</figure>
</div>
<h4 id="50-20880-zelda-hle-fix-reverb-volume-factor-by-flacs"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20880/">5.0-20880 - Zelda-HLE: Fix Reverb Volume Factor</a></strong> by <strong><a href="https://github.com/Tilka">flacs</a></strong><a class="headerlink" href="#50-20880-zelda-hle-fix-reverb-volume-factor-by-flacs" title="Permanent link">¶</a></h4>
<p>Sticking to the theme of DSP-HLE, we have a microfix from longtime contributor <strong><a href="https://github.com/Tilka">flacs</a></strong>. This in particular targets the missing reverb effects noticed in <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart Double Dash!!</a>. These effects were noted to be broken <a href="https://bugs.dolphin-emu.org/issues/8034">way back in 2015</a> but was marked as low priority amidst a massive Zelda-HLE rewrite. When the rewrite was complete, this bug remained as a minor issue.</p>
<p><strong><a href="https://github.com/Tilka">flacs</a></strong> returned and has been hammering down bugs in all quadrants. This one turned out to be rather simple. The reverb volume was erroneously being multiplied by current volume twice, resulting in the effect becoming incredibly quiet. While the bug reporters originally thought the reverb was missing, they actually just weren't listening hard enough for it!</p>
<p>Once this oversight was fixed, the effect started working as intended.</p>
<h4 id="50-20517-implement-send-mail-by-sketch"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20517/">5.0-20517 - Implement Send Mail</a></strong> by <strong><a href="https://github.com/noahpistilli">Sketch</a></strong><a class="headerlink" href="#50-20517-implement-send-mail-by-sketch" title="Permanent link">¶</a></h4>
<p>Have you ever had an important work email that you needed to send <em>right now</em> but all you had at your disposal was an emulated Wii? This is a position I think we can say every single one of us have been at some point, but unfortunately in the past there was nothing you could do about it.</p>
<p>Thankfully, <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> took note of the plight of our users and has been slowly working through the Wii Mail system, and while it's not entirely complete, those registered with the WiiLink service can send messages to other Wiis and even emails directly from Dolphin!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/IMPORTANTWORKEMAIL.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/IMPORTANTWORKEMAIL_thumb.jpg"></a>
<figcaption></figcaption>
</figure>
</div>
<p>To get to this point, it's been a rather long ride, and <em><a href="https://dolphin-emu.org/blog/2022/12/21/dolphin-progress-report-september-october-november-2022/#50-17613-implement-missing-features-for-wiiconnect24-support-by-noahpistilli">a ton of</a> <a href="https://dolphin-emu.org/blog/2023/08/13/dolphin-progress-report-may-june-and-july-2023/#50-19274-add-wiiconnect24-support-via-wiilink-by-sketch">the legwork</a></em> was already done for WiiConnect24 emulation. Soon, we're hoping to have full parity between using WiiLink on a console and Dolphin, though there are still some missing features on the Dolphin side of things.</p>
<h4 id="50-20589-rewrite-lazymemoryregion-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20589/">5.0-20589 - Rewrite LazyMemoryRegion</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-20589-rewrite-lazymemoryregion-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:20%; min-width:200px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/WindowsLogo1991.svg">
</div>
<p>Last Progress Report, we described a performance optimization that had the annoying side effect of <a href="https://dolphin-emu.org/blog/2023/11/25/dolphin-progress-report-august-september-and-october-2023/#50-19415-and-50-20126-improve-jit-block-lookup-performance-by-krnlyng">taking up 32 GiB of disk space on Windows</a>. Now <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> has rewritten the code used on Windows to avoid side effects of this kind.</p>
<p>To summarize the problem from last time: Dolphin needed a 32 GiB memory allocation to efficiently keep track of where recompiled code was located. Most of it didn't need to be backed by real memory, but whenever Dolphin wanted to access a particular location, real memory had to be allocated on the fly so the access wouldn't fail. In the solution described in the previous Progress Report, we handled this by asking the operating system to allocate pages for us as needed. This worked well on almost every OS, but on Windows we ran into the problem that the system would force the page file to grow to match our huge 32 GiB allocation, in case we try to access all 32 GiB.</p>
<p>With the new solution, we're handling things more manually on Windows. <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong>'s initial idea was to mimic what the operating system was doing by setting up a signal handler that runs when Dolphin tries to access an address that isn't backed by real memory – something Dolphin is already doing for the tried and tested <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/">fastmem</a> optimization – and then allocating some real memory when the signal handler runs. But because Dolphin only writes to the 32 GiB region from two pieces of code, both of which run relatively infrequently, Progress Report reader <strong><a href="https://github.com/PJB3005">PJB3005</a></strong> was able to come up with a simpler solution that <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> then implemented. Instead of using a signal handler, Dolphin now manually checks if it needs to allocate any real memory before it writes to the 32 GiB region. Parts of the 32 GiB region that aren't yet backed by real memory are pointed to a read-only page filled with zeroes, so that nothing will go wrong if Dolphin tries to read from a location that hasn't been written to.</p>
<p>Now Dolphin users on Windows are able to benefit from the JIT Block Lookup performance optimization without worrying about Windows making their page file balloon. Issues like not being able to download large files while Dolphin is running will no longer occur.</p>
<p>On operating systems other than Windows, Dolphin is still using the old approach where the OS allocates real memory on the fly, since we've only seen problems with that approach on Windows.</p>
<h4 id="50-20745-disable-arbitrary-mipmap-detection-by-default-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20745/">5.0-20745 - Disable Arbitrary Mipmap Detection by Default</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-20745-disable-arbitrary-mipmap-detection-by-default-by-iwubcode" title="Permanent link">¶</a></h4>
<p>As part of the essential hack that is raising Internal Resolution, Dolphin adjusts the <a href="https://en.wikipedia.org/wiki/Mipmap">mipmap</a> level of textures. Mipmapping is the process of swapping to lower resolution versions of textures if they would appear too small in the final image. This is an old graphics staple - using maximum resolution textures everywhere leads to severe aliasing and moire on distant textures and textures at oblique angles. However, this is resolution dependent, and mipmap targets set for 480p will be intensely blurry at 4K. So Dolphin adjusts the mipmap levels to match the increased Internal Resolution, significantly improving overall texture quality of the final image.</p>
<p>However, some GameCube and Wii titles use mipmap shenanigans for effects, and by changing the mipmap levels, we were breaking these tricks. To have our high resolution cake and eat it too, <a href="https://dolphin-emu.org/blog/2017/11/03/dolphin-progress-report-october-2017/#50-5745-add-heuristic-for-detecting-custom-mipmaps-by-tomcc">in 2017 we added <em>Arbitrary Mipmap Detection</em></a>, a heuristic that attempts to detect mipmap mischief and drop to a more accurate mipmap implementation for only the textures involved in these effects. The result is that the specific textures used for these effects will be blurrier, but as it is correcting broken effects and should only affect the specific textures involved, it's a win win. Theoretically. </p>
<div class="media-block wider">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-october/galaxy2-oldnative.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-october/galaxy2-oldnative_thumb.jpg" /></a>
<figcaption>Galaxy 2 reads the mipmap level to control this fog effect in the sky. </figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-october/galaxy2-oldhighres.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-october/galaxy2-oldhighres_thumb.jpg" /></a>
<figcaption>Without Arbitrary Mipmap Detection, the fog is gone and the clouds repeat infinitely.</figcaption>
</figure>
</div></div>
<p>Unfortunately, this heuristic has proven to be problematic. It often has false positives, incorrectly detecting mipmaps as being used for effects and needlessly using blurrier versions.</p>
<div class="media-block wider">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2018-june/arcadiamipmaps-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2018-june/arcadiamipmaps-broken_thumb.jpg" /></a>
<figcaption>With Arbitrary Mipmaps, the back of the ship in <a href="https://wiki.dolphin-emu.org/index.php?title=Skies_of_Arcadia_Legends">Skies of Arcadia</a> is much blurrier than it should be.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2018-june/arcadiamipmaps-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2018-june/arcadiamipmaps-working_thumb.jpg" /></a>
<figcaption>Without Arbitrary Mipmap Detection, the ship is considerably crisper.</figcaption>
</figure>
</div></div>
<p>To account for this, in 2018 we added the <em>Arbitrary Mipmap Detection</em> toggle. On by default, this option gave anyone who was having trouble with the heuristic the ability to simply turn it off, and avoid any problems it may cause. It was a simple solution, and it has remained ever since.</p>
<p>Fast forward to late 2023, and <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> asked a question that shook us all: "how many games use arbitrary mipmaps for effects?" In the resulting back and forth, we realized the number of games that utilize mipmap hijinks is... not a lot. To our knowledge, only Nintendo used this technique. Of course these were games by <em>Nintendo</em>, titles that are flagships of the GameCube and Wii lineup, like <a href="https://wiki.dolphin-emu.org/index.php/Super_Mario_Galaxy">Super Mario Galaxy</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a>. However, by being such core titles, we realized that the importance of detecting these effects was overestimated. As far as we are aware, a couple dozen games use the trick, and <em>thousands</em> of games do not. Considering just how common and pernicious false positives are with the heuristic, having the heuristic on by default for every game was probably causing more harm than good.</p>
<p>So we have decided to change that. Arbitrary Mipmap Detection is now off by default. From now on it will only be enabled by default in known cases, via our GameINI system. If you happen to spot any issues that are resolved by turning on Arbitrary Mipmap Detection, please let us know and we'll add it to the list of known mipmap tomfoolery.</p>
<h4 id="50-20785-support-custom-aspect-ratios-by-filoppi"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20785/">5.0-20785 - Support Custom Aspect Ratios</a></strong> by <strong><a href="https://github.com/Filoppi">Filoppi</a></strong><a class="headerlink" href="#50-20785-support-custom-aspect-ratios-by-filoppi" title="Permanent link">¶</a></h4>
<p>Dolphin's Widescreen Hack is both amazing and terrible in equal measure. By expanding the <a href="https://en.wikipedia.org/wiki/Viewing_frustum">View Frustum</a>, it allows Dolphin to able to render any game at <strong>any</strong> aspect ratio, and thus fill <em>any screen</em> without stretching the image! However, the Widescreen Hack is only performed on the Dolphin side, and doesn't affect the game's logic at all. Frustum Culling, screenspace 2D graphics, and more are entirely unmodified. The result is large blank areas in the expanded space, stretched 2D elements, and aberrant pop-in are simply the reality of the Widescreen Hack.</p>
<p>Fortunately, we have an alternative - game-specific aspect ratio cheat codes. By editing the game itself through our cheat system, all of these quirks can be addressed and a much better result can be achieved.</p>
<p><div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/mp2-widescreenhack.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/mp2-widescreenhack_thumb.jpg" /></a>
<figcaption>Wasn't this room supposed to have walls?</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/mp2-actionreplaycodes.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/mp2-actionreplaycodes_thumb.jpg" /></a>
<figcaption>Through the power of action replay codes, geometry is no longer being culled and we don't have to worry about pop in!</figcaption>
</figure>
</div>
</div></p>
<p>However, aspect ratio codes require the user to configure their aspect ratio. For example, to run Ralf's 16:9 Aspect Ratio code for <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">Wind Waker</a>, a user must set Dolphin's aspect ratio to Force 16:9. Simple enough.</p>
<p>But what happens if your display is an UltraWide? 21:9 codes are fairly common, but there is no "Force 21:9" option. To work around this, 21:9 display users can set the aspect ratio to "Stretch to Window" and enter fullscreen. This does the job, but this has some issues. Ultrawide aspect ratios are less a standard and more of a <em>suggestion</em>, so even within the 21:9 category, the actual ratios vary. In the real world, our little workaround usually results in minor distortion.</p>
<p>But worse still is <strong><em>Super UltraWide</em></strong>. 32:9 aspect ratio codes are few and far between, making the workaround above unviable. The best option available for 32:9 users was to combine a 21:9 code, windowed mode, and Stretch to Window Size, then very carefully size the window so that there was no stretching. Not great.</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/329-windowed.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/329-windowed_thumb.jpg"></a>
<figcaption>This <em>works</em>, but you have to hide the Windows Taskbar, Windows will not let you move the titlebar of the window off screen if you don't have a secondary monitor, it's a lot of faff to set up, and it requires you to void your wallpaper for the best result. It's not a great experience.</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Filoppi">Filoppi</a></strong> decided that this will not do, and added a new <em>Custom Aspect Ratio</em> option to Dolphin. Using this feature, you can effectively force Dolphin's aspect ratio to whatever you want. Now, Super UltraWide screen users can enjoy 21:9 in fullscreen without any fuss or distortion! </p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/329-fullscreen.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/329-fullscreen_thumb.jpg"></a>
<figcaption>Set up a 21:9 code, configure a Custom Aspect Ratio of 21:9, and just enter fullscreen like normal! It's that easy!</figcaption>
</figure>
</div>
<p>Plus, this change allows any aspect ratio on any display, so if you have a 16:9 display and want to play 21:9 on your OLED TV or something, you can do that! In fact, if a theorectical retro port to the GameCube or Wii has an incorrect aspect ratio, this could even be used to correct it! We haven't actually found any of those yet, but it's an intriguing possibility.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/customaspectratioconfig.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/customaspectratioconfig_thumb.png"></a>
<figcaption>To use this feature, just set the Aspect Ratio to "Custom", and configure the ratio to whatever you like!</figcaption>
</figure>
</div>
<p>However, as we do whenever we give dangerous new powers to users, we must exit with a word of caution. <strong>The GameCube and Wii were never exactly 4:3, 5:4, or 16:9</strong>. Yes, <strong><em>on hardware.</em></strong> It was the days of analog displays and their crimes were all going to be <a href="https://en.wikipedia.org/wiki/Overscan">overscanned</a> away anyway, so game developers had no reason to care about being exact. Back when Dolphin assumed standard aspect ratios, every. single. game. was off to some degree. Remember the Melee shields?</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/#40-7138-pixel-aspect-ratio-adjustment-vi-scaling-fix-by-mirrorbender">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2015-july/meleeshield-broken_circle.jpg"></a>
<figcaption>This is the hell we used to live in.</figcaption>
</figure>
</div>
<p>This was a <em>tremendous headache</em> for us, and to resolve it required <strong>months</strong> of effort from very skilled engineers, testers, esports communities, and more. It was an enormous undertaking.</p>
<p>The result of all that work is that Dolphin reads the exact Aspect Ratio the game is instructing the console to scan out and displays precisely that. And to make sure users see it without distortion, all of our aspect ratio modes used these corrections, with only <em>Stretch to Window</em> bypassing it. Well, now there is a second way to bypass it. A Custom Aspect Ratio will give you exactly what you enter, no matter what. So if you are playing in ordinary 4:3 or 16:9, and you configure the custom aspect ratio to 4:3 or 16:9, you are bypassing Dolphin's aspect ratio adjustment and <em>you will be distorting the image in all cases</em>.</p>
<p>Please use this power responsibly.</p>
<p><em>PLEASE.</em></p>
<h4 id="50-20849-videocommon-apply-force-24-bit-color-to-efb-copies-by-flacs"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20849/">5.0-20849 - VideoCommon: Apply "Force 24-bit Color" to EFB Copies</a></strong> by <strong><a href="https://github.com/Tilka">flacs</a></strong><a class="headerlink" href="#50-20849-videocommon-apply-force-24-bit-color-to-efb-copies-by-flacs" title="Permanent link">¶</a></h4>
<p>"Force 24-bit Color" is an enhancement that reduces banding by forcing the emulated hardware to the highest bitdepth possible. However, there were some cases where turning on the enhancement <em>did not improve banding at all!</em> This change fixes that, but to explain why, <strong>we're going to have to get <em>technical</em>.</strong></p>
<p>To understand this problem, we need to go over how post-processing works on the GameCube and Wii. This first paragraph may be a little familiar, but bear with us. While rendering, the ArtX GPU in the GameCube and Wii rasterizes to the "Embedded Frame Buffer" (EFB), a 2MiB chunk of extremely fast working memory that resides in the GPU itself. While some basic post-processing can be applied while the frame is in the EFB, any effect that involves reading then distorting the frame cannot be done while it is in the EFB. So for most post-processing effects, games will execute an EFB Copy to transfer the frame to main memory, then read the frame as a texture from which to render again on top of. However, the consoles primarily render in 6-bits per channel RGBA6, but cannot read a texture in that format. To deal with this discrepancy, it is common for games to convert the frame to 8-bits per channel RGBA8 during the EFB Copy to maintain full visual quality.</p>
<p>However, a fullscreen image at RGBA8 is HUGE for this hardware. Assuming a 640x480 render target, that would be 9830400 bits, or 1.17MiB! And for post-processing effects, multiple renders need to be made! The GameCube's Main Memory is only 24MiB, and <em>the game</em> needs to live in that space too. So many games opt to EFB Copy some images into main memory in the RGB565 format. A 640x480 RGB565 image is only 4915200 bits in size, or 0.59MiB. That's half the size!</p>
<p>But of course, this came at a cost. Most games render in RGBA6. 6-bits per channel is 64 values per color, for 262144 total possible colors (ignoring the alpha channel). RGB565 has two channels at 5-bits (32 values per color), combining to a total of 65536 total possible colors. RGB565 has significantly fewer colors making banding much worse, and it is missing the alpha channel entirely, limiting its uses. However, when the benefit was <em>halving an image's RAM usage on a chronically memory-starved machine</em>, this was a option that many developers utilized.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#50-13242-final-fantasy-crystal-chronicles-mogmail-crash-fix-by-smurf3tte">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/crystalchron-bosscrash_thumb.jpg"></a>
<figcaption>A certain brave developer tried to maximize visual quality by switching between RGBA8 and RGB565 EFB Copies depending on how much memory was available. This was the equivalent of <em>playing hot potato with a hand grenade</em>. Click the explosion above to read that story!</figcaption>
</figure>
</div>
<p>And now we return to Dolphin. In Dolphin, we support the original RGBA6 that games usually render with, and all other formats for rendering and EFB Copies. However, the hardware we are running on is almost guaranteed to be 8-bits per channel RGBA8 <em>or better</em>, so we have an enhancement called <em>Force 24-bit Color</em>. This mode forces the emulated console into a hybrid RGBA8-ish mode where the color channels are 8-bits per channel, and the alpha channel remains at 6-bits. This is mildly inaccurate, but it is not that far removed from what the console can do, and it <em>substantially</em> reduces banding. It's a relatively safe enhancement that can significantly improve image quality.</p>
<p>However, for <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a>, <em>Force 24-bit Color</em> <strong>did not affect banding at all</strong>.</p>
<p><div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigismansionbefore-default.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigismansionbefore-default_thumb.png" /></a>
<figcaption>This was the game with Default settings.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigismansionbefore-force24bit.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigismansionbefore-force24bit_thumb.png" /></a>
<figcaption>And here it was with Force 24-bit Color. Yes they are not the same image, we are sure.</figcaption>
</figure>
</div>
</div></p>
<p><strong><a href="https://github.com/Tilka">flacs</a></strong> noticed this discrepancy and looked into it. <em>Force 24-bit Color</em> forces the initial render to use the RGBA8 mode. However, <em>Force 24-bit Color</em> did nothing to EFB Copies, which every frame will undergo at least once! If the game used the typical option of EFB Copying into RGBA8, then Dolphin would take an RGBA8 image and EFB Copy it into an RGBA8 image, and the enhancement would still be in effect. But if the game chose to go with RGB565 (or RGB5A3... we're not going to talk about that one), Dolphin would follow the game's instructions and <em>decimate</em> the RGBA8 rendered image into RGB565, completely destroying the enhancement in the process!</p>
<p>Due to the color compromises, most games use RGB565 sparingly, saving it for secondary post processing of effects that only partially cover the screen. Most of the time, the RGB565 pieces of an image would be difficult to spot. Not so with Luigi's Mansion, as it <strong>EFB Copies the entire framebuffer in RGB565</strong>! This decimates the entire screen, rendering <em>Force 24-bit Color</em> effectively useless!</p>
<p>So <strong><a href="https://github.com/Tilka">flacs</a></strong> has corrected this oversight. Now, whenever <em>Force 24-bit Color</em> is enabled, EFB Copies will also use RGBA8 within Dolphin. Thanks to this change, we can see Luigi's Mansion as we never have before!</p>
<div class="media-block wider">
<div class="swap" ontouchstart>
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigibanding-before.png" alt="First Image">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/luigibanding-after.png" class="img-top" alt="Active Image">
</div>
<p style="margin-top: .5em; max-width: 100%; text-align:center;">Click/Tap and hold to see the banding improvement Force 24-bit Color can now achieve! </p>
</div>
<p>Force 24-bit Color will be improved in any title that uses lower quality EFB Copy formats such as RGB565. Players using the feature should look for reduced banding in their favourite titles! However, most games only use these lower quality EFB Copy modes for part of the screen, so most titles that are improved will see a less dramatic change than Luigi's Mansion.</p>
<h4 id="50-20923-steam-deck-pad-out-feature-report-to-64-bytes-by-endrift-and-arcanenibble"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20923/">5.0-20923 - Steam Deck: Pad out feature report to 64 bytes</a></strong> by <strong><a href="https://github.com/endrift">endrift</a></strong> and <strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong><a class="headerlink" href="#50-20923-steam-deck-pad-out-feature-report-to-64-bytes-by-endrift-and-arcanenibble" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:180px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/steam-release/steamdeckonwhite.jpg">
</div>
<p>In the previous Progress Report, we covered <a href="https://dolphin-emu.org/blog/2023/11/25/dolphin-progress-report-august-september-and-october-2023/#50-20148-periodically-re-enable-steam-deck-gyro-by-arcanenibble">5.0-20148 - Periodically Re-enable Steam Deck Gyro</a>. Current versions of SteamOS will try to shut down gyros that it thinks are not being used. This gave us a lot of issues, so this change addressed this by making Dolphin re-enable the gyro on Steam Decks roughly once per second.</p>
<p>However, due to SteamOS quirks, it's not easy for users to run Development builds on Steam Decks. Most Steam Deck users get Dolphin builds through <a href="https://docs.flatpak.org/en/latest/introduction.html">Flatpaks</a> of our Beta builds. So while the change was tested by the developers before being merged, it was only after the Report and the Beta release that the Flatpaks were updated and this change was finally able to reach wide adoption in users' hands.</p>
<p>And almost immediately, we started to get <a href="https://dolp.in/i13412">reports of doubled inputs</a> in the latest version of Dolphin. Uh oh.</p>
<p>The author of the change, <strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong>, immediately retested and couldn't reproduce it. And yet reports kept pouring in. So more of our developers tried it, and they couldn't reproduce it either. A few of our users and testers tried it, and weren't able to reproduce it either. Yet more and more reports kept pouring in. What was happening!?</p>
<p>This back and forth continued for weeks, until finally, we stumbled upon the answer. <em>Older Steam Decks were affected, and newly built Steam Decks were not</em>. It turns out that the <a href="https://www.youtube.com/watch?v=fhUqh-RkqEU&t=325s">Steam Deck LCD had a major revision in the fall of 2023</a>! The revision completely changed the Deck's internals, with significantly different PCBs and component parts! And sure enough, the Deck's Steam Controller controller chip was refreshed too. Steam Decks made before fall of 2023 use an Atmel controller, while Steam Deck LCDs made after fall of 2023, and all Steam Deck OLEDs, use a Renesas controller. Once we realized this potential source, we asked users to run a command that reported the controller in their Deck. In all of our samples, Steam Decks with Atmel controllers always had the issue, and Decks with the Renesas controller never had it.</p>
<p>Now that we knew how to reproduce the issue, we asked developers who work on the Deck for help. <strong><a href="https://github.com/endrift">endrift</a></strong>, <a href="https://mgba.io/">mGBA</a> author and Dolphin contributor, has been working on the Deck a lot lately. She came in and worked with the author of the change for a thorough debugging. It turns out, <strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong> made an tiny oversight and didn't fill in one value.</p>
<p><br/></p>
<p>Broken Code:</p>
<p><code>const unsigned char pkt[] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00};</code></p>
<p><br/>
Working Code:</p>
<p><code>const unsigned char pkt[65] = {0x00, 0x87, 0x03, 0x30, 0x18, 0x00};</code></p>
<p><br/></p>
<p><strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong> forgot to pad the packet size of the feature report packet. That's it. Here's endrift explaining what happened:</p>
<p><br/><blockquote style="font-size:1.1em">
When Steam tells the Steam Deck (or previously the Steam Controller) to change a setting, it uses something called a HID feature report. Feature reports can be up to 64 bytes long in USB 2.0, and the size of a device's report is described in the suitably named report descriptor, which is specified by the HID standard.</p>
<p>Feature reports can be split out into up to 256 different IDs, each of which can have a separate size as described in the descriptor. However, for a dynamic system like the Steam Deck, sometimes devices just define a longer-than-used 64 byte report size and just pad the end out with zeroes, then define the ID outside of the descriptor.</p>
<p>Steam always sends a fully padded 64 byte report, in accordance with the report descriptor. However, by sending a feature report with less than 64 bytes, the implementation on the USB device end gets confused. Quite possibly later feature reports get misinterpreted as a result, and one of these misinterpreted reports from Steam causes this issue.</p>
<p>However, Renesas chips don't appear to get confused and just internally assume the report should be padded to 64 bytes even when fewer are sent.
<footer><a href="https://github.com/endrift">endrift</a></footer></blockquote><br/></p>
<p>This resulted in Atmel controllers entering a glitched state where they operated in both "Lizard Mode" (the default fallback controls for when Steam is not running) and normal mode at the same time, doubling every input. Renesas controllers, on the other hand, were entirely unaffected.</p>
<p>So <strong><a href="https://github.com/endrift">endrift</a></strong> tested a fix and made a quick PR, and now the double input issue is resolved! While the solution may have ended up being very simple, this bug was a very difficult one to identify. It took the <em>entire Dolphin Steam Deck community</em> chasing this bug for us to figure it out and get it sorted. Thank you to everyone who reported and helped us chase this sneaky bug!</p>
<h4 id="50-20941-sdl-add-gamecontroller-api-cleanup-by-supersamus"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20941/">5.0-20941 - SDL: Add GameController API, cleanup</a></strong> by <strong><a href="https://github.com/SuperSamus">SuperSamus</a></strong><a class="headerlink" href="#50-20941-sdl-add-gamecontroller-api-cleanup-by-supersamus" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:20%; min-width:200px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2015-july/Sdl-logo.png">
</div>
<p><strong><a href="https://github.com/SuperSamus">SuperSamus</a></strong> has given our SDL input backend some love. First, they added support for the <a href="https://blog.rubenwardy.com/2023/01/24/using_sdl_gamecontroller/">GameController API</a>, an abstraction that allows consistent mapping across different controllers. Users will be able to switch controllers, i.e. a DualSense to a Switch Pro Controller, seamlessly without remapping! <strong><a href="https://github.com/SuperSamus">SuperSamus</a></strong> also cleaned up our SDL input backend, cleaning up a bunch of workarounds for old SDL versions that are no longer applicable to our current SDL2 input backend. SDL is now better than ever before, on all operating systems!</p>
<p>In fact, as of this change SDL has once again been enabled by default in our Linux builds! SDL has come <a href="https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/#40-6951-linux-add-an-evdev-based-controller-backend-to-replace-sdl-by-phire">a long long way</a>.</p>
<h4 id="50-20961-only-initialize-bounding-box-if-supported-by-gpudriver-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20961/">5.0-20961 - Only initialize Bounding Box if supported by GPU/driver</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-20961-only-initialize-bounding-box-if-supported-by-gpudriver-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>"Renderer" was an abstraction in Dolphin's code that functioned as an interface for video plugins. However, when the video plugins were merged with Dolphin's code and became video <em>backends</em>, Renderer became a dumping ground, filling up with tons of miscellaneous code and features. So, last year, <a href="https://github.com/phire">Phire</a> set off with the mission to kill Renderer <em>entirely</em>, refactoring enormous amounts of Dolphin's graphics code.</p>
<div class="media-block wider">
<figure>
<a href="https://github.com/dolphin-emu/dolphin/pull/11522">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/Refactoring.png"></a>
<figcaption>Kill Renderer moved <strong>a lot</strong> of code around.</figcaption>
</figure>
</div>
<p><a href="https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#50-18576-kill-renderer-by-phire">We covered Kill Renderer here on the blog</a>, both because it was a huge achievement, but also because any change that touched that much of Dolphin's codebase was likely to have <em>unforeseen consequences</em>. And that is what we come to today.</p>
<p>After Kill Renderer, we received reports from users on <em>very</em> old GPUs that Dolphin no longer worked for them. Now, any game they attempted to run would fail to start, with the error "Failed to create BoundingBox Buffer." </p>
<div class="media-block narrower">
<figure>
<a href="https://github.com/dolphin-emu/dolphin/pull/11522">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/BoundingBoxError.png"></a>
<figcaption>This occurred after running <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Brawl">Super Smash Bros. Brawl</a>. That game doesn't even use Bounding Box!</figcaption>
</figure>
</div>
<p>After Kill Renderer, Bounding Box was always initialized whether the hardware supported it or not. This doesn't affect most of our userbase, as >99% of our users' hardware supports the feature, but for any hardware that <em>doesn't</em> support Bounding Box, this regression completely broke Dolphin!</p>
<p><strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> looked into this and made a quick fix. As of this change, Dolphin will perform the same as it did before Kill Renderer on those GPUs - Dolphin runs again and games work, but if a user attempts to run a Bounding Box title, they are in for a buggy good time.</p>
<div class="media-block full-width">
<div class="row">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox1_thumb.jpg" /></a>
<figcaption>Mario refuses to be associated with the Intel HD Graphics 3000.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox2.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox2_thumb.jpg" /></a>
<figcaption>Now that's an air ship.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox3.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/hd3000-boundingbox3_thumb.jpg" /></a>
<figcaption>Unlike the GameCube, Intel HD Graphics 3000 cannot handle this many sprites at once.</figcaption>
</figure>
</div>
</div>
<h3 id="notice-for-nvidia-users"><strong>Notice for Nvidia Users</strong><a class="headerlink" href="#notice-for-nvidia-users" title="Permanent link">¶</a></h3>
<p>We've received reports of texture corruption in D3D11 on Nvidia GPUs with their latest drivers. This is still developing, as we have yet to properly isolate and analyze this, but we believe it to be some sort of driver issue. For now, we recommend Nvidia users avoid our D3D11 backend.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/d3d11nividiatexturecorruption.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2024-january/d3d11nividiatexturecorruption_thumb.png"></a>
<figcaption></figcaption>
</figure>
</div>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2023-11-01&to=2024-01-31&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-20349/">5.0-20349</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-21088/">5.0-21088</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
<p><style>
.swap {
position: relative;
display: inline-block;
}
.swap .img-top {
display: none;
position: absolute;
top: 0;
left: 0;
z-index: 99;
}
.swap:active .img-top {
display: inline;
}
</style></p>
Dolphin Progress Report: August, September, and October 2023
2023-11-25T15:44:10+00:002023-11-25T16:27:29.051470+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2023/11/25/dolphin-progress-report-august-september-and-october-2023/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/progressreportheader-august2023.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/progressreportheader-august2023mini.jpg" />
</header>
<p>This past October, Dolphin turned 20 years old since its initial release to the public as an experimental GameCube emulator. It's been a long ride, with twists and turns. I don't know if anyone back in 2003 expected Dolphin not only to still be under active development <strong>20 years later</strong>, but to also support the GameCube's successor in the Wii.</p>
<p>You might be wondering, <em>where is all the pageantry?</em> The honest truth is that things aren't ready yet. We have a few massive changes on the horizon that we wanted to be ready for the 20th anniversary, but that date was not an excuse to release something in a broken and incomplete state. For now, development will continue as normal, but we promise that there is some excitement to be had on the horizon.</p>
<p>In the meantime, we have some great changes for you this in Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-19886-add-custom-dark-style-for-windows-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19886/">5.0-19886 - Add Custom Dark Style for Windows</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-19886-add-custom-dark-style-for-windows-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>The waiting game is over. After much discussion and work, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> bit the bullet and added a dark mode to Dolphin. Some of you may be wondering right now, <em>Wait, didn't Dolphin already have dark mode?</em> Yes. Also no.</p>
<p>Essentially, on macOS, Android, and Linux, Dolphin has supported dark mode for <em>years</em>. On those platforms, if your system is configured to dark mode, Dolphin will switch to darker colors to match without requiring any input from the user. It is completely seamless on macOS and Android, and has been since <strong><a href="https://dolphin-emu.org/blog/2020/04/05/dolphin-progress-report-february-2020/">early 2020</a></strong>, nearly four years ago. Dolphin on Linux has supported dark mode for even longer, however it may or may not work out of the gate depending on the packaged Qt defaults and other Linux quibbles. If you're a Linux user, you know the dance.</p>
<p><div class="media-block wide">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/darklite-macos.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/darklite-macos_thumb.png" /></a>
<figcaption>Dark mode has been effortless in macOS for years now.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/darklite-android.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/darklite-android_thumb.png" /></a>
<figcaption>Android too!</figcaption>
</figure>
</div>
</div></p>
<p>However, the above fails to mention a very significant operating system that we support - Windows. As that is nearly half of our userbase, a lot of our users were missing out on nihilistic bliss. There were many reasons why we didn't support dark mode on Windows until now, but the core of the matter is our desktop GUI toolkit - Qt.</p>
<p>While Qt 5 supported automatic dark mode switching on macOS and Linux, it did not respond to the Windows dark mode setting at all. But there was a lot of demand for the feature, so Qt promised that a solution was in progress. For us as an application that uses Qt, we could have bodged together some sort of dark mode switching ourselves, but it would have inevitably been jank and weird. So upon hearing that Qt was working on it, we decided to wait for their solution. That eventually came with Qt 6.5, which indeed delivered automatic dark mode switching on Windows as promised... in their new "Fusion" style. The Windows-matching <em>QWindowsVistaStyle</em> Dolphin has used for years was abandoned and will not be getting dark mode at all. <a href="https://www.qt.io/blog/dark-mode-on-windows-11-with-qt-6.5">Qt gave many reasons for their decision</a> (spoiler: Windows be Windowsing), but fundamentally, they did what they thought was best given the circumstances.</p>
<p>With Qt's unexpected move to a new style, we had to make some decisions. Do we adopt the new Fusion style, affecting all of our Windows users both light and dark, or do we use the switching they built into Qt 6.5 and create something ourselves? So people experimented, with nearly a half dozen pull requests of all kinds! We tried Fusion, but the look of the style proved to be unpopular. So we started experimenting with custom styles of our own, with multiple people going different directions and <a href="https://en.wikipedia.org/wiki/Bikeshedding">bikeshedding</a> for months.</p>
<p>The end result is a hand-crafted dark mode alternate QWindowsVistaStyle created by our very own <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong>. It is what we had hoped Qt's default support for dark mode on Windows would have been - Dolphin on Windows, but dark.</p>
<p><div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/windows-lightmode.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/windows-lightmode_thumb.png" /></a>
<figcaption>The same Windows Dolphin style you know...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/windows-darkmode.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/windows-darkmode_thumb.png" /></a>
<figcaption>Can now go dark!</figcaption>
</figure>
</div>
</div></p>
<p>Now every platform we support now has dark mode and automatic switching! Of course it will switch automatically, but on Windows you can manually select between our dark and light styles and even custom user styles with the new Style dropdown in Config → Interface. This replaces the old Custom User Style control, combining our official styles and custom user style controls in one place. </p>
<h4 id="50-19939-implement-output-resampling-upscalingdownscaling-by-filoppi-and-samb"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19939/">5.0-19939 - Implement Output Resampling (Upscaling/Downscaling)</a></strong> by <strong><a href="https://github.com/Filoppi">Filoppi</a></strong> and <strong><a href="https://github.com/Sam-Belliveau">samb</a></strong><a class="headerlink" href="#50-19939-implement-output-resampling-upscalingdownscaling-by-filoppi-and-samb" title="Permanent link">¶</a></h4>
<p>For years now, whenever a user has asked us for settings that would give them the best image quality possible from Dolphin, there's been a familiar back and forth. In response to the question, we'd tell them to set Dolphin's Internal Resolution to match their screen (following our recommendations in the GUI), set Anisotropic Filtering to x16, and use 4x or 8x SSAA (Super Sample Anti-Aliasing). </p>
<p>On a sufficiently-capable gaming PC, that combination will give <em>pristine</em> visual quality. However, users would counter our recommendation by saying that since SSAA runs at a higher resolution than the screen and uses downsampling for its resolve, why can't they just do the same by raising Dolphin's Internal Resolution higher than their screen? And we'd reply by reminding them that Dolphin didn't have its own output resampling, and the basic downsampling from the GPU meant that their idea would create <strong>more aliasing</strong> rather than less.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-12xnative-4xssaa.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-12xnative-4xssaa_thumbbig.png"></a>
<figcaption>Believe it or not, this is using 4xSSAA. The Internal Resolution in this shot is much higher than the screen, and the GPU's basic bilinear downscaling is so sharp it creates new aliasing.</figcaption>
</figure>
</div>
<p>This song and dance has happened dozens of times, enough that <a href="https://dolphin-emu.org/blog/2020/05/05/dolphin-progress-report-april-2020/#50-11858-dolphinqt-dont-overwrite-8x-ir-scale-in-ini-add-maximum-internal-res-option-by-stenzek">we would remind users about this whenever new Internal Resolution options were added</a>. However, as of this change, things are different. Dolphin now has its own Output Resampler! With Area, Bicubic, Sharp Bilinear and more, users can now take upscaling and downscaling into their own hands. In fact, as far as we know no other game, emulator, or even <em>GPU driver</em> implements such an advanced and comprehensive resampler!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/Output-Resampling.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/Output-Resampling_thumb.png"></a>
<figcaption>B-Spline, Catmull-Rom, and Mitchell-Netravali, oh my!</figcaption>
</figure>
</div>
<p>Has this changed our recommendation for the best possible visual settings? Not really. While you can use output resampling to create a "DIY SSAA" that can meet SSAA's visuals, hardware SSAA <em>is faster at equivalent fidelity</em> (on an Nvidia GPU). SSAA is an easy recommendation.</p>
<p>However, performance was never the point. Output Resampling is an extremely powerful new tool that was built to give users control of Dolphin's final look. From an especially soft and temporally stable image, to razor sharp pixels, to the highest fidelity imaginable, our new output resampling features can do it all! There's a lot to cover here, so let's get started.</p>
<h4 id="what-is-output-resampling">What is Output Resampling?<a class="headerlink" href="#what-is-output-resampling" title="Permanent link">¶</a></h4>
<p>Before we continue, let's briefly go over the basics for any readers who are unfamiliar with these topics. Whenever rendering at a resolution that doesn't match the render window, the pixels of the game's output must be <em>resampled</em> (effectively remapped) into a new image that matches the new pixel grid. For example, a 1x Native (640x528) frame in a 1920x1080 canvas must be scaled up to fill the canvas. As it is not a 1:1 ratio and not even an integer multiplier, we can't just directly translate pixels from our output onto pixels of the screen, it must be resampled during upscaling. With the familiar Bilinear upscaling, it will fill the canvas by <a href="https://en.wikipedia.org/wiki/Interpolation">interpolating</a> the source pixels into the new pixel grid, for a consistent, though soft, resulting image.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xwindow.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xwindow-zoom_thumb.png" /></a>
<figcaption>If we run a game in 4:3 at 1x native in a window with Auto-Adjust Window Size, we get razor sharp pixels thanks to direct pixel mapping. At least, as close to direct mapping as is possible for the GC/Wii.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xwindow.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xwindow_thumb.jpg" /></a>
<figcaption>But this configuration is quite small on a 1080p screen.</figcaption>
</figure>
</div>
</div>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xfullscreen.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xfullscreen_thumb.jpg" /></a>
<figcaption>If we enter fullscreen, the game is much larger. However...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xfullscreen.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1xfullscreen-zoom_thumb.png" /></a>
<figcaption>Our pixels are now soft. This is because the ~480p pixel grid has been interpolated into the 1080p pixel grid of our display.</figcaption>
</figure>
</div>
</div>
<p>The GameCube and Wii were built with analog displays in mind, where exactness simply didn't exist. Every game is <em>close</em> to a standard aspect ratio but subtly nonstandard, and frustratingly <em>uniquely</em> subtly nonstandard. Plus, widescreen is achieved by just.. making the pixels wider, not adding more of them, so that means non-square pixels are a factor too! To accurately recreate these games on modern displays, we have no choice but to account and adjust for these behaviors, which we do by resampling the image. As such, any time you play a game in Dolphin, the image you are seeing will have been resampled at least a little in <strong>all cases</strong>.</p>
<p>Resampling is <em>unavoidable</em> in Dolphin.</p>
<p>Without an internal output resampler, Dolphin has been entirely reliant on host GPU's provided resampling for this important task. It's... not amazing. The GPU Bilinear Resampler was designed to be fast and simple, and not necessarily to have the best visual resolve.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-1xnative_thumb.png" /></a>
<figcaption>The GPU provided bilinear resampling a 1x native image into 1080p gives a soft result, but not an especially clean or great one. It does the job.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-6xnative_thumb.png" /></a>
<figcaption>Downscaling a 6x native image to 1080p is similarly "meh". Despite using four times the pixels of <a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-3xnative_thumb.png">3x native (which is close to our 1080p canvas)</a>, it's not much better. But it did downsample it for us.</figcaption>
</figure>
</div>
</div>
<p>Despite all this, resampling hasn't been a huge issue for us. After all, Dolphin's GPU load is pretty low* and we are always* CPU limited, so with GPU power to spare*, users should just run at the Internal Resolution that we recommend for their screen and call it a day. With modern devices, even a phone can do that*. And they probably even have enough spare GPU power to add antialiasing for an even better result! Despite all those asterisks, that is still <em>usually</em> the case, if all you care about are high resolutions and crisp antialiased lines. However, not everyone wants that. And even in 2023, there are still cases where not everyone can achieve that. This is where Output Resampling comes to its own.</p>
<h4 id="what-are-the-resample-options">What are the resample options?<a class="headerlink" href="#what-are-the-resample-options" title="Permanent link">¶</a></h4>
<p>Our Output Resampler is extremely comprehensive with many different possible settings and use cases. Here are some of the options and some ways that you can use them.</p>
<p><br/>
<span style="font-size: 1.5em;"><strong>Area</strong></span> is a resampler that samples every pixel on the screen for the maximum possible sample count. It is built for downsampling, with a soft resolve to combat aliasing, shimmer, and moire issues inherent to downscaling. It can be used for upsampling though, to curious results.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-1xnative_thumb.png" /></a>
<figcaption>By sampling all the pixels, the Area downsampler is extremely sharp when upsampling.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-6xnative_thumb.png" /></a>
<figcaption>When downsampling, Area's soft resolve helps smooth edges of textures and polygons alike.</figcaption>
</figure>
</div>
</div>
<p>Upsampling isn't really what Area is intended for, but is does give an interesting result - an extremely sharp look, akin to Sharp Bilinear. However, we recommend Sharp Bilinear over using Area this way, as Sharp Bilinear is explicitly designed for upscaling pixel art titles and has lower GPU usage than Area. Experiment with it yourself and compare!</p>
<p>Downsampling is where Area shines. The frick ton of samples and softened resolve allows Area to avoid the downsample aliasing that Bilinear and other resamplers experience. In fact, by combining the area resampler with MSAA and an Internal Resolution much higher than your screen, you can create a DIY SSAA.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-6xnative-4xmsaa.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-area-1080p-6xnative-4xmsaa_thumb.png"></a>
<figcaption>Add in some MSAA and the Area downsampler can match <a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-1080p-3xnative-4xssaa.png">SSAA's exceptional picture quality.</a></figcaption>
</figure>
</div>
<p>However, SSAA is a graphics driver feature that is optimized <em>with</em> your GPU to make it surprisingly efficient, for a brute force technique anyway. A DIY SSAA cannot be faster than a hardware optimized solution! But by being within the users' control, Area provides a lot of interesting downsampling options that we have not had before. Furthermore, SSAA is not so optimal everywhere and may not even be available for everyone. More on that later.</p>
<p><br/>
<span style="font-size: 1.5em;"><strong>Bicubic</strong></span> uses <a href="https://en.wikipedia.org/wiki/Spline_interpolation#Algorithm_to_find_the_interpolating_cubic_spline">cubic spline interpolation</a> for its resolve. It comes in three flavors: B-Spline (soft), Catmull-Rom (sharp), and Mitchell-Netravali (medium).</p>
<p><strong>B-Spline</strong> is an exceptionally soft upsampler. With extreme temporal stability and minimal noise, B-Spline can give an extremely clean and stable result.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-1xnative_thumb.png" /></a>
<figcaption>If you ever wanted Dolphin to use a modern display's pixels for a soft image rather than just more and sharper pixels, the softness of B-Spline is for you!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-6xnative_thumb.png" /></a>
<figcaption>B-Spline's downsampling is kind of inbetween Area and Bilinear.</figcaption>
</figure>
</div>
</div>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-1xnative-8xssaa.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-bspline-1080p-1xnative-8xssaa_thumb.png"></a>
<figcaption>Add SSAA to 1x Native B-Spline for a silky smooth resolve! All of the detail is still there, but the source pixels have melted into light and shapes. Be sure to click/tap this image, it's something else.</figcaption>
</figure>
</div>
<p>On the opposite end of the spectrum is <strong>Catmull-Rom</strong>, an extremely sharp upsampler.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-catmullrom-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-catmullrom-1080p-1xnative_thumb.png" /></a>
<figcaption>Now THIS is a different look for Dolphin! Click/Tap the image for detail!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-catmullrom-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-catmullrom-1080p-6xnative_thumb.png" /></a>
<figcaption>Downsampling, Catmull-Rom's sharpening is still present and gives some highlights around pixels, but it is significantly weakened.</figcaption>
</figure>
</div>
</div>
<p><strong>Mitchell-Netravali</strong> is inbetween these two extremes.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-mitchellnet-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-mitchellnet-1080p-1xnative_thumb.png" /></a>
<figcaption>For upsampling, Mitchell-Netravali kind of looks like B-Spline and Catmull-Rom combined. It is both softer and sharper than Bilinear.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-mitchellnet-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-mitchellnet-1080p-6xnative_thumb.png" /></a>
<figcaption>When downsampling, Mitchell-Netravali more or less just looks like Bilinear, but with a tiny bit of sharpening added on. It's fine.</figcaption>
</figure>
</div>
</div>
<p><br/>
<span style="font-size: 1.5em;"><strong>Sharp Bilinear</strong></span> was previously added to Dolphin as a post processing filter, and now has joined the suite of output resamplers. As we have <a href="https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#new-post-processing-shaders">already covered Sharp Bilinear quite recently</a>, we won't be going into detail here. But in summary, Sharp Bilinear is a best-of-both-worlds combination of Bilinear and Nearest Neighbor, allowing nearest neighbor pixel clarity without its shimmering artifacts. It is primarily designed for upsampling low resolution sprites, but it can be used to upsample 3D graphics if you want unnaturally sharp jaggies. It is not intended for downsampling.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-sharpbilinear-1080p-1xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-sharpbilinear-1080p-1xnative_thumb.png" /></a>
<figcaption>Sharp Bilinear is extremely sharp and ready to upscale pixel art!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-sharpbilinear-1080p-6xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingdemo-sharpbilinear-1080p-6xnative_thumb.png" /></a>
<figcaption>It's not made for downsampling, but downsampling Sharp Bilinear... looks like Bilinear. Also it is <em>extremely</em> close to the Mitchell-Netravali image above!</figcaption>
</figure>
</div>
</div>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#new-post-processing-shaders">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/sharpbilinear2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>
Click the image above to be taken to our previous coverage on Sharp Bilinear. It has animations and everything!
</figcaption>
</figure>
</div>
<h4 id="when-is-output-resampling-better-than-existing-solutions">When is Output Resampling Better than Existing Solutions?<a class="headerlink" href="#when-is-output-resampling-better-than-existing-solutions" title="Permanent link">¶</a></h4>
<p>Output Resampling is primarily focused on providing visual options for players, and it typically isn't outright superior to existing solutions. However, it is very powerful, and during testing, we found several scenarios where Output Resampling is able to create a better result than what was possible before.</p>
<h5 id="efb-copy-brute-forcing">EFB Copy Brute Forcing<a class="headerlink" href="#efb-copy-brute-forcing" title="Permanent link">¶</a></h5>
<p>Some games use a large EFB effect that is particularly expensive, and have to render it at a fraction of the game's output resolution. A classic example is the mirrored surface of Fountain of Dreams in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Melee">Super Smash Bros. Melee</a>.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplefod-1080p-3xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplefod-1080p-3xnative_thumb.jpg"></a>
<figcaption>The mirrored surface is rendered at <strong>1/8th</strong> the resolution of the rest of the image!</figcaption>
</figure>
</div>
<p>We don't have to worry about the hardware limitations that lead to these decisions, but the consequences of their choices affect us even today: as these effects are rendered proportional to the game's rendering resolution, they <em>scale</em> proportionally too. No matter what Internal Resolution multiplier we use, the mirrored pool in Fountain of Dreams will always be 1/8th of that. As such, the only way to increase the resolution of these effects relative to the screen (without modding the game) is to increase the Internal Resolution way beyond the screen resolution. But as we have already talked about thoroughly in this section, this will introduce aliasing with the GPU bilinear resampler. Users simply had to deal with this - it was either aliasing or a low resolution reflection.</p>
<p>Until now! Using our Output Resampler (specifically Area), we can raise the Internal Resolution as much as we want without adding aliasing!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplefod-1080p-21xnative-4xmsaa.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplefod-1080p-21xnative-4xmsaa_thumb.jpg"></a>
<figcaption>Fountain of Dreams can now be seen in perfect clarity!</figcaption>
<p style="transform: scale(1, -1);"><sub>Smash 64 is that you?</sub></p>
</figure>
</div>
<h5 id="upsampling-to-a-close-resolution">Upsampling to a Close Resolution<a class="headerlink" href="#upsampling-to-a-close-resolution" title="Permanent link">¶</a></h5>
<p>As mentioned previously, resampling is basically unavoidable in Dolphin due to quirks of the GameCube and Wii. However, if you use the Internal Resolution recommendations we have our in GUI (such as 3x Native for a 1080p screen), the GPU Bilinear Resampler will be good enough that switching to our Area resampler will give only marginal improvements even for pixel peepers. But not everyone has a system powerful enough to run at our recommendations for their screens, and they may have to settle with the highest Internal Resolution their hardware can manage. Depending on their circumstance, our Output Resampler could help them achieve a better image than was possible before.</p>
<p>A good example of this is resampling a 2x Native (1280x1056) 16:9 title into a 1920x1080 canvas. 2x Native nearly matches a 1080p screen vertically (1056 → 1080), but it has significantly fewer pixels horizontally (1280 → 1920).</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingclose-1080p-2xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingclose-1080p-2xnative_thumb.png" /></a>
<figcaption>The GPU Bilinear Resampling clearly exposes the resolution difference, with much softer pixels horizontally.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingclose-area-1080p-2xnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/resamplingclose-area-1080p-2xnative_thumb.png" /></a>
<figcaption>Our Area resampler gives a sharper and more consistent result under the same circumstances. This is most clear on Pit's rings in the left half of this image.</figcaption>
</figure>
</div>
</div>
<p>This benefit of our Output Resampler is highly situational, but it can improve Dolphin's image quality on lower end systems. Experiment and see what works best for you!</p>
<h5 id="downsampling-on-platforms-where-ssaa-is-unviable">Downsampling on Platforms where SSAA is Unviable<a class="headerlink" href="#downsampling-on-platforms-where-ssaa-is-unviable" title="Permanent link">¶</a></h5>
<p>SSAA has pristine visual quality and surprisingly good performance for a brute force solution. However, that doesn't matter if your system doesn't support SSAA! In desktop land we have been spoiled by SSAA being near universal, but Dolphin's mobile users are now <em>over half</em> of our userbase, and SSAA is uncommon on mobile SoCs. Furthermore, SSAA may be present but not optimal. Adreno in particular <em>hates</em> SSAA! A DIY SSAA made with Output Resampling may be just what a user needs on those platforms.</p>
<p>Unfortunately, our Output Resampler is not yet available on Dolphin Android. We tried our best to hunt down some non-Android devices that lack SSAA or have poor SSAA performance, but the best we had on hand was a <a href="https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-report-dec-2019-and-jan-2020/#50-11409-platform-support-for-windows-on-arm64-and-50-11455-dolphinqt-support-compiling-on-arm64-by-stenzek">2019 Surface Pro X</a>. While its Adreno GPU absolutely hated SSAA as predicted, it was too weak to serve as a good demonstration. </p>
<p>Once this feature arrives on Android, we have loads of powerful Android tablets to try this on. Stay tuned!</p>
<h4 id="50-20193-expose-resolutions-multipliers-up-to-12x-8k-by-filoppi"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20193/">5.0-20193 - Expose Resolutions Multipliers Up to 12x (~8k)</a></strong> by <strong><a href="https://github.com/Filoppi">Filoppi</a></strong><a class="headerlink" href="#50-20193-expose-resolutions-multipliers-up-to-12x-8k-by-filoppi" title="Permanent link">¶</a></h4>
<p>Now that we have proper downsampling, we've decided to increase the maximum Internal Resolution exposed by default in our desktop Qt GUI from 8x Native to 12x Native (8K). This will allow users of 4k displays to increase the Internal Resolution beyond their screen for downsampling purposes <a href="https://dolphin-emu.org/blog/2020/05/05/dolphin-progress-report-april-2020/#50-11858-dolphinqt-dont-overwrite-8x-ir-scale-in-ini-add-maximum-internal-res-option-by-stenzek">without editing INIs</a>. For the twelve of you with an 8k panel, now you don't need to set MaxResolution at all! Unless you want to, 8k users tend to have silly hardware so do whatever you want.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/internalresolutionoptions.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/internalresolutionoptions_thumb.png"></a>
<figcaption>That's a lot of pixels.</figcaption>
</figure>
</div>
<p>However, just because Dolphin shows 12x Native in the GUI does not mean that your computer can achieve it. 12x Native is <span style="white-space: nowrap;">48,660,480 pixels</span>, or <strong>48.7 megapixels</strong>. Currently <strong>most computers will run out of VRAM before reaching 12x Native!</strong> Statistically speaking your computer will not run this resolution at fullspeed. Use this power responsibly!</p>
<p>This change only applies to our desktop Qt GUI, and does not affect Dolphin on Android. We do not need to explain this.</p>
<h4 id="50-20199-use-lz4-for-savestate-compressiondecompression-by-malleo"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20199/">5.0-20199 - Use LZ4 for SaveState Compression/Decompression</a></strong> by <strong><a href="https://github.com/malleoz">Malleo</a></strong><a class="headerlink" href="#50-20199-use-lz4-for-savestate-compressiondecompression-by-malleo" title="Permanent link">¶</a></h4>
<p>If you're in the TAS community or relying on constant savestate usage for your project, this is a huge optimization that might make your life a lot easier. <strong><a href="https://github.com/malleoz">Malleo</a></strong> noticed that Dolphin was using <a href="https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Oberhumer">LZO</a> for savestates, which has a good compression ratio, but is quite a bit slower than <a href="https://en.wikipedia.org/wiki/LZ4_(compression_algorithm)">LZ4</a> when it comes to decompression. By moving Dolphin's savestate compression to LZ4, savestate loading is now ~72% faster.</p>
<p>For the casual users, savestate loads are now snappier. For speedrunners this will make practicing a single trick over and over again take a little less time. But for people using hundreds, thousands, or tens of thousands of savestate loads for TAS creation or AI projects, the savings really start to add up.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/Doec5gxhT_U" allowfullscreen></iframe></div><figcaption></figcaption>This is the kind of work that will be much faster now!
</figure>
</div>
<h4 id="50-19415-and-50-20126-improve-jit-block-lookup-performance-by-krnlyng"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19415/">5.0-19415</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20126/">5.0-20126</a></strong> - <strong>Improve JIT Block Lookup Performance</strong> by <strong><a href="https://github.com/krnlyng">krnlyng</a></strong><a class="headerlink" href="#50-19415-and-50-20126-improve-jit-block-lookup-performance-by-krnlyng" title="Permanent link">¶</a></h4>
<p>To run game code that's been designed for the GameCube and Wii's PowerPC CPU, Dolphin's JIT translates PowerPC machine code into machine code that your computer can run natively. Once a chunk of code has been translated, the resulting code block is stored in Dolphin's JIT Cache so that the code doesn't have to be translated all over again if it needs to run again later.</p>
<p>Usually when we optimize the JIT, the improvement is in how the code gets translated. But this time, <strong><a href="https://github.com/krnlyng">krnlyng</a></strong> has improved how quickly Dolphin can start executing the next block after a block is done running. Or to be more specific, how quickly Dolphin can do it in the case where it doesn't know in advance which block comes next.</p>
<p>To find out what block to run, Dolphin has a large table that maps emulated code addresses to the corresponding block of translated code. Before <strong><a href="https://github.com/krnlyng">krnlyng</a></strong>'s changes, this table was 256 KiB, and doing lookups in the table worked as follows:</p>
<ol>
<li>Dolphin grabs the lowest 16 bits of the current emulated code address. This results in a number from 0 to 65,535.</li>
<li>The number calculated in the previous step is used as an index in the table. Dolphin reads the table at that index and gets a pointer to JIT block metadata.</li>
<li>Dolphin checks that the pointer isn't 0, and then reads the JIT block metadata. If the pointer is 0, the code hasn't been translated yet, so Dolphin has to go and translate it before it can continue.</li>
<li>Dolphin checks that the emulated code address stored in the JIT block metadata matches the current emulated code address. Sometimes, the address might not match because two different emulated addresses have been mapped to the same index in the table. In that case, Dolphin has to use a much slower piece of code to find the right block.</li>
<li>Dolphin checks that the IR and DR bits of the MSR register match. We'll skip the details, but this is very similar to the previous step.</li>
<li>Dolphin gets the pointer to the translated code from the JIT block metadata, and jumps to it.</li>
</ol>
<p>After the changes, Dolphin has a new table that's <strong>32 GiB</strong> in size, and doing lookups in it works as follows:</p>
<ol>
<li>Dolphin takes the entirety of the current emulated code address and prepends the MSR bits that were mentioned earlier. This results in a number from 0 to 17,179,869,183.</li>
<li>Dolphin reads the table at the index calculated in the previous step and gets a pointer directly to the translated code.</li>
<li>Dolphin checks that the pointer isn't 0. Like before, a 0 means that Dolphin has to stop what it's doing and go translate the code.</li>
<li>Dolphin jumps to the pointer.</li>
</ol>
<p>This not only gets rid of the problem of different emulated addresses sharing the same index in the table, but also lets us skip reading the JIT block metadata entirely! But you may have an important question: How the heck is Dolphin going to fit a 32 GiB table into RAM when many computers and all phones have less total RAM than that?</p>
<p>In reality, Dolphin isn't asking the operating system for 32 GiB of real memory. Instead, it sets up 32 GiB of <em>address space</em> and asks the operating system to only allocate memory as needed. The first time Dolphin tries to access any given section of the 32 GiB table that isn't backed by real memory, the operating system allocates a small chunk of memory on the fly and fills it with zeroes. In the end, this new table can use a few more megabytes of memory than the old table, but nowhere even near 32 GiB.</p>
<p>In an ideal world, that would be all we have to say about the new solution. But for Windows users, there's a special quirk. On most operating systems, we can use a special flag to signal that we don't really care if the system has 32 GiB of real memory. Unfortunately, Windows has no convenient way to do this. Dolphin still works fine on Windows computers that have less than 32 GiB of RAM, but if Windows is set to automatically manage the size of the page file, which is the case by default, starting any game in Dolphin will cause the page file to balloon in size. Dolphin isn't actually writing to all this newly allocated space in the page file, so there are no concerns about performance or disk lifetime. Also, Windows won't try to grow the page file beyond the amount of available disk space, and the page file shrinks back to its previous size when you close Dolphin, so for the most part there are no real consequences... unless you like to download large files while running Dolphin.</p>
<p>We will look into improving the situation on Windows, but for the time being, please don't be alarmed if you see a sudden decrease in available disk space when running Dolphin.</p>
<h4 id="50-20201-increase-farcodenearcode-cache-sizes-by-dreamsyntax"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20201/">5.0-20201 - Increase FarCode/NearCode Cache Sizes</a></strong> by <strong><a href="https://github.com/dreamsyntax">dreamsyntax</a></strong><a class="headerlink" href="#50-20201-increase-farcodenearcode-cache-sizes-by-dreamsyntax" title="Permanent link">¶</a></h4>
<p>When playing certain games for an extended time, Dolphin's JIT Cache has an annoying tendency to run out of space. The most prominent example is of games like <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_2:_Echoes_(GC)">Metroid Prime 2: Echoes</a> where the game can dynamically load code into different places in memory. An even more difficult case is N64 Virtual Console games, like <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">The Legend of Zelda: Ocarina of Time</a> which use a recompiler to generate code on the fly. Once either the FarCode or NearCode cache is full, they must both be flushed, wiping both old and <em>current</em> data in the cache. This forces the JIT to rebuild all the code the game currently is running on the fly, leading to a noticeable stutter that cannot be avoided.</p>
<p>A huge step that <em>mostly</em> remedied this situation was merged <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#50-12575-jit-codegen-space-reuse-by-admiralcurtiss">back in 2021</a> which allowed Dolphin to evict code from the JIT Cache that the game itself invalidated. However, It wasn't a perfect solution. Dolphin was reliant on the game invalidating code, but sometimes games <em>just don't</em>, especially if they happen to be a trashfire like <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>. Also it couldn't actually defragment evicted code, meaning that the longer the game was running, the more fragmented the caches would become. If there was no longer enough space to fit a chunk of code, a full flush would be required. Back in 2021, we mentioned that the ability to just use a bigger JIT Cache <em>was</em> still on the table, but we were worried about its ramifications and hoped it would not be necessary.</p>
<p>Fast forward to today, and <strong><a href="https://github.com/dreamsyntax">dreamsyntax</a></strong> made a proposal to expand the JIT Cache. As part of it, they showcased a game that blew away all of our tricks: <a href="https://wiki.dolphin-emu.org/index.php?title=Shadow_the_Hedgehog">Shadow the Hedgehog</a>. It generates just enough code that it created a consistent, rhythmic, annoying stutter due to the JIT Caches filling up and flushing every 15 - 30 minutes.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/kwqlrC9COpk" allowfullscreen></iframe></div><figcaption></figcaption>The pauses. Are very. Consistent.
</figure>
</div>
<p><strong><a href="https://github.com/dreamsyntax">dreamsyntax</a></strong> showed that enlarging the JIT Cache <em>completely eliminated</em> the JIT Cache flushes in <a href="https://wiki.dolphin-emu.org/index.php?title=Shadow_the_Hedgehog">Shadow the Hedgehog</a>, and showed many other games that benefitted from it as well. They made a compelling case, so with a little hesitation, we pulled the trigger. As of this change, the JIT Cache has been enlarged!</p>
<p>However, all of the things we were worried about with a larger JIT Cache, such as longer more severe stutters, just didn't happen. The JIT Cache flush stutters that we have observed take the same amount of time, yet they happen MUCH less frequently <em>if ever</em>. In fact, the potential to have a cache flush stutter is now pushed so far into a play session that it is outside the usual play session for most users! Players <em>may never see a JIT Cache flush stutter again</em> as of this change! It makes us feel a little silly that we were so hesitant to enlarge the cache.</p>
<p>So far it appears that this is the JIT Cache flush stutter solution we have all been waiting for. Hopefully that holds true, as any further improvements to the JIT Cache from here will be <em>much</em> harder.</p>
<p><em>Note: This change only applies to our x86-64 JIT, and does not affect our AArch64 JIT for ARM systems. Due to architectural differences, raising the AArch64 JIT Cache size beyond 128 MiB would require special solutions.</em></p>
<h4 id="50-20148-periodically-re-enable-steam-deck-gyro-by-arcanenibble"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20148/">5.0-20148 - Periodically Re-enable Steam Deck Gyro</a></strong> by <strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong><a class="headerlink" href="#50-20148-periodically-re-enable-steam-deck-gyro-by-arcanenibble" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:180px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/steam-release/steamdeckonwhite.jpg">
</div>
<p>In the latest version of SteamOS, the gyro is disabled whenever SteamOS thinks the gyro is not being used. This includes situations like opening the Steam Deck's menus, which users might do quite frequently!
For Dolphin, this would make the gyro suddenly stop working for unknown reasons, with no clear way to reenable it. We're not sure why this behavior changed, but we have no choice but to find some way to deal with it.</p>
<p><strong><a href="https://github.com/ArcaneNibble">ArcaneNibble</a></strong> came up with a clever workaround. Rather than try to detect when the gyro is enabled/disabled, Dolphin will try to re-enable the gyro <em>roughly</em> every second or so. If it's already enabled? No harm, no foul. If it's disabled, it'll usually get re-enabled quickly, hopefully before the player even noticed it was disabled.</p>
<p>This will make playing some of your favorite Wii games on the latest version of SteamOS a lot more enjoyable, without you having to worry about the motion controls suddenly breaking for previously unknown reasons.</p>
<h4 id="50-20097-and-50-20109-allow-widescreen-heuristic-to-be-modified-per-game-by-oatmealdome-and-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20097/">5.0-20097</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20109/">5.0-20109</a></strong> - <strong>Allow Widescreen Heuristic to be Modified Per-Game</strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> and <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-20097-and-50-20109-allow-widescreen-heuristic-to-be-modified-per-game-by-oatmealdome-and-billiard" title="Permanent link">¶</a></h4>
<p>As an emulator for consoles in the 4:3 to 16:9 transition, players can expect to encounter many different aspect ratios as they play their library in Dolphin. So users don't have to change our aspect ratio setting with each game, we have a widescreen heuristic which detects how wide of an image the game is rendering and sets Dolphin accordingly.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2015-july/BogusNegativeAnemone.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2015-july/BogusNegativeAnemone.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>The widescreen heuristic works magically! ....usually.</figcaption>
</figure>
</div>
<p>Unfortunately, being a heuristic, Dolphin is effectively making an informed guess as to what aspect ratio the game wants. And sometimes, a game is able to fool our heuristic and create wildly inconsistent results!</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/pokemonwidescreen.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/pokemonwidescreen_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Oh no.</figcaption>
</figure>
</div>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_2:_Echoes_(GC)">Metroid Prime 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Colosseum">Pokémon Colosseum</a> and a few other games render certain effects with a viewport size that <em>tricks</em> our heuristic!</p>
<p>Unfortunately, we couldn't fix this by just changing what threshold the heuristic uses, as this would create false <em>negatives</em> - situations where the heuristic should have changed the aspect ratio but didn't. Regressions would be inevitable. Fortunately, there is a very simple solution available to us - our GameINIs. As of this change, the parameters used by our widescreen heuristic can be be overridden by our GameINIs. If we know a game is problematic for our heuristic, we can tweak how the heuristic behaves for that game without affecting any other games!</p>
<p>With that said, none of our GameINIs have had any parameters added yet. For the time being, you'll still run into problems in games like Pokémon Colosseum, but now that we have a workable system we can move forward with figuring out what parameters are needed for each problematic game.</p>
<h4 id="50-20041-add-support-for-touchscreen-latching-toggle-buttons-by-thunderousecho"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20041/">5.0-20041 - Add Support for Touchscreen Latching (Toggle) Buttons</a></strong> by <strong><a href="https://github.com/ThunderousEcho">ThunderousEcho</a></strong><a class="headerlink" href="#50-20041-add-support-for-touchscreen-latching-toggle-buttons-by-thunderousecho" title="Permanent link">¶</a></h4>
<p>Sometimes playing certain games in Dolphin on a touchscreen feels like an impossible challenge that would require another couple of hands and maybe a few extra fingers. For our touchscreen gamers, <strong><a href="https://github.com/ThunderousEcho">ThunderousEcho</a></strong> comes in with the ability to change various buttons on the touchscreen to be toggled instead of having to hold them down. This is known as a latching button, and is effectively the same as a toggle button in Dolphin's input system for physical controllers.</p>
<p>Simply tap the button once to have it "held" and then tap it a second time to release it. This is a simple addition, but it opens up the touchscreen controls a lot to be able to play more games on a touchscreen device. If you don't have a controller for your phone/tablet, or just prefer the single device form factor, latching might be the feature you need to play your favorite game.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/latchingbuttons.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-august/latchingbuttons_thumb.jpg"></a>
<figcaption>You can find the feature in the side menu, under Overlay Controls > Latching Controls.</figcaption>
</figure>
</div>
<h4 id="50-20001-another-panicalert-deadlock-fix-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-20001/">5.0-20001 - Another PanicAlert Deadlock Fix</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-20001-another-panicalert-deadlock-fix-by-josjuice" title="Permanent link">¶</a></h4>
<p>If you're a veteran of the Dolphin Progress Reports, you're well aware of the eternal battle with PanicAlerts and the seemingly random deadlocks they can cause in combination with certain settings. Thankfully, <em>another</em> one bites the dust as <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> fixes a hang that could happen when pressing the "Ignore for this session" button in a PanicAlert.</p>
<p>Is this the end of the PanicAlert deadlocks? Has our lovable villain finally been felled in such an anti-climatic manner? Find out next time on Progress Report Z.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2023-08-01&to=2023-011-15&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-19872/">5.0-19872</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-20347/">5.0-20347</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: May, June, and July 2023
2023-08-13T05:59:25+00:002023-08-13T06:30:44.408525+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2023/08/13/dolphin-progress-report-may-june-and-july-2023/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/progressreportheader-july2023.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/progressreportheader-july2023-mini.jpg" />
</header>
<p>It has been a bit of a tumultuous summer for the project, but now things are returning to normalcy. For those who somehow missed it, the Dolphin on Steam project <a href="https://dolphin-emu.org/blog/2023/07/20/what-happened-to-dolphin-on-steam/">has ceased</a> after contact between Valve and Nintendo. Though we disagree with their stance and decision, we respect Valve's right to impose whatever restrictions they want within their private storefront. Please read the full article for details.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/blog/2023/07/20/what-happened-to-dolphin-on-steam/">
<img src="https://dolphin-emu.org/m/user/blog/steam-release/steamwhat.jpg"></a>
<figcaption>
</figcaption>
</figure>
</div>
<p>Fortunately, all that means is that nothing is going to change. We're going to continue working hard to improve Dolphin and make it the best emulator it can be. </p>
<p>Speaking of which, we hope you enjoy this Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-19611-implement-custom-driver-support-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19611/">5.0-19611 - Implement Custom Driver Support</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-19611-implement-custom-driver-support-by-k0bin" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:8%; min-width:120px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png"></div>
<p>GPU drivers for Android devices have come a long way from the <a href="https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/">nightmare they once were</a>, but they still lag behind their desktop counterparts in many ways. Missing features, performance problems, and plain old bugs are still plentiful on Android drivers. Furthermore, while drivers are improving over time, these improvements <a href="https://www.esper.io/blog/android-dessert-bites-14-gpu-driver-updates-3819534">rarely make their way to existing devices</a>, which is considerably worse than desktop. However, for Dolphin, Android GPU drivers are now at least good enough to <em>work</em> most of the time. There may be bugs or issues, but usually you'll get an image and the emulated title will function.</p>
<p>Emulators for newer consoles weren't so lucky, however, and Android drivers have been an intense pain point for them. This spurred <strong><a href="https://github.com/bylaws">ByLaws</a></strong> to take action and develop the library <a href="https://github.com/bylaws/libadrenotools">libadrenotools</a>, which lets apps temporarily switch out the system driver for a user-provided driver. libadrenotools has tremendously improved the experience of emulating newer consoles on Android devices, as not only does it allow loading of newer versions of official drivers, but it also allows the loading of <em>unofficial</em> open source drivers that are substantially better than their official counterparts. Specifically of note is Freedreno Vulkan, also known as Turnip. It's a custom driver primarily for Adreno 600 GPUs (though support for Adreno 700 GPUs is in development as well) that is by far the most complete Vulkan driver available for Adreno.</p>
<p><strong><a href="https://github.com/K0bin">K0bin</a></strong> saw all of the improvements that libadrenotools and Turnip granted other emulators and realized that Dolphin could take advantage of them too. With this change, libadrenotools is now integrated into Dolphin, allowing Android users to choose which Vulkan GPU drivers they prefer. While Android driver issues were not as critical for us, the Freedreno driver is a breath of fresh air. Tons of Vulkan issues that have plagued our Adreno users are <em>gone</em> when using it.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/tp-adreno.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/tp-adreno_thumb.jpg" /></a>
<figcaption>For unknown reasons, paletted EFB copies are among the broken features on Adreno.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/tp-turnip.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/tp-turnip_thumb.jpg" /></a>
<figcaption>Turnip just works.</figcaption>
</figure>
</div>
</div>
<p>If your GPU is among those supported, Turnip offers an opportunity to get a driver that's much closer to desktop quality. However, we've only been talking about compatibility and bugs so far. How does Turnip compare to the official drivers in performance? Well, performance can be better, but it isn't always going to be. Sometimes the more complete implementation of features allows Dolphin to go faster than other drivers, sometimes the fact it's able to emulate things in a more complete manner means that the game might run a little slower. And, of course, the driver might not implement all features optimally, causing some variations that are out of the control of Dolphin.</p>
<p>Using an older phone, we can compare the Turnip driver to the latest supported Adreno driver and compare performance. We also compared to the Adreno OpenGL driver - as Turnip is for Vulkan only. All tests were done at 1x internal resolution in order to test the raw efficiency of the driver to keep maximum performance.</p>
<p><br/>
<script>
addChart(
{"chart":{"type":"column","polar":false},"title":{"text":"Custom Drivers Performance"},"subtitle":{"text":"Pixel 3a with Adreno 615"},"tooltip":{"headerFormat":"<span style=\"font-size:10px\">{point.key}</span><table>","pointFormat":"<tr><td style=\"color:{series.color};padding:0\">{series.name}: </td><td style=\"padding:0\"><b>{point.y:.1f} FPS</b></td></tr>","footerFormat":"</table>","shared":true,"useHTML":true},"plotOptions":{"column":{"pointPadding":0.2,"borderWidth":0},"series":{"animation":false,"dataLabels":{"enabled":true}}},"series":[{"name":"Custom Drivers Performance)","turboThreshold":0,"_colorIndex":0,"marker":{"enabled":false},"colorByPoint":false},{"name":"Native","turboThreshold":0,"_colorIndex":1},{"name":"Three","turboThreshold":0,"_colorIndex":2}],"data":{"csv":"\"Category\";\"Adreno\";\"Turnip\";\"OpenGLES\"\n\"Super Mario Galaxy\";35;32;24\n\"Pokemon Colosseum Singles Battle\";24;26;25\n\"Wind Waker Outset Island\";27;28;33","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"labels":{"format":"{value}FPS"}},"colors":["#ff3100","#006eff","#00c800","#00c800","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"legend":{"floating":false,"verticalAlign":"top"},"credits":{"enabled":false},"lang":{},"exporting":{},"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<p>The results vary quite a bit, with a different driver being faster for each game! However, for the most part performance is pretty similar between the different backends with the main benefit being that Turnip mostly just works. While there are the occasional bugs, much like with the <em>official</em> Adreno drivers, overall Turnip provides a more consistent experience. And with it under active development, the problems we have seen are likely to get fixed.</p>
<h5 id="a-note-to-non-adreno-users">A Note to Non-Adreno Users<a class="headerlink" href="#a-note-to-non-adreno-users" title="Permanent link">¶</a></h5>
<p>There is nothing fundamentally Adreno-specific about loading custom drivers. Unfortunately for users with other GPUs, there aren't any viable custom drivers at this time. If custom drivers do show up for these devices, we'll be able to update Dolphin to load them.</p>
<h4 id="50-19274-add-wiiconnect24-support-via-wiilink-by-sketch"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19724/">5.0-19274 - Add WiiConnect24 Support via WiiLink</a></strong> by <strong><a href="https://github.com/noahpistilli">Sketch</a></strong><a class="headerlink" href="#50-19274-add-wiiconnect24-support-via-wiilink-by-sketch" title="Permanent link">¶</a></h4>
<p>When WiiConnect24 shut down so suddenly just over ten years ago in June of 2013, there was a thought among Dolphin developers that WiiConnect24 would never be emulated - at least in Dolphin. For nearly 10 years, <a href="https://dolphin-emu.org/blog/2022/12/21/dolphin-progress-report-september-october-november-2022/#50-17613-implement-missing-features-for-wiiconnect24-support-by-noahpistilli">that remained true</a>. However, a lot of the core features of WiiConnect24 were still missing in Dolphin, and setting it up required use of third party tools to patch channels.</p>
<p>In the latest builds of Dolphin, users can now enable WiiConnect24 directly in Dolphin's GUI, allowing you to use the Forecast Channel, Nintendo Channel, and soon the News Channel and Everybody Votes Channel directly in the system menu without the need for patching channel files. This is all thanks to <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> (aka noahpistilli) who is both implementing critical features in Dolphin's Network/KD and reimplementing the servers which the channels themselves communicate with as the lead developer of <a href="https://www.wiilink24.com/">WiiLink</a>.</p>
<p>This marriage between the two sides of development has led to a WiiConnect24 revolution within Dolphin, and more features will be coming online in the future.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/dolphinweather-demo.mp4" type="video/mp4"/>
</video></div>
<figcaption>Here is a short demonstration video of the <a href="https://wiki.dolphin-emu.org/index.php?title=Forecast_Channel">Forecast Channel</a> made in Dolphin with WiiLink, showing the many cities that the channel supports! With the Wii console set to the United States, a total of 904 cities are available to view! </figcaption>
</figure>
</div>
<p>With Dolphin adding support for WiiLink, does this mean RiiConnect24 will not work in Dolphin? Of course not! The same methods used to patch channels with RiiConnect24 will continue to work in the latest versions of Dolphin.</p>
<p>Choosing between WiiLink and RiiConnect24 for a default service was not an easy task. RiiConnect24 has been an invaluable part of the WiiConnect24 preservation scene and will continue to work in Dolphin. However, with <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> working on both the server side (WiiLink) and the client side (Dolphin), compatibility and stability is currently higher with WiiLink. As well, there are some features of RiiConnect24 that use cIOS features that do not currently work in Dolphin that are handled without cIOSes in WiiLink.</p>
<p>Something to keep in mind is that Dolphin's priority is to emulate <strong>WiiConnect24</strong> to the best of its ability. Currently, <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> is reimplementing WiiConnect24 features in a manner that would work alike to the original WiiConnect24 servers. We are aware that some bugs/inaccuracies in Dolphin's implementation of Network/KD that, when fixed, will require changes from RiiConnect24 in order to maintain compatibility.</p>
<p>We also request that users who have used the RiiConnect24 VFF downloader delete any VFF files created by it, as well as disable the downloader. The VFFs created by it are made to never expire, meaning new files will never be downloaded by Dolphin. To locate these, click <code>File -> Open User Folder</code> and then navigate to <code>Wii/title/00010002/484146xx/data</code> for the Forecast Channel and <code>Wii/title/00010002/484147xx/data</code> for the News Channel, where <code>xx</code> is <code>45</code> for NTSC-U consoles, <code>50</code> for PAL and <code>4a</code> for Japanese. If you're having problems with WiiLink/RiiConnect24 on the latest builds and have used the VFF downloader in the past, that may be the source of your troubles.</p>
<p>Note for those who want to use an unmodified Nintendo Channel: <strong>Cheats must be enabled in order for the channel to work.</strong></p>
<h4 id="50-19448-android-disney-infinity-base-support-by-dereeperjosh"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19448/">5.0-19448 - Android - Disney Infinity Base Support</a></strong> by <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong><a class="headerlink" href="#50-19448-android-disney-infinity-base-support-by-dereeperjosh" title="Permanent link">¶</a></h4>
<p>If everyone is being honest, there probably isn't much point to this feature, at least right now. The only game that supports the Disney Infinity Base on the Wii is <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a>, possibly the crown jewel of the Disney Trio of Destruction. There is no existing <em>desktop</em> computer that can run the game full speed given how Dolphin currently emulates the game. For phones, the situation is even worse.</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/infinitybaseandroid.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/infinitybaseandroid_thumb.jpg"></a>
<figcaption>Note the FPS in this screenshot. Disney Infinity will not even get close to fullspeed on any device currently available, so don't get your hopes up.
</figcaption>
</figure>
</div>
<p>But, maybe some day, some AArch64 JIT improvement and/or some future phone will somehow emulate Disney Infinity at a playable framerate. Whenever that happens, future Android users will be able to emulate the Infinity Base and get in game without the need for physical hardware.</p>
<h4 id="50-19554-android-fix-trigger-detection-issue-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19554/">5.0-19554 - Android - Fix Trigger Detection Issue</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-19554-android-fix-trigger-detection-issue-by-josjuice" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:180px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/BSPD3_thumb.jpg">
</div>
<p>After the release of the <a href="https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/#50-18920-rewrite-android-input-handling-by-josjuice">input handling rewrite</a> a few months ago, there have been a few growing pains. A rather annoying one for many users was an issue causing trigger inputs from certain controllers to simply be ignored in the menu. More frustratingly, you could actually <em>manually</em> add them if you knew your way around the advanced mapping options!</p>
<p>This turned out to be relatively easy to fix in the end, though. The input handling rewrite brought a lot of code from the PC version of Dolphin to the Android version, including a piece of code that is designed to skip over button inputs in case a gamepad provided both a button input and an axis input for a trigger at the same time. But the affected controllers on Android were doing something that the PC version of Dolphin had never ran into: each trigger provided <em>two</em> axis inputs. Because the code wasn't expecting this, both of the inputs were getting skipped by accident. With the cause of the problem known, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> was able to change the code to let both inputs through.</p>
<p>Users that suffered from this regression should be able to configure their controllers directly in the GUI again in the latest Play Store release.</p>
<h4 id="50-19863-add-filesize-checks-to-check-nand-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19863/">5.0-19863 - Add Filesize Checks to Check NAND</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-19863-add-filesize-checks-to-check-nand-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>With the Wii NAND coming more to the forefront with some of Dolphin's latest features, <em>Check NAND</em> has been seeing a lot more usage. The long-story-short of it is that the Wii File System is <em>extremely</em> tempermental and prone to breaking, so back in the day <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> created a feature that allowed Dolphin to check the Wii NAND for certain common problems and automatically fix them.</p>
<p>Check NAND was mostly a tool used to fix the NAND to get the Wii Shop and <a href="https://wiki.dolphin-emu.org/index.php?title=Dragon_Quest_X:_Mezameshi_Itsutsu_no_Shuzoku_Online">Dragon Quest X</a> working - as even the slightest problem with the NAND would prevent them from booting. However, it wasn't designed to fix everything, and it'll often say no problems found when in fact there are critical problems with the NAND.</p>
<p>Enter <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong>. Having debugged an issue where a user's NAND was "overfilled" due to spurious files being placed in the NAND directory, they decided that it was time to expand the scope of Check NAND a bit more. In the latest versions of Dolphin, Check NAND will now make sure that the NAND size is within the bounds of the Wii NAND.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/nandcheck.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/nandcheck.png"></a>
<figcaption>
</figcaption>
</figure>
</div>
<p>On a modern computer with terabytes of storage, you might think that the Wii NAND being limited to just 512MB is a bit archaic and that Dolphin should just allow any NAND size. And we technically do - you can keep adding things to the NAND even if it is over that maximum size. Unfortunately, the Wii System Menu and many games have checks to make sure that the NAND isn't getting close to full. Even if we tell the Wii it has way more NAND space, it is <em>hardcoded</em> to use exactly 512MB, with certain portions of it being reserved.</p>
<p>In the past, Dolphin has tried to lie to the emulated Wii about the size of installed files, saying that they were one block no matter how big they were, but this just caused other problems and we ran into other limitations even in situations where that hack did seem to help. So for now, we're handling things as accurately as possible in order to make sure users don't jeopardize their Wii Save Data.</p>
<p>It's possible there is some magic combination of hacks that could <em>maybe</em> trick the emulated Wii into supporting more/bigger files, but so far we haven't found it. And considering how many people run into the Wii's paltry NAND size limits, a hack like this wouldn't see much resistance into being merged as an option.</p>
<h4 id="50-19716-support-accurate-ntscpal-color-spaces-by-filoppi"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19716/">5.0-19716 - Support Accurate NTSC/PAL Color Spaces</a></strong> by <strong><a href="https://github.com/Filoppi">Filoppi</a></strong><a class="headerlink" href="#50-19716-support-accurate-ntscpal-color-spaces-by-filoppi" title="Permanent link">¶</a></h4>
<p>The GameCube and Wii were designed with analog CRT televisions in mind. In this era, "close enough" was the rule of the day. For example, each region had their own slightly different color spaces and gamma targets. Games almost never accounted for these differences, so how each game would appear varied slightly from region to region! To emulate this, Filoppi (helped by <a href="https://github.com/EndlesslyFlowering">Lilium</a>) has implemented a suit of color space and gamma correction settings.</p>
<p>Dolphin's color correction provides several color space options. Using these profiles, you can now set Dolphin to match the colour space of any given region and either make it match how you remember it in your region, or just see how your game would look in an entirely different region!</p>
<div class="media-block full-width">
<div class="swap" ontouchstart>
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/normalcolorspace_thumb.jpg" alt="First Image">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/ntscmcolorspace_thumb.jpg" class="img-top" alt="Active Image">
</div>
<p style="margin-top: .5em; max-width: 100%; text-align:center;"><em>This is the unmodified color space. Click/Tap and hold to see the NTSC-M color space.</em><br/>The difference is VERY subtle.</p>
</div>
<p>Something a little more impactful from these changes is <em>gamma correction</em>. Most GameCube games (and some Wii games) targeted a gamma value of roughly 2.35. Modern televisions and monitors normally use a value of 2.2, which can result in these games looking a tiny bit brighter than they would have (by default) on hardware of the day.</p>
<div class="media-block narrow">
<div class="swap" ontouchstart>
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/notgammacorrected.png" alt="First Image">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-july/gammacorrected.png" class="img-top" alt="Active Image">
</div>
<p style="margin-top: .5em; max-width: 100%; text-align:center;"><em>This is the normal image. Click/Tap and hold to see the gamma corrected version.</em><br/>The gamma corrected version has subtly crushed blacks for a slightly spookier vibe.</p>
</div>
<p>While it's possible for users to adjust their monitor's settings, and <em>some</em> games come with built-in gamma correction, <strong><a href="https://github.com/Filoppi">Filoppi</a></strong> added gamma correction to the color space features within Dolphin's settings in order to streamline the experience.</p>
<p>Note that these settings and features have not been ported to the Android version of Dolphin yet, however that is <a href="https://github.com/dolphin-emu/dolphin/pull/12095">in progress</a>.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2023-05-01&to=2023-07-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-19370/">5.0-19370</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-19870/">5.0-19870</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
<p><style>
.swap {
position: relative;
display: inline-block;
}
.swap .img-top {
display: none;
position: absolute;
top: 0;
left: 0;
z-index: 99;
}
.swap:active .img-top {
display: inline;
}
</style></p>
Dolphin Progress Report: February, March, and April 2023
2023-05-21T07:27:22+00:002023-05-22T05:22:49.538494+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2023/05/21/dolphin-progress-report-february-march-april-2023/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/progressreportheader-feb2023.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/progressreportheader-feb2023-mini.jpg" />
</header>
<p>It's been a hectic past few months for the project. In addition to the <a href="https://dolphin-emu.org/blog/2023/03/28/coming-soon-dolphin-steam/">upcoming release on Steam</a>, a lot of focus has gone into other major features. While not everything has landed yet, two very important changes to Android <em>did</em> arrive, one of which has been in the works for a couple years!</p>
<p>We're talking about a large scale rewrite to Dolphin's Android Input Handling that will eventually allow it to match the feature set users on Desktop Dolphin builds enjoy. Android users also get another major quality of life upgrade - Dolphin is now a Document Provider on Android. This means you can use Dolphin to directly copy files into and out of its <em>per-app directory</em> on the latest versions of Android.</p>
<p>In this report, we'll be going through both of these and several other important changes. Enjoy!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-18920-rewrite-android-input-handling-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18920/">5.0-18920 - Rewrite Android Input Handling</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-18920-rewrite-android-input-handling-by-josjuice" title="Permanent link">¶</a></h4>
<p>Over <em>ten</em> years ago, back in the ancient time known as "<em>late 2012</em>", <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> started development on a new Dolphin JIT that could run on ARM processors. Back then it was an incredibly bold move - there were no ARM devices that even had a <em>prayer</em> of running Dolphin close to full speed. It was a forward thinking project that took on many incredibly difficult hurdles. </p>
<p>While today the ARM JIT is mostly used on Android phones, the early ARM JIT development was done on development boards and Chromebooks running Linux. Phones simply didn't have the features/speed to even <em>hope</em> to run Dolphin at that point. However, once phones began to appear with the bare minimum featureset required to run Dolphin, <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> began work on porting Dolphin to Android using the new ARM JIT. And thus, a new challenge appeared for <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> - <em>Android itself</em>.</p>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:8%; min-width:120px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png"></div>
<p>One of the biggest annoyances with Dolphin on Android comes from Android's interfaces being written in Java versus Dolphin's being written in C++. In order to bridge these two languages together, we have to use JNI (Java Native Interface). In order to go the path of least resistance and get things working, <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> decided to just make a quick reimplementation in Java. It was less code overall at the time and meant things could be working more easily. Less time spent working on input meant more time working on the fun parts.</p>
<p>However, the quick implementation that <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> threw together just... remained, with feature after feature bolted onto it over a decade. This is how Dolphin's Android's Input fell into such a problematic state. Plus, it was separate from Dolphin's C++ input implementations, so any improvements had to be manually ported over. Most of the time the latest input features simply wouldn't come to Dolphin Android.</p>
<p>To rectify this situation, Android's entire Input system had to be ripped out and started anew.</p>
<h5 id="android-controller-support-reborn">Android Controller Support Reborn<a class="headerlink" href="#android-controller-support-reborn" title="Permanent link">¶</a></h5>
<p>For the past couple of years, users have been desperately asking for improvements to Dolphin's Touch Controls and Android Controller Support. We've continually turned them away, promising that work was being done on it. While it was possible to hack improvements into the Java implementation, it would have been a temporary band-aid fix. These fixes would then have to be thrown out if a proper fix was ever to come into fruition, which we knew was coming.</p>
<p>Behind the scenes, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has been slowly removing <em>all</em> of the Java reimplementations of C++ parts of Dolphin on Android and moving them over to JNI. While there were multiple parts of Dolphin reimplemented in Java, input handling was one of the biggest and most convoluted. It proved to be a much more difficult task than the other sections.</p>
<p>Part of the problem is that input handling in Dolphin is complicated. We have to give users options to deal with motion controls, infrared, controller orientation, swapping attachments, swapping controllers, and more. Depending on what kind of controller you have, you might need entirely different features to play through a game. Worse yet, you might need <em>entirely different settings</em> to play two different games.</p>
<p>The project to port the handling over to JNI so we can use the C++ implementation directly has been a multiyear endeavor. And while the initial work has been merged, not everything is fully complete yet. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> had to move out some parts of it in order to keep the pull request reviewable and to avoid regressions that haven't been hammered out quite yet. Still, the JNI port of Dolphin's input handling <strong>already has a ton of long requested features</strong>!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/androidinput.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/androidinput_thumb.png"></a>
<figcaption> The Advanced Input Page finally reaches Android greatly opening the door for more advanced input schemes.
</figcaption>
</figure>
</div>
<ul>
<li>You can change controller settings while emulation is running.</li>
<li>You can save and load input profiles. (The old feature of per-game mappings is replaced by per-game input profiles.)</li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Input_Syntax">Advanced input expressions.</a></li>
<li>You can map your device's accelerometer and gyroscope to whatever you want, not just Wii Remote motions.</li>
<li>Support for many new device sensors. (How about the ambient light level, or the hinge angle of a foldable phone?)</li>
<li>If a device or gamepad has multiple motors, you can now choose between them for rumble. (Requires Android 12 or later.)</li>
<li>You can set many boolean and numeric controller settings that weren't available on Android before, like Relative Input.</li>
<li>The Sideways Wii Remote setting, the numeric settings for Wii Remote pointing, and the setting for disabling accelerometer/gyroscope pointing have been moved from the in-emulation settings to the regular settings.</li>
<li>The touchscreen controller type setting has been overhauled. Users can now choose between all controllers 1-4, but selecting a Wii Remote extension is now done in the regular settings.</li>
<li>Separate gamepads are never treated as a single gamepad anymore.</li>
<li>Dolphin no longer mixes up buttons and axes that have the same ID.</li>
<li>Possibly fixes for various issues with detecting axes.</li>
</ul>
<p>Because Android now uses the same input core as desktop builds, this will allow newer input features to hit Android builds at a more consistent rate. This does come with one caveat - all configurations for the <em>old</em> Android Input will no longer work on new builds, meaning users will have to reconfigure controllers under the new system.</p>
<h4 id="50-18922-android-implement-document-provider-support-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18922/">5.0-18922 - Android: Implement Document Provider Support</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-18922-android-implement-document-provider-support-by-k0bin" title="Permanent link">¶</a></h4>
<p>With Scoped Storage and the per-app directories in modern versions of Android, modifying Dolphin's user contents has gotten a lot harder. The days of just having a typical "User Directory" in an easy-to-access place on Android are gone. We're stuck using gated per-app directories that <em>only Dolphin can access</em>. The problem with that, is that if you want to modify those files to add a Texture Pack or Riivolution mod, you more or less have to use a computer or something that bypasses Android's restrictions altogether!</p>
<p>In an effort to mitigate these problems, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> added the ability for users to import/export the entire user directory via zip files. Unfortunately, it seems many Android distributions use non-standard zip formats that our basic implementation couldn't handle for unknown reasons. A better long-term solution was needed.</p>
<p>Thankfully, other emulators have run into the same issues as us and have come up with some rather robust solutions. <strong><a href="https://github.com/K0bin">K0bin</a></strong> implemented Document Provider Support to allow file managers with that feature to access Dolphin's per-app directories!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/android-documentprovider.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/android-documentprovider_thumb.png"></a>
<figcaption> Document Provider Support allows easier access to per-app directories.
</figcaption>
</figure>
</div>
<p><a href="https://dolphin-emu.org/download/dev/master/5.0-19234/">5.0-19234</a> added some further improvements, as well as a distinction between "debug" and "release" builds in order to reduce confusion when handling user directories.</p>
<h4 id="50-18957-fix-wii-remote-disconnect-deadlock-by-dentomologist"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18957/">5.0-18957 - Fix Wii Remote Disconnect Deadlock</a></strong> by <strong><a href="https://github.com/Dentomologist">Dentomologist</a></strong><a class="headerlink" href="#50-18957-fix-wii-remote-disconnect-deadlock-by-dentomologist" title="Permanent link">¶</a></h4>
<p>A common complaint with using <em>Real</em> Wii Remotes for <em>Emulated</em> controllers is that if the Wii Remote were to suddenly disconnect from Dolphin, sometimes the entire emulator would go down with it! Because the problem wasn't especially consistent, tracking it down was annoying until <strong><a href="https://github.com/Dentomologist">Dentomologist</a></strong> came up with a fairly consistent method of triggering the crash.</p>
<p>Once reproducing the crash was sorted out, they found a potential deadlock with device population while debugging it. By putting safeguards to prevent this deadlock, <strong><a href="https://github.com/Dentomologist">Dentomologist</a></strong> fixed the crash and now disconnecting Wii Remotes should be <em>quite</em> a bit safer.</p>
<h4 id="50-18576-kill-renderer-by-phire"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18576/">5.0-18576 - Kill Renderer</a></strong> by <strong><a href="https://github.com/phire">phire</a></strong><a class="headerlink" href="#50-18576-kill-renderer-by-phire" title="Permanent link">¶</a></h4>
<p>Not all big changes are supposed to have an immediate impact. Kill Renderer is something, that if implemented correctly, should cause nothing to change for the time being. It's just a step toward some more important changes down the line, and the reason that it is necessary requires us to dive into Dolphin's history and learn a bit about this mysterious "renderer".</p>
<p>Renderer exists because Dolphin was originally a plugin based emulator, much akin to the Nintendo 64 emulators being developed during that era, and Renderer was the abstraction interface for those plugins. Though Dolphin moved away from plugins fairly quickly, Renderer managed to stick around, consuming work that really should have been elsewhere in the emulator.</p>
<p>This design philosophy did have some limitations, but for the most part it stayed out of the way. At least, until <strong><a href="https://github.com/phire">phire</a></strong> began working on a feature called <em>asynchrounous presentation.</em> Right now, all logic in Dolphin's output (including various GUI element like ImGui) are based on the framerate of the game. This is what causes Dolphin's overlays to look "choppy" in low FPS games (like in <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>) and causes them to completely freeze during periods when a game stops outputting frames (such as during static loading screen or fadeout). Asynchorous presentation would allow us to decouple our output from the game's framerate, correcting all of those issues and paving the way for future goals.</p>
<p>One of those goals is to improve our framepacing. Outside of the very specific circumstance where your display happens to closely match the game's framerate, our framepacing is horrendous. While Freesync/Gsync monitors can mostly mitigate this, most monitors aren't happy with the locked 29.97, 50, or 25 framerate of many supported games. We can't really do much about this when presentation is locked to the game's framerate, so asychronous presentation will be the foundation of our efforts to improve our framepacing. </p>
<p>Kill Renderer <em>is not</em> asynchronous presentation, but it is a major step in that direction. We're highlighting it here because it is a major change to Dolphin's core, and while it <em>shouldn't</em> have any userfacing changes, we've already found and fixed a couple of <a href="https://dolphin-emu.org/download/dev/master/5.0-18818/">major</a> (and <a href="https://dolphin-emu.org/download/dev/master/5.0-18815/">minor</a>) bugs caused by the change.</p>
<h4 id="50-18953-portal-of-power-support-trapteam-audio-by-dereeperjosh"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18953/">5.0-18953 - Portal of Power - Support TrapTeam Audio</a></strong> by <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong><a class="headerlink" href="#50-18953-portal-of-power-support-trapteam-audio-by-dereeperjosh" title="Permanent link">¶</a></h4>
<p>This is a quick update to our <a href="https://dolphin-emu.org/blog/2023/02/12/dolphin-progress-report-december-2022-january-2023/">Portal of Power</a> emulation. <a href="https://wiki.dolphin-emu.org/index.php?title=Skylanders:_Trap_Team">Skylanders: Trap Team</a> introduced a speaker on the portal that could play various audio clips throughout the game.</p>
<p>Understanding the audio packets was a bit complicated, so the emulated portal skipped over this feature initially, but given a little more time, <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> was able to figure out how it worked and borrowed some code from Dolphin's support for Wii Remote Speaker output in order to make it play over the user's speakers.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/nBq9c3g6RGg" allowfullscreen></iframe></div>
<figcaption>Trap Team Audio Demonstration Directly from the Developer.</figcaption>
</figure>
</div>
<h4 id="50-19334-implement-infinity-base-by-dereeperjosh"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19334/">5.0-19334 - Implement Infinity Base</a></strong> by <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong><a class="headerlink" href="#50-19334-implement-infinity-base-by-dereeperjosh" title="Permanent link">¶</a></h4>
<p>Speaking of figurine portals, the <em>Portal of Power</em> wasn't the only USB portal on the Wii. And with <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> already kneedeep in USB portal work, they set their sights on another "portal" accessory for Wii. This time, it'd be the <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> Base. <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> was Disney's answer to the Toy Portal fad that hit during the 7th generation of consoles. By leveraging Disney's vast array of characters, settings, and overall brand, they set out to leverage that into a collectable figurine game. </p>
<p>Unlike Skylanders, which had an overall story and most figurines just inserted a new character or item, Disney Infinity uses "Playsets" that have campaigns around their various properties. You can then play through that campaign with character figures from that playset. Disney Infinity for Wii supports the original six playsets.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/infinitycars.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/infinitycars_thumb.jpg"></a>
<figcaption>Each playset presents unique gameplay and characters.
</figcaption>
</figure>
</div>
<p>Probably the more interesting part of Disney Infinity is the Toybox. Here you can mix and match things you've unlocked from the campaigns to create your own levels.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> might be a <em>unique</em> game, but it's been one that's hard to justify emulating with Dolphin. Not only is this a more limited version of the game compared to other releases, this is the <em>crown jewel</em> of the Disney Trio of Destruction. It currently brings the most powerful machines to their knees, even more so than Cars 2. Worse yet, it's seen even less attention from developers because of the need to have external hardware and figurines to even boot into gameplay!</p>
<p>None of those things stopped <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> from diving in to reverse engineer the base. Fresh from their work in Skylanders, they put what they learned from the last one in action. In truth, the Infinity Base works roughly the same as the Skylander's Portal. A lot of what we explained <a href="https://dolphin-emu.org/blog/2023/02/12/dolphin-progress-report-december-2022-january-2023/">last progress report</a> stands. The figurines only contain a little bit of data on them, and all of the main content is already on the disc. Now, the Infinity figures (and discs) do contain <em>a little</em> bit more data than Skylanders figures, but the end result is the same. These are just little wireless NFC chips in these figures/discs, and the portal reads them to see what figure is on and the game loads the appropriate content off of the disc, maybe with high scores or mini-game progress with the particular figure's game saved back onto it in some cases.</p>
<p><strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> just had to reverse engineer the communication between the base and the Wii and leverage the same GUI used for the Portal of Power. It ended up being a fairly painless process overall, and now you can emulate the Infinity Base in Dolphin! ...That doesn't make Disney Infinity particularly <em>playable</em> due to performance issues, but is one more step in the right direction.</p>
<p><strong>Note</strong>: The GUI isn't quite finished on Dolphin Android yet, so the feature isn't available yet there. Not that it'd be <em>too</em> useful considering that <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> suffers from severe performance issues even on high-end desktops.</p>
<h3 id="new-post-processing-shaders"><strong>New Post Processing Shaders</strong><a class="headerlink" href="#new-post-processing-shaders" title="Permanent link">¶</a></h3>
<p>While Dolphin may not be known for having the most robust Post Processing shader support, over the last couple of months a few interesting shaders were added that some users might find rather nice to use in specific cases.</p>
<p><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18503/">5.0-18503</a></strong> from
<strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> ports over <a href="https://github.com/libretro/slang-shaders/blob/master/interpolation/shaders/sharp-bilinear.slang">sharp bilinear</a> to Dolphin.</p>
<p>Older consoles didn't output square pixels. The CRT displays they were designed for can produce an image with arbitrary horizontal scaling on the signal, so <em>every console would have different pixel aspect ratios</em>, even varying per title! Our modern displays don't work this way - they instead use a fixed pixel grid that can't cleanly reproduce these non-square pixels. The most common solutions to handling this in emulation has been the use of Nearest Neighbor and Bilinear Filtering. Both have their compromises.</p>
<div class="media-block full-width">
<div class="row">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearest1by1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearest1by1.png" /></a>
<figcaption>Say we have a 4x4 grid of pixels. Scaling it up with nearest neighbor scaling is fine if the aspect ratios match.
</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearest5by4.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearest5by4.png" /></a>
<figcaption>But if those pixels are intended to be in a 5:4 aspect ratio? When we scale these up with nearest neighbor, the pixel colums are now uneven. In motion the pixels would appear to "change size" as they move across the screen, which is very distracting.
</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-bilinear5by4.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-bilinear5by4.png" /></a>
<figcaption>Bilinear scaling will have even pixel columns and thus will appear consistent in motion. But it's also very soft.
</figcaption>
</figure>
</div>
</div>
<p>Here it is in practice in a pixel art title you may be familiar with.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/nearest.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/nearest2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Scaling with nearest neighbor will give you a sharp image, but it introduces artifacts. For example, the "shimmering" shown here in the floor tiles. This is a result of unevenly sized pixel columns as they scroll across the screen.
</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/bilinear.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/bilinear2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Bilinear scaling will give solid, reliable results no matter what is going on with the pixel ratios or scaling values. But it will be soft, which is not always an appealing look for pixel art.
</figcaption>
</figure>
</div>
<p>But one day, someone had an idea: why not both? Sharp Bilinear is a combination of both Nearest Neighbor and Bilinear filtering that attempts a best-of-both-worlds result by using the strengths of both filtering techniques.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearestwideaspect.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-nearestwideaspect.png" /></a>
<figcaption>First the image is scaled up with Nearest Neighbor to an exact integer multiple of the input that is at least the desired target resolution. In this case, it is wider than our target due to the aspect ratio mixmatch.
</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-sharpbilinear.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/checkerboard-sharpbilinear.png" /></a>
<figcaption>Then, that output is <em>bilinearly scaled</em> to the target resolution. This can produce a sharp result without uneven pixels.
</figcaption>
</figure>
</div>
</div>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/sharpbilinear.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/sharpbilinear2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>
Here's our pixel art title again to show it in action. Sharp Bilinear is sharp, but without shimmering and other artifacts!
</figcaption>
</figure>
</div>
<p>Sharp Bilinear is made for 2D graphics and specifically pixel art. But nothing says you can't apply it to 3D graphics as well!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/vanilla1x.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/vanilla1x_thumb.png" /></a>
<figcaption>Dolphin scales bilinearly, so running fullscreen at 1x Native on a 8k panel gives a soft image.<br/><sub>Even this is <em>sharper</em> than console output. Console has additional blur passes that we skip, and that's before analog fuzz and potential interlacing.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/sharpbilinear1x.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/sharpbilinear1x_thumb.png" /></a>
<figcaption>With Sharp Bilinear, you can have the unnaturally sharp jaggies you crave! This isn't accurate (in fact it's about as accurate as high Internal Resolutions are) but if you like this look, enjoy.</figcaption>
</figure>
</div>
</div>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/highinternalresolution.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/highinternalresolution_thumb.jpg"></a>
<figcaption>Of course, at higher-than-native Internal Resolutions, Sharp Bilinear doesn't really do anything for 3D Graphics.
</figcaption>
</figure>
</div>
<p>Another Post Processing Shader that's been a part of Dolphin's history <em>just won't die.</em> That's right, we have the glorious return of the legendary ASCII Art Shader from <a href="https://dolphin-emu.org/blog/2020/12/10/dolphin-progress-report-october-2020/#50-12881-remove-asciiart-shader-by-spacexcheesewheel">the ashes of removal</a>. And who would go through the effort to fix it up for modern Dolphin? Well, none other than it's original creator and long-time Dolphin contributor <strong><a href="https://github.com/degasus">degasus</a></strong>! While they're not as active around the project, they couldn't stand to let such an injustice stand and returned to active development to right this incredible wrong. <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-19109/">5.0-19109</a></strong> marks the return of the ASCII Art Shader!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/ascii8k.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/ascii8k_thumb1.jpg" /></a>
<figcaption>At a distance everything seems normal. But if we take a closer look...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/ascii8k.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/ascii8k_thumb2.png" /></a>
<figcaption>It was ASCII Art all along! At 8k, the ASCII blocks can build a 2x Native image, then add additional detail with the ASCII characters!</figcaption>
</figure>
</div>
</div>
<p>This isn't just a straight port of the original - <strong><a href="https://github.com/degasus">degasus</a></strong> has optimized the shader to run on modern graphics cards that support subgrouping. If you have a supported GPU, the shader is now actually somewhat performant! 8k and 60fps is now possible! <span style="white-space: nowrap; font-size:0.5em;">(on an RTX 4090)</span> </p>
<p>With this change, it is likely that <strong><a href="https://github.com/degasus">degasus</a></strong> will return to slumber, at least until the next time we try to remove the ASCII Art Shader.</p>
<h3 id="a-sixth-bounding-box-game"><strong>A Sixth Bounding Box Game!</strong><a class="headerlink" href="#a-sixth-bounding-box-game" title="Permanent link">¶</a></h3>
<p>This is a momentous occasion for us all. After the discovery of <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a>'s <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14257-bounding-box-account-for-pixel-quads-by-techjar">usage of</a> <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14326-bounding-box-add-fallback-for-when-bounding-box-is-unsupported-or-disabled-by-techjar">bounding box</a>, we thought that it was going to be the feature's last dance. Yet, somehow someway, despite the GameCube and Wii no longer seeing retail games, bounding box has found a way.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Solitaire_%26_Mahjong">Solitaire and Mahjong</a> joins the ranks of known bounding box titles after remaining anonymous for many years. It was just obscure enough that it escaped our issue tracker... at least for a time. But eventually, no matter how weird, how unassuming, or how obscure the game is, someone tests it. And if there is an issue, we can only hope that <a href="https://bugs.dolphin-emu.org/issues/13248">they report it to us</a>.</p>
<p>The user in question didn't know that it was a bounding box issue, but by bringing up this game's broken nature to developers, we were finally able to take a look and see why it wasn't working. At first, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> thought that the issue may be XFB related, and <strong><a href="https://github.com/JMC47">JMC47</a></strong> wondered if NAND issues were causing the save files to be hard to click.</p>
<p>But nope, it turned out that the menus were powered by bounding box. A helpful log message kindly pointed this out at boot, but went unnoticed through early testing.</p>
<p><code>E[Video]: BBox shall be used but it is disabled. Please use a gameini to enable it for this game.</code></p>
<p>This game being broken for all of these years was simply due to the default setting of bounding box being set to disabled.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/solitaire-broken.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/solitaire-broken.png" /></a>
<figcaption>This game had a very gray look on old builds.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/solitaire-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2023-february/solitaire-working.png" /></a>
<figcaption>But with bounding box enabled, things are finally rendering correctly.</figcaption>
</figure>
</div>
</div>
<p>Users also reported a "performance" regression with this game, but thankfully that turned out to be a false positive. Essentially, we changed the default values given to a game when Bounding Box was disabled, which caused the game's behavior to change. While <a href="https://dolphin-emu.org/download/dev/master/5.0-14326/">5.0-14326</a> did cause a severe performance regression in this game, turning on bounding box to cause the <em>correct</em> values to be sent fixes it completely. This bisect <em>should have</em> pointed us to this game having a Bounding Box issue, but no one realized it at the time. After all, there were only <em>five</em> Bounding Box titles, and this wasn't one of them! Oops.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Solitaire_%26_Mahjong">Solitaire and Mahjong</a> now joins <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand Year Door</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Magical_Mirror_starring_Mickey_Mouse">Magical Mirror Starring Mickey Mouse</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Hide_%26_Sneak">Disney's Hide and Sneak</a>, and the aforementioned <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> as our bounding box titles.</p>
<p>To prevent <em>yet another</em> game from sneaking through, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> added "bounding box reads" to Dolphin's Usage Statistics. If any users run into this in the future while having Usage Statistics enabled, we'll know about it.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2023-02-01&to=2023-05-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-18501/">5.0-18501</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-19368/">5.0-19368</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: December 2022 and January 2023
2023-02-12T07:28:09+00:002023-02-12T09:26:55.027140+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2023/02/12/dolphin-progress-report-december-2022-january-2023/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/progressreportheader-jan2023.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/progressreportheader-jan2023mini.jpg" />
</header>
<p>We've got a lot of exciting news and features packed into this Progress Report. On top of the normal emulator development, Dolphin's infrastructure has seen a massive overhaul. While most of the work has gone into optimizing our backend and hardware to meet new demands, users may notice some upgrades to user facing features like the <a href="https://wiki.dolphin-emu.org/index.php?title=Main_Page">Dolphin Wiki</a> and <a href="https://fifo.ci/">FifoCI</a>.</p>
<p>Some focus on the infrastructure doesn't mean there was a slowdown in progress for the actual emulator, though! A bevy of new contributors to the project mixed with the efforts of stalwarts has brought together some massive new features no one will want to miss. Headlining this Progress Report is a massive new performance hack called <em>VBI Skip</em>. If you're on a weak device that can't consistently play a game full-speed, VBI Skip is a powerful tool that can help make the game more playable and keep audio crisp and clear. If you're looking for higher performance overall, a ton of Vulkan optimizations and general emulator optimizations have given Dolphin a pretty large performance increase. A new option called <em>Cull Vertices on the CPU</em> can also <em>greatly</em> improve the framerate in many games.</p>
<p>If you're instead looking to enjoy some unique games, the Skylanders games can now be played without needing a physical Portal of Power connected. You can even use your own figurine data to continue where you left off with powerful Skylanders!</p>
<p>We have a lot to get through... but first.</p>
<hr />
<p>It's that time again - we have to warn users of a rather annoying problem that can decimate Dolphin's performance, particularly in mobile devices. The culprit this time is NVIDIA based Optimus laptops - users have been reporting that the discrete NVIDIA graphics card has been giving them a fraction of the performance of Intel's onboard graphics!</p>
<p>We're unsure of what is wrong and haven't been able to determine exactly when it started happening. However, if you find that Dolphin is suddenly running slower than before, you can work-around the issue! Simply add Dolphin to the 3D Settings in the Nvidia Control Panel and set our Power Management setting to "Prefer Maximum Performance." That has been the only way to consistently fix performance.</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/nvcppowersetting.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/nvcppowersetting_thumb.png"></a>
<figcaption><em>A global Maximum Performance Profile does not work</em>, you can only work around the issue by creating a profile specifically for Dolphin Emulator and setting it to Maximum Performance.
</figcaption>
</figure>
</div>
<p>We also have one more announcement to make. For Android users who want the latest development builds on their phone without wanting to wait, we now have an Open Testing Program on the Play Store app.</p>
<p><br/>
<center><iframe src="https://social.dolphin-emu.org/@dolphin/109777973534057737/embed" class="mastodon-embed" style="max-width: 100%; border: 0" width="400" allowfullscreen="allowfullscreen"></iframe><script src="https://social.dolphin-emu.org/embed.js" async="async"></script></center>
<br/></p>
<p>Selecting this option will keep your Dolphin up to date with the latest development builds. This means you'll have access to the latest optimizations and features immediately, without having to wait for the next beta update. However, as with our development builds on desktop, there is always the risk of bugs and/or regressions slipping in and going unnoticed for a bit. If you want to live on the bleeding edge, Dolphin's Open Testing Program is here.</p>
<p>Now with <em>all of that out of the way</em>, let's finally get on with December and January's Notable Changes.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-18271-video-hack-vbi-skip-by-sam-belliveau"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18271/">5.0-18271 - Video Hack - VBI Skip</a></strong> by <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong><a class="headerlink" href="#50-18271-video-hack-vbi-skip-by-sam-belliveau" title="Permanent link">¶</a></h4>
<p>It's very rare that we merge a rather egregious hack. But when one shows up with such potential to drastically improve playability with a minimal impact on maintenance, it was a bit too much to pass up on. The entire story around how this change came out is rather strange.</p>
<p>The key thing to note is that <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> had a stress-inducing final exam and college applications quickly approaching during all of this. Thankfully for all of us, their only solace for procrastination was messing with Dolphin. One of the things they were working on was improving Dolphin's throttling, which led to them messing with what happens when a frame was presented. They then ended up messing with the timing of Vertical Blank Interrupts (VBIs). This is going to be a huge simplification, but they are essentially interrupts timed to the <a href="https://www.youtube.com/watch?v=l4UgZBs7ZGo&t=727s">Vertical Blanking <em>Interval</em></a> on a CRT television (<em>also</em> abbreviated as VBI, though more commonly as VBLANK). Since the Vertical Blanking Interval is how a CRT understands the start/end of each frame, the GameCube, being designed for analog televisions, uses an interrupt to track these and also uses said interrupt to mark of the start/end of each frame internally.</p>
<p>During this experimentation, <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong>'s experimented what would happen if Dolphin simply ignored or <em>skipped</em> a Vertical Blanking Interrupt when Dolphin was lagging. While their goal was to improve framepacing, the result they got when testing <a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Sports_Resort">Wii Sports Resort</a> was something no one expected.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/viskipdemo4_cropped.mp4" type="video/mp4"/>
</video></div>
<figcaption>Despite running at ~45 FPS, the game audio was sounding crisp and clear in our first glimpse of the hack in action. Enable audio to see why this turned heads when it was shown off.</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> announced what was discovered with a longer version of the video above. It displayed a game lagging significantly while maintaining crisp audio and snappy controls. This turned a lot of heads, and the feature was quickly given the name <em>VI Skip</em>. ...but that was too close to Video Interface which we regularly abbreviate to VI, so we renamed it to <em>VBI Skip</em> for clarity.</p>
<p>A hack like this would normally be a bigger controversy, but the method in which it worked made it a lot more enticing. The initial version of VBI Skip was <em>only 11 lines of code</em>! Additionally, it would only activate itself <em>if Dolphin was lagging</em>. And just because VBI Skip is active doesn't mean game logic will slowdown - some games can instead frameskip instead, depending on how the game works. </p>
<hr />
<p>Developers were initially skeptical about the compatibility of a hack like this. Thankfully, <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> quickly unleashed it for everyone to test. And while VBI Skip doesn't <em>directly</em> improve framerate, it can drastically improve the playability of a game that isn't running at full speed.</p>
<p>To see the pure potential of VBI Skip, we can show a compatible game with an underpowered device. For example, <a href="https://wiki.dolphin-emu.org/index.php?title=Crash_Bandicoot:_The_Wrath_of_Cortex">Crash Bandicoot: Wrath of Cortex</a> is far too demanding for a Pixel 3a featuring an Adreno 615. The opening cutscene makes this readily apparent.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/cbvioff_cropped.mp4" type="video/mp4"/>
</video></div>
<figcaption>The framerate tanks and audio lags as the poor Pixel 3a can't keep up.</figcaption>
</figure>
</div>
<p>However, <a href="https://wiki.dolphin-emu.org/index.php?title=Crash_Bandicoot:_The_Wrath_of_Cortex">Crash Bandicoot</a> is compatible with VBI Skip and can give the weak device a fighting chance to run the game.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/cbvion_cropped.mp4" type="video/mp4"/>
</video></div>
<figcaption>Though it isn't as smooth as it should be, the game runs at a playable speed, without slowing down or distorting the audio. Note however that the framerate is still lower, but due to the limited motion in this cutscene it isn't as as obvious here as it would be in game.</figcaption>
</figure>
</div>
<p>VBI Skip is a powerful tool for weaker devices, especially in games that struggle. <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand Year Door</a>'s Bounding Box effects are torture for weaker phones, but VBI Skip gives them a fighting chance. It's obviously not perfect, but the mixture of slowdown and frameskip keeps the game fairly playable.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/pmttydvion_cropped.mp4" type="video/mp4"/>
</video></div>
<figcaption>During Bounding Box effects like the boat flip, this poor phone ends up skipping a lot of VBIs!</figcaption>
</figure>
</div>
<p>But here comes the rather interesting part of this. We once had a <em>frameskip</em> implementation, but it only worked under very specific conditions, didn't actually improve performance much at all, and was <em>completely broken</em> for years before it was ultimately <a href="https://github.com/dolphin-emu/dolphin/pull/4322">removed</a>. Dolphin's developers were convinced that due to the complexity of the GameCube and Wii, a frameskip-like hack was effectively impossible for Dolphin. Yet, here is VBI Skip accomplishing the same feature with higher compatibility and bigger gains, all while dynamically activating and deactivating itself depending on if Dolphin is lagging. Why does VBI Skip work where frameskip did not?</p>
<p><br/>
<center><span style="font-size: 1.25em;"><strong>No one knows.</strong></span></center>
<br/></p>
<p>Veterans of the Dolphin project said that VBI Skip should run games at half speed or crash outright. Developers from outside of the project called it "disgusting." We even had friends at <a href="https://pcsx2.net/">PCSX2</a> quickly hack in the feature and test the PS2 version of <a href="https://wiki.pcsx2.net/Crash_Bandicoot:_The_Wrath_of_Cortex">Crash Bandicoot: Wrath of Cortex</a>, where the game immediately froze. And yet the majority of games in Dolphin are okay with this egregious hack, and we have no idea why. There are some theories that the environment the games were developed under did something to make them tolerant of this, but we genuinely do not know why VBI Skip works at all.</p>
<p><em>But it does.</em></p>
<p>However, though this hack is an amazing thing that shouldn't exist but does... it isn't without flaws. It works for <em>a lot of games</em> but not <em>all games.</em> And because the hack itself is quite simple and we don't have a great understanding of why VBI Skip works, there isn't much that we can do about it.</p>
<p>The good news is that VBI Skip tends to fail rather obviously when it isn't compatible with a game, making it easy to flag down those games and disable the feature. For instance, both <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">Twilight Princess</a> stop rendering if VBI Skip is active in-game. This is because they don't actually use Vertical Blanking Interupts, but instead use shadow registers to manage their own timings for presentation. <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">Wind Waker</a> in particular is extremely touchy. The game's developers went so far as to lock the <em>PAL</em> version of the game to 30 FPS in PAL50, just so they wouldn't have to touch those timings!</p>
<p>Other games, like many in the <a href="https://wiki.dolphin-emu.org/index.php?title=Need_for_Speed:_Carbon_(Wii)">Need for Speed series</a>, have a strange "dynamic" framerate that doesn't play nicely with the hack - causing even worse lag.</p>
<p>VBI Skip is also compatible with some games that you might not expect. For instance, it can be used in Dual Core sensitive titles like <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars: Rogue Squadron III</a> that tend to reject a lot of Dolphin's other performance hacks.</p>
<p>Overall compatibility is actually surprisingly good, though we're sure that more edge-cases and potential issues will crop up through wider testing. More quirks are bound to be found now that VBI Skip is out in the wild, but we are confident enough in our early testing to push it through so that users can try it out. We know a lot of our users are on limited hardware and this is a feature that can turn a painful experience into an enjoyable one.</p>
<hr />
<p><em>Note: VBI Skip was originally named <strong>VI Skip</strong>. However, during the process of writing this article we realized just how easy it was to confuse with VIdeo Interface (VI), and after consulting with samb and other developers, we decided to rush to rename it to VBI Skip. As a consequence, the beta build that is being released along side this Progress Report still lists it as VI Skip. However, it was changed in <a href="https://dolphin-emu.org/download/dev/master/5.0-18628/">5.0-18628</a> so dev builds reflect this change, and all subsequent beta builds will call it VBI Skip. We apologize for any confusion this may have caused, but we decided that this was the best course of action to limit confusion long term.</em></p>
<h4 id="50-18086-new-frametimevblank-analyzer-graph-by-sam-belliveau"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18086/">5.0-18086 - New FrameTime/VBlank Analyzer + Graph</a></strong> by <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong><a class="headerlink" href="#50-18086-new-frametimevblank-analyzer-graph-by-sam-belliveau" title="Permanent link">¶</a></h4>
<p>Did you notice the branch name that <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong>'s was on during the first video with VBI Skip? And did you see that frametime graph that was being used to check for framepacing? Well that was what <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> was working on when they discovered VBI Skip. In fact, VBI Skip was actually merged <em>afterwards</em>, and the initial changes made for measuring framepacing were actually integral towards implementing the hack.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/fzerogxframepacing.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/fzerogxframepacing_thumb.png"></a>
<figcaption>The new graphs are powerful and give developers a bigger picture on performance and framepacing.
</figcaption>
</figure>
</div>
<p>For most users, the new graphs are a bit overkill. However, there are some other new features to our performance statistics display that might give users a better idea of how they're performing. The most notable of which is a new "speed" display that actually will tell you what your current performance and what your potential maximum performance would be without having to disable the framelimiter. These features can be enabled in the performance statistics section of Graphics Settings -> Advanced on desktop builds and now Android builds as well.</p>
<h4 id="50-18299-implement-emulated-skylanders-portal-of-power-by-dereeperjosh-and-mandar1jn-with-code-relicenced-to-gplv2-for-dolphin-from-ripleytom"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18299/">5.0-18299 - Implement Emulated Skylanders Portal of Power</a></strong> by <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> and <strong><a href="https://github.com/mandar1jn">mandar1jn</a></strong> with code relicenced to GPLV2+ for Dolphin from <strong><a href="https://github.com/RipleyTom">RipleyTom</a></strong><a class="headerlink" href="#50-18299-implement-emulated-skylanders-portal-of-power-by-dereeperjosh-and-mandar1jn-with-code-relicenced-to-gplv2-for-dolphin-from-ripleytom" title="Permanent link">¶</a></h4>
<p>Together, these games make up four adventure platformers with hundreds of unique characters and a <a href="https://wiki.dolphin-emu.org/index.php?title=Skylanders:_SuperChargers_Racing">racing game</a>. Regardless of the type of game, at the center of each game, the key to playing them revolves around figurines you can get called "Skylanders" which enter the game through a USB device called the Portal of Power.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/portalofpower.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/portalofpower_thumb.jpg"></a>
<figcaption>Does your Portal of Power look this cool?
</figcaption>
</figure>
</div>
<p>There were ~450 different figurines and 172 base characters and 39 magic items. The <a href="https://wiki.dolphin-emu.org/index.php?title=Skylanders:_Trap_Team">Trap Team</a> portal also features a speaker that boss characters could taunt you through. Some figurines could even unlock new areas in games.</p>
<hr />
<p>For all the potential of a game like this, there is a cruel reality to it. The figurines are simply containers for the Near Field Communication (NFC) chips that get read by the portal. They hold very little data: just an ID, character stats, and the applied hat. All of the real data is on the disc. The game just uses the ID to "unlock" that content and give the illusion that the figure is being sucked into the game. However, this is more than just a gimmick. The Skylanders games <em>will not allow you to play without a figurine</em> - they are a fundamental part of <s>their business model</s> the game. They even went as far as to gate significant features behind specific figurines!</p>
<p>In Dolphin, setting up a Skylanders game was a unique experience. Dolphin has <a href="https://dolphin-emu.org/blog/2016/01/26/wii-usb-hid-support/">long supported the <em>physical</em> Skylanders Portal of Power</a>. It was a little cumbersome, but once set up, Dolphin's USB HID implementation allows users to play their IRL figures in Dolphin just as the game was designed. However, this feature was unavailable on Android, making the Skylanders series inaccessible to our Dolphin Android users.</p>
<p><strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> has been requesting support for several years hoping to be able to enjoy the games on Dolphin without having to dig out their portal every time. Using the <a href="https://github.com/RPCS3/rpcs3/pull/5688">RPCS3 Emulated Portal of Power implementation</a> as the basis for a Dolphin implementation, <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> took matters into their own hands to try to bring an Emulated Portal of Power over to Dolphin. A lot of the code from <strong><a href="https://github.com/RipleyTom">RipleyTom</a></strong>'s RPCS3 implementation was used at the core of the change but <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> still had a lot of work to do to make it work within Dolphin. <strong><a href="https://github.com/mandar1jn">mandar1jn</a></strong> provided <a href="https://marijnkneppers.dev/posts">expertise</a> along with tools that allowed for testing data from the generated figurines and comparing them to figurine data from a real portal.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skylandersandgui.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skylandersandgui_thumb.jpg"></a>
<figcaption>Using the new emulated Portal you can create blank Skylanders, or load real figurine data complete with save progress.
</figcaption>
</figure>
</div>
<p>For Dolphin on Android users, <strong><a href="https://github.com/deReeperJosh">deReeperJosh</a></strong> decided to put in some extra work after the initial merge and as of <a href="https://dolphin-emu.org/download/dev/643726110b723b287590058f9fa802502c5db0d6/">5.0-18497</a>, the emulated portal GUI has been ported over to Android. Considering that USB HID passthrough isn't available on Android, this is the only option for playing these games. For our Android users, the feature is located Options -> Wii and has to be enabled there.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skylandersandroid.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skylandersandroid_thumb.jpg"></a>
<figcaption>
</figcaption>
</figure>
</div>
<p>All of this together results in the arrival of a long requested feature. Again, we have to thank <strong><a href="https://github.com/RipleyTom">RipleyTom</a></strong> for the original implementation for <a href="https://rpcs3.net/">RPCS3</a> and allowing the code to be licensed under GPLv2+ for Dolphin.</p>
<p><strong>Note:</strong> <em>As with all electronics, Skylanders figurines have a chance of failure, resulting in a useless figurine. While Skylanders figurines don't have batteries and are powered by the portal itself, their NFC chips do have a slight failure rate and they are likely only guaranteed to a certain number of read/writes before failure.</em></p>
<h4 id="50-18355-allow-dolphin-to-manually-cull-vertices-on-the-cpu-by-tellowkrinkle"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18355/">5.0-18355 - Allow Dolphin to Manually Cull Vertices on the CPU</a></strong> by <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong><a class="headerlink" href="#50-18355-allow-dolphin-to-manually-cull-vertices-on-the-cpu-by-tellowkrinkle" title="Permanent link">¶</a></h4>
<p>Normally, this would be a headlining feature of most Progress Reports. But you know, <em>VBI Skip</em>. Still, we couldn't let the juggernaut in the room completely drown out this excellent performance improvement.</p>
<p>For many years, <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Metroid_Prime_(Series)">the Metroid Prime games</a> and their insane way of drawing the map with a mixture of line-width, point-size, and triangles has decimated performance on modern GPUs. The way they alternate between lines, points, and triangles makes our batching optimizations inapplicable, forcing Dolphin to use a tremendous number of draw calls in order to emulate what the games are doing. This isn't an isolated incident, either, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">The Legend of Zelda: Twilight Princess</a> does a similar thing when drawing its own minimap, just on a much more damaging level to the point where developers <a href="https://github.com/dolphin-emu/dolphin/commit/040a6e1eb33ceccccf3e4c7d790e46657288c9fe">initially patched it out directly in Dolphin's source code!</a> </p>
<p><strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> noticed that a lot of these triangles weren't actually getting used, suggesting that these extra triangles may have been trying to avoid a hardware bug. If Dolphin could somehow detect this, we could reduce the number of draw calls significantly and reduce the performance impact of these tremendously damaging scenes. And thus, <em>Cull Vertices on the CPU</em> was born.</p>
<p><br/>
<script>
addChart({"title":{"text":"CPU Vertex Culling"},"subtitle":{"text":"AMD 5950x with a RTX 3060"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"series":[{"name":"CPU Cull Off","turboThreshold":0,"marker":{}},{"name":"CPU Cull On","turboThreshold":0}],"data":{"csv":"\"Game\";\"CPU Cull Off\";\"CPU Cull On\"\n\"Twilight Princess GC - Hyrule Field without hack (30FPS Title)\";31;43\n\"Densha de Go! Shinkansen EX - City Area\";71;83\n\"Rogue Squadron 3 - Battlefield Hoth\";58;60\n\"Mario Galaxy - Hub\";143;140\n\"Metroid Prime 2 - Full Agon Wastes Map\";102;122","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"tickInterval":30,"max":150,"labels":{"format":"{value}FPS"}},"pane":{"background":[]},"responsive":{"rules":[]},"xAxis":{"title":{},"labels":{}},"colors":["#ff3100","#006eff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"legend":{}})
</script>
<br/></p>
<p>In cases where games are using a lot of triangles but not all of them are actually visible, Cull Vertices on the CPU can ease the drawcall bottleneck. Unlike some of the existing solutions to make these maps faster, such as disabling geometry shader support in old builds or the famous <em>Hyrule Field Speed Hack</em>, Cull Vertices on the CPU doesn't actually result in any graphical glitching. This allows players to finally run Hyrule Field at full speed without having to compromise the look of the minimap.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/twilightmap-hack.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/twilightmap-hack_thumb.jpg" /></a>
<figcaption>The "Hyrule Field Speed Hack" patch greatly reduces the number of draw calls but affects the look of the minimap.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/twilightmap-cull.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/twilightmap-cull_thumb.jpg" /></a>
<figcaption>With CPU Cull on and the patch disabled, the minimap will look correct while still delivering a sizeable performance increase.</figcaption>
</figure>
</div>
</div>
<p>For people on lower-end hardware, the "Hyrule Field Speed Hack" patch is still faster than CPU Culling because it removes some triangles/lines/points that are actually visible. But, if you want the minimap to look correct, CPU Cull is an effective alternative for higher end devices. Without either of these options, the game is left incredibly slow in Hyrule Field and Faron Woods.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">Twilight Princess</a> has to be considered an extreme example. After all, there were already targeted hacks and patches toward its difficult rendering method. But, a game doesn't have to be doing something exceptional to see improvements from Cull Vertices on the CPU. <a href="https://wiki.dolphin-emu.org/index.php?title=Densha_de_Go!_Shinkansen_EX">Densha de Go!</a> sees significant benefits simply because it isn't very optimal with culling vertices, and Dolphin usually saves more than enough draw calls to gain a sizeable performance boost in every zone of the game.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/denshadego.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/denshadego_thumb.jpg"></a>
<figcaption>As a train driver, I'm always on time but I never stop.
</figcaption>
</figure>
</div>
<p>There is the case where a game is so optimized that Dolphin trying to cull vertices on the CPU actually ends up <em>lowering</em> performance because it isn't saving enough draw calls to make back the CPU overhead. As such, it is no accident that <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> shows up slower on the graph above with CPU culling enabled. It takes an extra ~2 - 3% of CPU performance to analyze things and try to cull vertices, and we just don't gain enough in this game in most areas.</p>
<p>Because we can't guarantee this option will be faster in most games, we've decided to default CPU culling to <strong>off</strong>. It's a safe feature that won't cause crashes or graphical issues, but we wanted to give it a trial period where users can enable it and see how it affects their favorite games.</p>
<p>For games that see a huge benefit, we've currently enabled it by default via GameINI.</p>
<h4 id="50-18192-emulate-ppc-datacache-by-mkwcat"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18192/">5.0-18192 - Emulate PPC Datacache</a></strong> by <strong><a href="https://github.com/mkwcat">mkwcat</a></strong><a class="headerlink" href="#50-18192-emulate-ppc-datacache-by-mkwcat" title="Permanent link">¶</a></h4>
<p>Proper CPU dcache emulation was something that none of us were really expecting. After all, dcache emulation was going to be very slow, and most uses of dcache emulation were caused by game bugs. Patching the games was not only easier in most cases, but also didn't come with the hefty performance penalty that correctly emulating those bugs would entail.</p>
<p>But none of that mattered to <strong><a href="https://github.com/mkwcat">mkwcat</a></strong>. They were on a different kind of mission. They were on a personal challenge to crack into CTGP-R's anti-emulation/cheat security. For those that don't know, CTGP-R is a prestigious <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> mod where many top players compete for the fastest time trial times. On top of being a trusted closed garden for time trial competition, CTGP-R also has hundreds of custom tracks and many new offline and online game modes.</p>
<p>While Dolphin developers usually focus on officially released titles, we occasionally get issue reports regarding popular mods that users want to run in Dolphin. These issues are usually treated as valid - after all, these mods and romhacks run on the real console, so it doesn't seem unreasonable to try to make sure they are emulated properly when possible. CTGP-R ended up a special case - the developers <em>absolutely did not want Dolphin running their mod</em>. They went as far as to add features to their hack to detect and prevent Dolphin from running it.</p>
<p>This decision by the CTGP-R developers wasn't entirely unwarranted. They wanted to have a closed, trusted environment where players could run time-trials and be confident that the times they were running against weren't cheated. They saw the ability to run the mod on Dolphin as a huge security liability, and took measures to make sure it didn't happen. There are other listed reasons, but this was the main crux of the issue. Because of the situation, we told users we had no intention of going out of our way to emulate the mod.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/petition.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/petition_thumb.jpg"></a>
<figcaption>With both CTGP-R and Dolphin's developers turning them away, Dolphin's users took matters into their own hands.
</figcaption>
</figure>
</div>
<p>Given the situation, our users have developed a bit of animosity toward the CTGP-R project. After all, the MKWii mod is going out of its way to make sure it doesn't run under emulation. But if you travel back to when a lot of development was happening, their fears of cheating aren't exactly unfounded.</p>
<p>Back when Wiimmfi was new and the Nintendo Wi-Fi Connect services had just shut down, Dolphin was a <em>very</em> popular tool to go onto <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> and cheat. It was way easier to do this on the emulator than to do it on the console. And if you got banned on Dolphin, it was a lot easier to spoof a new console ID than on a real Wii.</p>
<p>The early days of Wi-Fi replacement servers were rife with users using item hacks, timer hacks, and more.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/mkcheats.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/mkcheats.png"></a>
<figcaption>Dolphin's easy to access cheat system meant that users could create and enable cheats for just about anything, and just as easily take them online.
</figcaption>
</figure>
</div>
<p>Thankfully, Wiimmfi didn't end up completely banning Dolphin users, but instead mandated more authentication for Dolphin users that required such steps as using a real Wii NAND dump and a seven day wait period for all new users. Considering how much work and thought Wiimmfi developers have gone through in order to make things fair for players online, it's hard to fault CTGP-R developers for their stance.</p>
<p>However, times change, and over the years Dolphin's emulation has improved dramatically. While developers never directly targeted CTGP-R, overall improvements of Wii emulation brought Dolphin closer to being able to run it. In fact, by the time <strong><a href="https://github.com/mkwcat">mkwcat</a></strong> showed up, their goal wasn't even to get CTGP-R running on Dolphin. They were simply examining some of the anti-hacking and anti-emulation code in the executable, and realized that Dolphin wasn't very far from being able to run it.</p>
<p><br/><blockquote style="font-size:1.1em">
I decided to take a look at it in detail and figure out what specific parts of the code were not being emulated properly. I found I could make four instruction patches to get it to at least boot, but there was one particular issue with the UPMC registers not mirroring the PMC registers which was not easy to simply patch out, so I decided to fix the issue in Dolphin itself. </p>
<p>After seeing the icache implementation, I thought it was feasible to adapt it into a data cache, and it really was. After only a few hours iirc I was able to make it accurate enough to emulate CTGP's boot stage correctly using Interpreter, though it broke everything else from working properly.
<footer>mkwcat</footer></blockquote><br/></p>
<p>A few weeks later, a user from the <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> community mentioned a branch of Dolphin that could run CTGP-R by implementing dcache emulation. This caught the eye of Dolphin's developers, and a discussion soon took place which then pulled in the branch's creator, <strong><a href="https://github.com/mkwcat">mkwcat</a></strong>. Realizing there was interest in dcache emulation from the main project, they submitted a pull request and after a lengthy review process, dcache emulation hit Dolphin.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/ctgprdownload.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/ctgprdownload_thumb.jpg"></a>
<figcaption>The first step to running CTGP-R in Dolphin is going through a painfully long installation process.
</figcaption>
</figure>
</div>
<p>Before you go installing CTGP-R in Dolphin, please remember that dcache emulation is <em>incredibly expensive</em>. Only on the most powerful of computers will you manage to get decent speed on tracks in time trial mode. Even if you can reach full speed in sections, because memory operations are so much more expensive, expect stutters whenever anything is loaded.</p>
<p>And for those with nefarious intentions, don't even try to use Dolphin to cheat in CTGP-R. While Dolphin can boot and run CTGP-R, the mod still has additional layers of detection that are able to detect Dolphin and prevent the submission of times and ghosts. As well, Dolphin <em>openly announces itself to mods</em> with a special device Wii mods can access.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/ctgpringame.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/ctgpringame_thumb.jpg"></a>
<figcaption>Once in game, the single player more or less works. To help performance, you can disable dcache emulation after completing the boot process by saving state, turning off dcache, loading Mario Kart Wii, and then loading the savestate you made in CTGP-R.
</figcaption>
</figure>
</div>
<p>Outside of CTGP-R, dcache emulation can also be applied to other dcache sensitive titles if you want to run them without hacks/patches applied. This includes games like <a href="https://wiki.dolphin-emu.org/index.php?title=Ten_Pin_Alley_2">Ten Pin Alley 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Dead_to_Rights">Dead to Rights</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Casper%27s_Scare_School:_Spooky_Sports_Day">Casper's Scare School: Spooky Sports Day</a>. </p>
<p>This also allows <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Cars_2">Cars 2</a> to boot <em>without</em> any special hacks. However, performance is reduced <em>even more than normal</em>. As such, for any dcache sensitive game with an existing patch, we highly recommend that players use our included hacks when possible.</p>
<h4 id="50-18242-change-default-user-directory-location-to-appdata-on-windows-and-50-18238-menubar-add-action-which-opens-the-user-folder-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18242/">5.0-18242 - Change default user directory location to AppData on Windows</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18238/">5.0-18238 - Menubar: Add action which opens the user folder</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-18242-change-default-user-directory-location-to-appdata-on-windows-and-50-18238-menubar-add-action-which-opens-the-user-folder-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>Dolphin's Global User directory has stayed in the same place on Windows since it was first introduced <a href="https://dolphin-emu.org/blog/2013/09/22/dolphin-40-release-announcement/">with the launch of Dolphin 4.0</a>. Placed within <em>My Documents</em>, we wanted to keep the User directory in an easily findable place because it stores <em>more</em> than just save files. Users can find screenshots, resource packs, logs, configurations, and more all within the Global User Directory. While many of our users do use <em>Portable Mode</em> or <a href="https://dolphin-emu.org/docs/guides/controlling-global-user-directory/">move the directory themselves</a>, most users simply use the default setup.</p>
<p>When this choice was made, <em>My Documents</em> was the perfect choice. It was a mixture of an easy to find spot and a fairly safe spot where the user isn't going to accidentally delete their save data. Unfortunately, the ever changing landscape of computers has made using My Documents more of a headache than it is worth.</p>
<p>One of the biggest problems is Microsoft's very own <em>OneDrive</em>. While OneDrive may be good at backing up files, it is an absolute <em>nightmare</em> to use with Dolphin. Emulating the Wii NAND often has Dolphin making lots of small writes to a lot of files. However, OneDrive will lock down any files it is currently backing up, <em>even if Dolphin is still using it.</em> In extreme cases, OneDrive can actually cause Wii games to stop booting on a Windows PC, and cause savedata loss in GameCube games.</p>
<p>The other problem is a recent(ish) wave of malware that would encrypt important files on your computer and require you to pay a fee to get them unencrypted. Again, Dolphin's handling of Wii NAND emulation with tons of small writes to a lot of files in <em>My Documents</em> makes machine learning based anti-virus/anti-malware programs go on alert and block writes. This can cause Wii games to not boot <em>and</em> end up corrupting the NAND. We've let these vendors know about the problem, and they were more than happy to whitelist us. However, due to simple hash-based whitelisting procedures, every new build of Dolphin would have to be whitelisted separately after being reported by a user. This was not great.</p>
<p>The only way to alleviate these problems was for Dolphin to place its files where these applications expected programs to keep their files - AppData. This hidden folder is basically the Windows catch-all place for programs to keep their stuff, and Windows has strong restrictions in place there to limit programs to only their own little nook. Thanks to those protections, antivirus programs know that they don't need to watch AppData as closely, and have explicit exceptions for the folder. OneDrive also doesn't back up this folder (outside of specific files), so it will never interfere with writing files there. AppData is the <em>only</em> place like this on Windows. While we like the accessibility of My Documents, we had no choice but to move our default global user directory location to AppData to get these applications to stop bothering us and our users.</p>
<p>For those of you who are using My Documents with no problems, don't worry. We aren't going to change anything. If Dolphin (even new builds) see the Global User Directory in My Documents, it will continue to use it as normal. However for new Windows installs of Dolphin, the AppData directory will be chosen instead.</p>
<p>Because the AppData folder is a hidden directory that can be hard to find, we've added a new option to the Menu Bar that will open a file browser window directly in the Global User Directory. We hope that this compromise eases some of the inconveniences of the new location.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/openuserfolder.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/openuserfolder_thumb.png"></a>
<figcaption>Handy! But be careful in there - that's where your saves and settings are stored.
</figcaption>
</figure>
</div>
<h4 id="50-18025-add-option-for-force-nearest-or-linear-texture-filtering-by-leo60228-and-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18025/">5.0-18025 - Add Option for Force Nearest Or Linear Texture Filtering</a></strong> by <strong><a href="https://github.com/leo60228">leo60228</a></strong> and <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-18025-add-option-for-force-nearest-or-linear-texture-filtering-by-leo60228-and-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>This is another long awaited option that has been debated for quite a while. Originally submitted by <strong><a href="https://github.com/leo60228">leo60228</a></strong> nearly three years ago, the ability to <em>force</em> various texture filtering modes has been up for debate ever since.</p>
<p>The biggest question was about the <em>value</em> of the feature. Games already set texture filtering on their own - and with Manual Texture Sampling, we can emulate that to a very exact degree. Forcing it to render <em>differently</em> could not only cause bugs, but could make games look blurry or pixelated.</p>
<p>However, as time went on and we saw more user feedback, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> determined the feature did have some merit and decided to rebase the original changes and reorganize the GUI in order to make it cost less space.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/texturefilteringgui.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/texturefilteringgui.png"></a>
<figcaption>The old Anisotropic Filtering menu has been repurposed for all texture filtering features!
</figcaption>
</figure>
</div>
<p>While giving users the ability to customize the look of the games they are playing is a definite perk, the reason for finally giving users this control is that it presents a work around for game bugs. Usually, a game developer making games on the GameCube will choose whatever texture filtering is best for the game. However, there are many cases where the original developer choose poorly, and presenting this option allows users to correct it. There are even cases where a game is outright <em>broken</em> on console due to texture sampling issues, and forcing nearest neighbor can actually work-around those defects!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sexypokerlinear.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sexypokerlinear_thumb.jpg" /></a>
<figcaption>Sexy Poker has texture defects even on console, but they're incredibly visible in Dolphin at higher resolutions.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sexypokernearest.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sexypokernearest_thumb.jpg" /></a>
<figcaption>Forcing Nearest Neighbor can erase the defects allowing you to immerse yourself into this legendary card game.</a></figcaption>
</figure>
</div>
</div>
<p>If you're looking for a more notable example than the venerable <a href="https://wiki.dolphin-emu.org/index.php?title=Sexy_Poker">Sexy Poker</a>, the GameCube version of <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Gems_Collection">Sonic CD in Sonic Gems Collection</a> is significantly blurrier than the Playstation 2 version because everything is bilinearly filtered in the internal emulator. While some users may prefer that, most players have deemed it to be a flaw. By forcing nearest in Dolphin, you can finally have the crisp pixels you crave in the GameCube version.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sonic-linear.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sonic-linear_thumb.png" /></a>
<figcaption>
<a href="https://youtu.be/qK8oohv6sgU?t=1261">Even Digital Foundry complained about how blurry Sonic CD looks on GameCube.</a>
</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sonic-nearest.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/sonic-nearest_thumb.png" /></a>
<figcaption>At least now you can choose to change one of the port's differences.</a></figcaption>
</figure>
</div>
</div>
<p>One of the reasons we chose to finally present forcing <strong>nearest</strong> texture filtering is because we already had a feature for forcing <strong>linear</strong> texture filtering. This "Force Texture Filtering" option was added long long ago to work around a quirk of two premiere Nintendo titles - <a href="https://wiki.dolphin-emu.org/index.php?title=New_Super_Mario_Bros._Wii">New Super Mario Bros. Wii</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">The Legend of Zelda: Skyward Sword</a>.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skywardsword-banding.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skywardsword-banding_thumb.jpg" /></a>
<figcaption>Skyward Sword's shading gets chunky at higher than native internal resolutions.
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skywardsword-nobanding.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/skywardsword-nobanding_thumb.jpg" /></a>
<figcaption>Forcing linear texture filtering resolves this issue.</figcaption>
</figure>
</div>
</div>
<p>Now the existing "Force Texture Filtering" option has been collected together with all the other texture filtering controls in one place, ready for users to adjust as they see fit.</p>
<h4 id="50-18017-jitarm64-implement-accuratenans-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18017/">5.0-18017 - JitARM64 - Implement AccurateNaNs</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-18017-jitarm64-implement-accuratenans-by-josjuice" title="Permanent link">¶</a></h4>
<p>This is a change with a rather funny story behind it, and actually goes back several years. Jump back to <a href="https://dolphin-emu.org/blog/2015/07/01/dolphin-progress-report-june-2015/#40-6704-optionally-emulate-accurate-nans-by-flacs">June of 2015</a> and <em>AccurateNaNs</em> was being implemented for our x86-64 JIT. Essentially, it makes emulation of NaNs (Not A Number) more accurate by having our own custom handlers for them rather than just letting the host processor handle it. This is slower, but is necessary to prevent calamities like this one in <a href="https://wiki.dolphin-emu.org/index.php?title=Dragon_Ball:_Revenge_of_King_Piccolo">Dragon Ball: Revenge of King Piccolo</a></p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/CostlyWaterloggedBubblefish.mp4" type="video/mp4"/>
</video></div>
<figcaption>If you remember this, then you're truly one of the OGs of the Dolphin Blog. Note that you have to defeat all the enemies to proceed, but some of them are sent to a far away place...</figcaption>
</figure>
</div>
<p>However, this was never implemented in our AArch64 JIT for ARM 64-bit processors. Because, quite frankly, it didn't need it. The NaN behavior on AArch64 matched PowerPC closely enough that these games just worked without needing special handling.</p>
<p>But wait, the title of this section is Implement AccurateNaNs on AArch64. What changed?</p>
<p>Well, AArch64 and PPC NaN handling aren't <em>exactly</em> the same, it was just getting good enough results at the time. But Dolphin recently changed <a href="https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-report-august-2021/#50-14795-jit-fix-fma-negation-ordering-by-josjuice">how we handle FMA (Fused-Multiply Add) instructions</a> in order to fix online desyncs between real console and Dolphin in <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a>.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-desync_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Unlike the Dragonball issue, this one effected both our x86-64 JIT and our AArch64 JITback in the day!<br/><sub>Click/Tap to play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-desync.mp4">HERE</a> for a higher quality version.</sub></figcaption>
</figure>
</div>
<p>This fix was applied to both JITs, and no one was the wiser that we had inadvertently broken <a href="https://wiki.dolphin-emu.org/index.php?title=Dragon_Ball:_Revenge_of_King_Piccolo">Dragon Ball: Revenge of King Piccolo</a>. Some FMA instructions invert the sign of output, but only if the output is <em>not</em> NaN. The Inazuma FMA fix changed how we handle FMA instructions <em>just enough</em>, that on AArch64 the sign of NaNs for <code>nmadd</code> / <code>nmsub</code> instructions were inverted, breaking Revenge of King Piccolo. A user reported that the game was broken to some very confused developers, but considering we had seen this <em>exact</em> bug before in our x86-64 JIT, it was just a matter of fixing it in the other JIT. As our resident AArch64 JIT maintainer, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> was pulled into action to implement Accurate NaNs on ARM.</p>
<p>Because emulating NaNs in this manner is a slight performance reduction, it is only enabled in one title currently: <a href="https://wiki.dolphin-emu.org/index.php?title=Dragon_Ball:_Revenge_of_King_Piccolo">Dragon Ball: Revenge of King Piccolo</a>.</p>
<h4 id="50-18257-remove-boot-from-dvd-backup-by-mayimilae"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18257/">5.0-18257 - Remove Boot from DVD Backup</a></strong> by <strong><a href="https://github.com/MayImilae">MayImilae</a></strong><a class="headerlink" href="#50-18257-remove-boot-from-dvd-backup-by-mayimilae" title="Permanent link">¶</a></h4>
<p>Unlike many other consoles from the era, the GameCube and Wii use modified DVDs that can't be read by conventional DVD drives used on desktops. These modified DVDs are physically identical to normal DVDs, but Nintendo partnered with Panasonic, one of the creators of DVD, to slightly modify the sector format and error correction. A regular DVD drive doesn't understand this format and thinks every single sector is corrupted, never returning any data to your computer. This differs from many Playstation and Playstation 2 emulators, which can directly run original games </p>
<p>Yet despite that fact, Dolphin had the ability to boot from the host computer's DVD drives. This was implemented so Dolphin could read GameCube and Wii games burned to DVD backup discs. And yes, that requires a user to rip their games from their Wii, then burn them <em>back</em> onto blank DVD media.</p>
<p>Why would anyone want to do that? Back in the early through mid 2000s, drive space was much more limited than what we have today. The average hard-drive size was just 120 GB. Even if you bought that drive <em>just</em> for GameCube and Wii emulation, as few as <strong>14</strong> uncompressed Wii dumps would fill that entire drive! Burning backup discs may have been a hassle, but using cheap DVD media to free up space on an expensive hard drive made a lot of sense at the time.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/legit.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/legit_thumb.jpg"></a>
<figcaption>Don't mixup backup discs and real discs! Thankfully, our discs are certified.</figcaption>
</figure>
</div>
<p>Unfortunately, playing games on a DVD backup wasn't a great experience. Dolphin wasn't designed to read from slow optical media. Even in 2003 hard drives were leaps and bounds faster than any optical drive, so Dolphin assumes that storage will never be a bottleneck. If for some reason storage <em>is</em> a bottleneck, Dolphin will halt entirely and wait for the storage to catch up. This appears as a stutter to the end user. If a game only read from the disc at explicit loading screens this would not be an issue, but most games do smaller loads at a regular basis throughout play. And some games, like <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime">Metroid Prime</a>, <em>constantly</em> load from the disc during gameplay, introducing persistent stutter that can make playing the game a nightmare.</p>
<p>Another problem is that DiscTracK (DTK) audio games will have problems keeping up with the expected timings. Same for streaming videos, like those found at the start of <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_2:_Echoes">Metroid Prime 2</a>. We were unable to find a disc drive that could keep up, and in games like <a href="https://wiki.dolphin-emu.org/index.php?title=Ikaruga">Ikaruga</a> this can lead to hangs.</p>
<p>With the cost of hard drives now far below the cost of equivalent stacks of DVDs and multi-terabyte mass storage hard drives becoming the norm, the motivation to burn GC/Wii backups to discs has evaporated. In fact, most new computers forgo a DVD drive entirely! The only reason to use DVD backups with Dolphin in the modern era was to preserve the aspect of inserting a game into the system, but when the performance is so lackluster and the feature is confusing, the costs just didn't add up.</p>
<p>In the end, a mixture of poor performance and the fact it was confusing users into thinking Dolphin could boot <em>non</em>backup discs lead to the feature's removal. Does that mean the ability to play DVD backups is gone forever? Maybe not. After the feature was removed, a few diehard users of the feature spoke up on its behalf. In response to that, <a href="https://github.com/dolphin-emu/dolphin/pull/11462#issuecomment-1397990953">a list of improvements needed for the feature to return</a> was written and that's where we stand for now.</p>
<h4 id="50-18171-indexgenerator-fix-off-by-one-in-getremainingindices-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-18171/">5.0-18171 - IndexGenerator: Fix off-by-one in GetRemainingIndices </a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-18171-indexgenerator-fix-off-by-one-in-getremainingindices-by-pokechu22" title="Permanent link">¶</a></h4>
<p>This is a longstanding bug in Dolphin that has gone hidden in almost every game. A <a href="https://dolphin-emu.org/download/dev/8d5299c20b69f524b20a8d9451aaf754b36690cc/">Vertex Loader Cleanup</a> by <strong><a href="https://github.com/degasus">degasus</a></strong> unknowingly introduced an off-by-one error into the vertex loader. Oddly enough, this causes error spam in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> during the <a href="https://www.mariowiki.com/Red_Coin_Field">Red Coin Field secret area</a>.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/redcoinfield.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/redcoinfield_thumb.jpg"></a>
<figcaption>Dolphin veterans are <a href="https://bugs.dolphin-emu.org/issues/6135">all too familiar</a> with this secret stage.</figcaption>
</figure>
</div>
<p>Because nothing was <em>visibly</em> broken, this issue went mostly unnoticed. At least, not until a strange European only racing game arrived on our issue tracker. <a href="https://wiki.dolphin-emu.org/index.php?title=Pocoyo_Racing">Pocoyo Racing</a> is a licensed racing game based off of the kid's show Pocoyo. If you play <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> with tilt controls, you'll be right at home in this simple racing game aimed at children. However, when booting this game in Dolphin, things won't look quite right on the Ocean tracks.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/pocoyo-bugged.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/pocoyo-bugged_thumb.jpg"></a>
<figcaption>The vertex issues provided intangible obstacles that made driving the track slightly more difficult.</figcaption>
</figure>
</div>
<p>Unlike <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a>, the fixes to the Vertex Loader Cleanup back then <em>did not</em> fix this issue, meaning it's remained dormant for <strong>a decade</strong>. However, thanks to a user stumbling upon this weird bug in this weird game, we were able to get a look at the issue manifesting and were able to locate the problem and repair it. Namely, IndexGenerator was broken for large numbers of vertices in one draw call, which is the function that gives a unique number to each unique vertex. Using the visible error in <a href="https://wiki.dolphin-emu.org/index.php?title=Pocoyo_Racing">Pocoyo Racing</a>, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> quickly narrowed down the problem and solved the issue.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/pocoyofixed.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/pocoyofixed_thumb.jpg"></a>
<figcaption>The game finally looks right in the latest Dolphin builds.</figcaption>
</figure>
</div>
<p>This also fixes the error log spam in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> when it renders the grass special stage.</p>
<h4 id="50-17833-fix-normaltangentbinormal-with-index3-set-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17833/">5.0-17833 - Fix normal/tangent/binormal with Index3 Set</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-17833-fix-normaltangentbinormal-with-index3-set-by-pokechu22" title="Permanent link">¶</a></h4>
<p>This is a change that we missed from the last Progress Report, but thought it might be interesting to those that love seeing <em>edge of emulation</em> style of fixes. It was reported the several lighting effects in Quake GX (a homebrew port of Quake Shareware to the Wii) were broken in Dolphin. What made these effects interesting was that they were achieving <strong><a href="https://forum.beyond3d.com/threads/normal-mapping-wii-demo.46425/">normal mapping on the Wii</a></strong>.</p>
<p>Though the glorious bastards at Factor5 <a href="https://dolphin-emu.org/blog/2022/05/17/dolphin-progress-report-february-march-and-april-2022/#50-16301-videocommon-handle-emboss-texgen-with-only-a-single-normal-by-pokechu22">implemented bump mapping</a> without any assistance from the hardware, this homebrew takes it even further by implementing full normal mapping. Dolphin was fully capable of emulating the effects, except it was getting confused by Quake GX having <em>normalindex3</em> enabled in the vertex format. It wasn't actually doing anything <em>with this</em>, so simply disabling normalindex3 would fix the bugs.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/quake-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/quake-broken_thumb.jpg" /></a>
<figcaption> Even though it looks alright at a glance, some of this demo's coolest effects were completely missing.
</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/quake-fixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-december/quake-fixed_thumb.jpg" /></a>
<figcaption>You can see reflections of light on the walls and other normal mapped effects.</a></figcaption>
</figure>
</div>
</div>
<p>However, that wasn't a good enough solution for <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> who dove in to fix the bug correctly. Through hardware testing, they determined the behavior of normal/tangent/binormal with Index 3 being set in order to fix the Vertex Loader to generate these cases correctly.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2022-12-01&to=2023-02-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-17997/">5.0-17997</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-18498/">5.0-18498</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: September, October, and November 2022
2022-12-21T09:43:56+00:002022-12-23T07:43:12.014117+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2022/12/21/dolphin-progress-report-september-october-november-2022/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/progressreportheader-octo2022.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/progressreportheader-octo2022mini.jpg" />
</header>
<p>As we hit the holiday season, our Progress Report <em>might</em> be considered a bit late. A two month report became a three month report as we realized just how much work we had to catch up on. While the usual <em>summer</em> burst of activity didn't come, it seems instead everyone poured their time in throughout the autumn months! There's so many features, performance improvements, quality of life updates, and more that had to be considered.</p>
<p>We're going to have to skip out on some of the smaller updates this time around because there are so many big hitters. For instance, if you hate shader stuttering, Dolphin's <a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">Ubershaders</a> have gotten a new tool that helps smooth out issues on Vulkan, D3D12, and Metal thanks to Dynamic Vertex Loaders that help reduce/remove pipeline compiles during gameplay.</p>
<p>If you're on a weaker device that stays away from Ubershaders... maybe after these optimizations you might finally be able to make the leap. Raw performance in Dolphin is up across the board thanks to many optimizations to the GPU emulation thread (which is emulated on CPU). Because this optimization affects the very core of Dolphin, pretty much every game should be faster, with a few select games seeing improvements of <em>roughly 50%</em>!</p>
<p>If you're looking to play with friends, we have some good news on that front as well. Dolphin's "experimental" Wii Remote Netplay support has finally received some much needed attention that may help it break free of that experimental moniker in the coming months. </p>
<p>And, for our Android users, a lot of the performance improvements also affect tablets and phones, but we also have a special treat <em>only</em> for you. The Android GUI has also seen a huge overhaul that should make it easier to use and easier on the eyes. And for those having problems with particular games using features Dolphin <em>can't</em> reasonably emulate, we have a few presents from an old friend to patch them up.</p>
<p>We could go on and on, but you know what time it is. Please enjoy these Notable Changes!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-17613-implement-missing-features-for-wiiconnect24-support-by-noahpistilli"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17613/">5.0-17613 - Implement Missing Features for WiiConnect24 Support</a></strong> by <strong><a href="https://github.com/noahpistilli">noahpistilli</a></strong><a class="headerlink" href="#50-17613-implement-missing-features-for-wiiconnect24-support-by-noahpistilli" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:180px; float:right; text-align:center;">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiconnect24logo.png">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiconnect24logobig.png">
</a></div>
<p>And after all of the changes and features we mentioned in the intro, we neglected to mention our headline change for this report. It's almost fitting - WiiConnect24 came and went without leaving much of a mark in the gaming world. It was touted as a new way to be connected to the internet 24/7, with access to up to date information from the comfort of your couch. You could see the weather, the latest news, receive messages (with pictures!) and more through the WiiConnect24 service. Even if your console wasn't on, the disc tray would glow blue if you have a new message, a Wii Update, or something else awaiting you for the next time you booted things up.</p>
<p>By 2013, the unending march of technology had already consumed much of the usefulness of the service, and everyone expected it to slowly fade away. But to our surprise, on 13 April 2013 Nintendo announced the closure of WiiConnect24 in <em>late June</em>, only 44 days away. At the time <a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Network_Guide">Nintendo Wii Wi-Fi Connectivity Support</a> was in its infancy. Our mastery of NAND and IOS features was simply not good enough to support WiiConnect24, and many of its channels didn't even run in Dolphin at the time. When WiiConnect24 disappeared, we were years away from being able to support it. As much as it pained us, we were unable assist in the efforts to preserve WiiConnect24.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/nintendochannel.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/nintendochannel_thumb.jpg"></a>
<figcaption>The sudden passing of WiiConnect24 put its many supported channels, promotional demos, cheesy videos and advertisements at risk of disappearing forever.</figcaption>
</figure>
</div>
<p>However, there was another option for testing and preserving WiiConnect24 - the actual Wii. From the <a href="https://rc24.xyz/about.html">early days after WiiConnect24</a>'s closure, preservationists and reverse engineers have been chipping away at reviving many of the channels and features seemingly lost. For international/default channels, <a href="https://rc24.xyz/">RiiConnect24</a> offers good support across a lot of channels. For players looking for some Japanese exclusive channels, <a href="https://www.wiilink24.com/">WiiLink</a> has been slowly building support for these obscure channels that offer up some neat experiences that never saw the light outside of Japan.</p>
<p>Some efforts have been made by the <a href="https://rc24.xyz/">RiiConnect24</a> developers to bring their service to Dolphin, but these have been a bit hacky. They have workarounds to get <em>certain</em> channels working within Dolphin, though it required a lot of setup in order to prepare VFFs (Virtual FAT Filesystems) that the channels used to store WiiConnect24 data. It was not user friendly, as it was difficult to set up, had limited functionality, and could easily break at any time.</p>
<p><strong><a href="https://github.com/noahpistilli">Sketch</a></strong>, <a href="https://www.wiilink24.com/">WiiLink</a> project lead and <a href="https://rc24.xyz/">RiiConnect24</a> contributor, realized that direct support in Dolphin would be a boon to both projects. It would open up their replacement services to more users and also make it easier to debug issues. But of course, it was easier imagined than executed. Sketch identified three major challenges that blocked WiiConnect24 emulation: support for VFF files, implementing some of the missing IOS functions, and figuring out the many fields of nwc24dl.bin and what they do.</p>
<p>Figuring out nwc24dl.bin was a reverse engineering job. We mentioned that WiiConnect24 titles could download updates <em>while</em> the Wii was in standby mode. How often it checked among other important things is stored in nwc24dl.bin. Emulating the standby feature is <em>thankfully</em> unnecessary, as WiiConnect24 channels also check for updates while the actual Wii is running and when you load them. Because Dolphin doesn't support the Wii's background scheduler, the only check it could possibly support is on channel boot.</p>
<p>Once the many fields of nwc24dl.bin were reverse engineered and understood so it could be HLE'd, the next thing that needed to be handled was actually downloading the data needed for these channels. To do this, an IOS function called <code>DownloadNowEX</code> needed to be supported. This is a download handler that can download anywhere from 1 to 32 files. If it is downloading more than one file in a single task, these files are called "subtasks" and there is a flag set in memory saying this download is a subtask and how many files it needs to download. Many of the channels take advantage of the subtask functionality, and the News Channel will download 24 subtask files when it updates!</p>
<p>These files that are downloaded now need to be packed into VFF files for use by the channels. Thankfully, Dolphin already has to handle the FAT filesystem thanks to SD cards and whatnot, so <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> could get a jump start on support by copying code from there. But this wasn't an easy task, and actually supporting the VFF files required a little bit of finessing. The headers on the files were mostly undocumented and needed some digging into. However, once that was taken care of, <strong><a href="https://github.com/noahpistilli">Sketch</a></strong> streamlined the solution with <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong>'s help.</p>
<p>With these changes, WiiConnect24 channels like the <a href="https://wiki.dolphin-emu.org/index.php?title=News_Channel">News Channel</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Forecast_Channel#Emulation_Information">Forecast Channel</a>, and others can resume service in Dolphin! </p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/everybodyvotes.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/everybodyvotes_thumb.png"></a>
<figcaption>WiiConnect24 is working in Dolphin at long last!</figcaption>
</figure>
</div>
<p>Is the situation perfect? Absolutely not. Like we said, Dolphin doesn't support background updates, so on their very first boot most of these channels will error out. After that they should work normally as long as the NAND stays intact. The other thing to note is that Dolphin currently doesn't have a way to redirect WiiConnect24 requests. That means users will need to patch the channels to seek out the third party servers.</p>
<p>If you're into weird era specific features, connecting to these services is absolutely worth the time. Just to give you a taste of what you can find, here is a clip from <a href="https://en.wikipedia.org/wiki/Nintendo_Channel#Nintendo_Channel">Nintendo Week</a> 7 Dec 2009, captured from Dolphin using RiiConnect24.</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/NintendoWeekClip.mp4" type="video/mp4"/>
</video></div>
<figcaption></figcaption>
</figure>
</div>
<p>If you want to see more great videos like this, patch your Nintendo Channel today and check out the Nintendo Channel on <a href="https://rc24.xyz/">RiiConnect24</a> with either your Wii or the latest builds of Dolphin!</p>
<hr />
<p><strong>Note:</strong> <a href="https://rc24.xyz/">RiiConnect24</a> and <a href="https://www.wiilink24.com/">WiiLink</a> are third party services much like <a href="https://wiimmfi.de/">Wiimmfi</a>. You should make sure that you trust any third party service before connecting to it via <em>any</em> emulator. However, both <a href="https://github.com/RiiConnect24">RiiConnect</a> and <a href="https://github.com/WiiLink24">WiiLink</a> are open source, and were tested by developers during the development/testing of WiiConnect24 changes.</p>
<hr />
<h4 id="50-17527-netplay-redesign-wii-remote-data-exchange-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17527/">5.0-17527 - Netplay: Redesign Wii Remote Data Exchange</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-17527-netplay-redesign-wii-remote-data-exchange-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>As we said in the intro, Wii Remote Netplay has been a frustrating, yet tantalizing, feature since its inception. The Wii has a <em>ton</em> of multiplayer games that either didn't support Wi-Fi, or had substandard Wi-Fi support leading to couch multiplayer being the superior choice. Dolphin has netplay that lets you take couch multiplayer online. Everyone wins, right? There's one problem: Wii Remotes.</p>
<p>Using Wii Remote Netplay is a test of frustration for all but the most hardened of users. A ton of pitfalls awaited anyone who dared try to use it.</p>
<ul>
<li>Wii Remote Netplay did not support automatic port assignment, which was completely the opposite of GameCube Controller Netplay. This meant each player had to configure the actual Wii Remote slot's profile to match what slot they were assigned to on netplay. <a href="https://wiki.dolphin-emu.org/index.php?title=Netplay_Guide">To see how automatic port assignment works in Netplay now, please check out the netplay guide.</a></li>
<li>Wii Remote Netplay would crash on close due a previously undetermined bug with <em>Safe Shutdown</em> on netplay. Some Wii games flush saves during "Safe Shutdown" so we couldn't just outright disable this feature on netplay.</li>
<li>Wii Netplay has to export saves at the end of a Netplay Session if a user wants to permanently save them. But, because Wii Remotes would usually cause Wii Netplay to crash during safe shutdown, this meant that saves would get lost in limbo. While it was technically possible to restore them, it required expert knowledge and manual reconstruction of the NAND.</li>
<li>If a Wii Remote disconnected during a netplay session, for any reason, Dolphin would crash. This is despite there being code designed to handle this exact situation. Unfortunately, this meant that games like Donkey Kong Country Returns and Dokapon Kingdom couldn't be played on netplay, as these games will disconnect various Wii Remotes during the menus.</li>
<li>The <em>Real Wii Remote</em> setting will never work on Netplay. This is less of a problem nowadays thanks to the innovation of <a href="https://dolphin-emu.org/blog/2020/04/05/dolphin-progress-report-february-2020/#50-11684-add-support-for-wii-remotes-over-inputcommon-by-billiard">connecting physical Wii Remotes as emulated controllers</a> and the "Wii Remote" controller profile. Some problems solve themselves.</li>
</ul>
<p>These limitations and a confusing UI for setting up Wii Remotes on netplay meant that only extremely well researched users could actually use it. In order to fix all of these problems, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> decided to rethink how Dolphin would communicate Wii Remotes over netplay.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/DKCR-Netplay.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/DKCR-Netplay_thumb.jpg"></a>
<figcaption>Donkey Kong Country Returns struggled with netplay because it disconnected Wii Remotes.</figcaption>
</figure>
</div>
<p>If it wasn't obvious by the list of problems, Dolphin's netplay was not designed for the complexity of the Wii Remote. Still, it was implemented because we figured <em>someone</em> would want to use it, even if it was a pain in the ass to setup and use. Unfortunately, it was hard to recommend to anyone but the most desperate of players because of all the hoops you had to jump to get there.</p>
<p>The <a href="https://dolphin-emu.org/download/dev/master/4.0-17/">initial implementation</a> from <a href="https://github.com/RachelBryk">RachelBryk</a> was an experimental solution to enable functionality. It was meant more for experimentation and testing than general users, but once they saw it <em>could</em> work, users obviously wanted to use it. It was hard to provide help for the feature because it was so temperamental that most developers couldn't tell what was wrong. It got to the point where Wii Remote Netplay was one of the few features <a href="https://github.com/dolphin-emu/dolphin/pull/3691">outright removed</a> for the Dolphin 5.0 release in order to prevent users from thinking it was a fully working stable feature.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-40-8032.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-40-8032_thumb.png" /></a>
<figcaption>Experimental Wii Remote Netplay was available throughout most of the 4.0 era.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-40-9050.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-40-9050_thumb.png" /></a>
<figcaption>However it was removed before 5.0, and <a href="https://dolphin-emu.org/blog/2016/08/02/dolphin-progress-report-june-july-2016/#50-133-50-136-50-222-50-290-restore-and-repair-wiimote-netplay-by-mimimi-and-jmc47">restored after the release.</a></figcaption>
</figure>
</div>
</div>
<p>Dolphin's Netplay has evolved over the years. The advent of the desync checker revolutionized netplay, and allowed users to immediately know if something was wrong on boot. Other features, like the <a href="https://dolphin-emu.org/blog/2015/07/01/dolphin-progress-report-june-2015/#netplay-infrastructure-updates-40-6512-wii-blank-nand-on-netplay-by-comex-40-6638-netplay-desync-detection-by-rachelb-40-6839-synchronize-gamecube-sram-settings-file-on-netplay-by-admiralcurtiss">"Blank NAND"</a> further stabilized Wii Netplay in general. Wii Netplay was on the rise, but one problem remained constant: The Wii Remote.</p>
<p>The problem with fixing this is that the Wii Remotes are so complicated to handle. They communicate over Bluetooth at a high polling rate of 200hz, have their own logic for attachments, come equipped with accelerometers and (optionally) a gyroscope, carry a speaker which can play 8-bit PCM audio, and even come with an infrared camera with a resolution of 128x96. While Dolphin doesn't enable it on netplay, Wii Remotes even have a small bit of EEPROM for storing Miis on them! Wii Remotes are weird. But worse of all, the Wii Remote's reporting mode can change at any time, and the sessions have to be <strong>perfectly</strong> synced in order to prevent a deadlock from the wrong inputs being received on one or more Wii instances.</p>
<hr />
<p>Sometimes in order to make things work, you need to start fresh. In order to start the healing, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> did the most logical thing and immediately threw out most of the existing Wii Remote handling code used for Netplay. At this point, we knew the problems with Wii Remote Netplay and could now try again to write a solution that avoided these issues.</p>
<p>The big one is that when a Wii Remote talks to the Wii, it does this with <em>input reports</em> - small chunks of data sent over the Bluetooth connection that contain a partial Wii Remote state. These reports are what was sent over the network during Wii Remote Netplay. The problem comes that the game can configure at any time what kind of report it wants the Wii Remote to send. This means if there's any kind of problem on netplay on any of the clients and the reports don't match what the game is expecting, Dolphin would lock-up. In the best case, netplay would close but usually the entire emulator would crash.</p>
<p>Because of how sensitive this is, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> decided to take a different route. Instead of sending <em>just</em> what the game is requesting, all players will send <em>all</em> of the Wii Remote state across netplay and let each Dolphin instance translate those into an input report. This makes Wii Remote netplay more resilient to crashes over minor configuration problems and also opens up a ton of new features. Since we're no longer relying on each Dolphin instance to sort out the Wii Remote state, players on netplay can now do things like <em>change attachments</em> during netplay and it can handle events where the game might forcibly disconnect a Wii Remote.</p>
<p><strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> also standardized Wii Remotes to use the same conventions as GameCube netplay. This means Dolphin's automatic port assignment now works the same across all controller types. Best of all, Dolphin <em>no longer crashes when you attempt to end a Wii Remote Netplay session</em>.</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-current.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/wiiremotenetplay-current.png"></a>
<figcaption>Wii Remotes have seen some renovations and should be just as easy to setup as GameCube Controllers for netplay.</figcaption>
</figure>
</div>
<p>That's not to say everything is perfect. <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> mostly focused on getting things working with this rewrite, but there are still some missing features. "Golf Mode" and "Host Input Authority" should be able to work under the new implementation, but weren't done alongside the first wave of changes. As well, SD cards <em>are not</em> synced on netplay, so it's usually best to unplug them <em>or</em> make sure they are manually synced between players if SD cards are absolutely necessary.</p>
<p>With these changes, we're hoping that Wii Remote Netplay will <em>finally</em> be a feature that our general users can setup and enjoy.</p>
<h4 id="50-17681-vulkan-use-vma-for-memory-allocations-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17681/">5.0-17681 - Vulkan: Use VMA for memory allocations</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-17681-vulkan-use-vma-for-memory-allocations-by-k0bin" title="Permanent link">¶</a></h4>
<p>We're going to be talking <em>a lot</em> about Vulkan coming up as there were some renovations done throughout the backend. A consequence of these renovations is that Dolphin now uses <a href="https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator">Vulkan Memory Allocator</a> (used by many open source projects to efficiently allocate memory, including other emulators) to handle memory management with Vulkan.</p>
<p>This is a definite improvement, but it didn't exactly fix anything. The problem was that other changes to the Vulkan backend left us with some instability problems and we thought that <a href="https://github.com/GPUOpen-LibrariesAndSDKs/VulkanMemoryAllocator">Vulkan Memory Allocator</a> would fix the issue and most likely improve performance. It didn't fix the issue and didn't have an <em>immediate</em> impact on performance, but it still optimizes how we're handling memory in Vulkan. VMA is a definite improvement and we're happy to join the ranks of projects using the library.</p>
<h4 id="50-17499-vulkan-raise-number-of-command-buffers-and-50-17620-vulkan-allocate-descriptor-pools-as-needed-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17499/">5.0-17499 - Vulkan: Raise number of command buffers</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17620/">5.0-17620 - Vulkan: Allocate descriptor pools as needed</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-17499-vulkan-raise-number-of-command-buffers-and-50-17620-vulkan-allocate-descriptor-pools-as-needed-by-k0bin" title="Permanent link">¶</a></h4>
<p>Now we're going to get into why VMA was thought to be needed. Namely, Dolphin's usage of Vulkan was pretty primitive in some ways. The emulator was only using <em>two</em> command buffers and a single descriptor pool of 100,000 descriptor sets every frame. These choices weren't exactly efficient, but they weren't exactly causing problems either. Except on Android.</p>
<p>Our eternal battle with GPU drivers on Android has an ebb and flow. While we love to blame the drivers for their problems, there's always the otherside of things where Dolphin does something stupid. This time, we were the ones being grossly inefficient.</p>
<p><strong><a href="https://github.com/K0bin">K0bin</a></strong> found out that Adreno GPUs were forced to stall when running Dolphin because they were waiting on an available command buffer, particularly in games that need readbacks (EFB/XFB2RAM titles.) By increasing the number of command buffers to eight, <strong><a href="https://github.com/K0bin">K0bin</a></strong> reduced GPU stalling and made it so the mobile GPUs could work more efficiently. This doesn't mean your maximum performance at 1x Internal Resolution will go up, but this might mean you'll be able to play at a higher internal resolution before you become GPU limited!</p>
<p>This is a <em>major</em> optimization and we wanted to show some fancy graphs showing how much better things were running. Unfortunately, Android said no. Even though we reduced GPU usage by <em>up to 30%</em>, due to performance governors on the phone clocking things down, we were unable to see a difference in framerate on our devices. While <em>sometimes</em> the CPU would clock up, the numbers varied so greatly even within the same build, that we no longer feel confident in giving performance numbers on Android.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidcharts.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidcharts_thumb.jpg"></a>
<figcaption>"You need this? No, I don't think you need this."</figcaption>
</figure>
</div>
<p>The good news? This brings Vulkan's performance roughly in line with OpenGL on Android under Adreno devices. While we can't guarantee the drivers play nice in every game because performance testing has been a nightmare, we were able to confirm this fixes NES VC games being abnormally slow on Vulkan + Adreno.</p>
<hr />
<p>Unfortunately, this optimization had some unintended effects that reverberated through the Vulkan backend, especially for our macOS users through MoltenVK. Players were reporting new and exciting crashes throughout tons of games, forcing <strong><a href="https://github.com/K0bin">K0bin</a></strong> into figuring out what was going wrong. </p>
<p>Thankfully, the issue became apparent relatively fast. The new code wasn't <em>wrong</em> but other parts of the backend relied on how things worked before. Previously, if Dolphin ran out of descriptors, it would submit a command buffer expecting that to get it a fresh descriptor pool. With the new changes, submitting a command buffer would no longer get a fresh pool, and Dolphin would find itself still out of descriptors, at which point it would skip the draw.</p>
<p>In order to prevent the crashes, graphical issues, and <em>further</em> reduce memory overhead, <strong><a href="https://github.com/K0bin">K0bin</a></strong> changed Dolphin to now allocate descriptor pools as needed. This <em>technically</em> could positively affect performance, but we weren't able to measure any difference in practice.</p>
<h4 id="50-17357-optimize-getvertexsize-and-50-17370-cache-vertex-sizes-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17357/">5.0-17357 - Optimize GetVertexSize</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17370/">5.0-17370 - Cache Vertex Sizes</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-17357-optimize-getvertexsize-and-50-17370-cache-vertex-sizes-by-k0bin" title="Permanent link">¶</a></h4>
<p>New hardware always brings new opportunities. But that new hardware <em>doesn't</em> need to be something that pushes the boundaries of performance. In fact, one of the most exciting new devices this year is made up of decent, but unremarkable hardware in an interesting form factor. Of course, we're talking about the Steam Deck. This is an exciting target for Dolphin because it's got a respectable CPU and <em>real</em> GPU drivers paired with a mobile gaming form factor. In theory, it should be great for Dolphin.</p>
<p>However, early days of testing has been a somewhat rocky experience. Using Dolphin's desktop GUI on the Steam Deck isn't fun and takes a lot longer than you would like. Setting up controls is frustrating and actually getting Dolphin to compile on the Steam Deck is a nightmare unless you're fairly well versed in "Linux-fu". Thankfully, there is an easily accessible flatpak version (not maintained by Dolphin Emulator Staff) that keeps up with our beta builds, but it has a few problems not present when you compile yourself.</p>
<p>Thankfully, the situation improves a lot <em>once</em> you get past the setup stage. Light-to-midweight games run very well, and if you need a bit more juice you can always lock the GPU at a higher clockrate in exchange for lower battery life. But the hardware was <em>just</em> missing full speed on some mainstream titles. One game in particular was <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a>, which hovered around 80 to 90% speed in several strenuous areas.</p>
<p>A slight optimization wouldn't be enough to make one of the Wii's premiere 3D platformers fullspeed on the Steam Deck, but it was close enough to at least give it a shot. Having observed the performance problems first hand, <strong><a href="https://github.com/K0bin">K0bin</a></strong> downclocked their desktop and decided to profile things there. While a 20% jump in performance was <em>a lot</em> to ask for, they figured they could look for some low-hanging fruit and at least bring it closer.</p>
<p>Things took a twist when they discovered that the function GetVertexSize was using <strong>a lot</strong> of CPU time on the GPU emulation thread. This function should only need to come up once per vertex format and isn't anything that you'd expect to see in a flame graph. Surely there was a reason, right? Well, they started optimizing it and immediately got positive results. In fact, just optimizing this alone was able to push performance up on a downclocked R9 5900 roughly 30%! That's a huge jump, and one that had to be seen to be believed. </p>
<p>Testing it on the Steam Deck didn't provide as huge of a jump everywhere, but it was just enough to push it to nearly full speed in most demanding areas. But then the question became how we missed such an obvious problem.</p>
<p><code>git blame</code> revealed that this is a performance regression from just under 2 years ago during the fifoplayer quality of life updates. We didn't notice the performance regression because other optimizations were masking it, but an erroneous duplicate GetVertexSize was added which was causing it to be called for <strong>every single primitive.</strong> Suddenly something that should only take a little CPU time was taking a lot.</p>
<p>Finding this issue inspired <strong><a href="https://github.com/K0bin">K0bin</a></strong> to continue to optimize that part of the code. They discovered that we could also use the cached VertexSize instead of having use GetVertexSize again in some cases. This gave another jolt to performance.</p>
<p><br/>
<script>
addChart({"title":{"text":"Optimized GetVertexSize with Regression Fix"},"subtitle":{"text":"Super Mario Galaxy Hub | Simulated Steam Deck (AMD R9 5900 @ 2.2ghz)"},"exporting":{},"chart":{"type":"column","inverted":true,"polar":false,"height":550},"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"series":[{"name":"FPS","turboThreshold":0,"marker":{}}],"data":{"csv":"\"null\";\"FPS\"\n\"Before\";85\n\"Regression Fix\";112\n\"+ Optimization\";140","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"labels":{"format":"{value}FPS","enabled":true},"tickLength":10,"tickInterval":30,"minorTickInterval":10},"pane":{"background":[]},"responsive":{"rules":[]},"xAxis":{"labels":{"enabled":true}},"legend":{"enabled":false},"colors":["#006eff","#434348","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"]})
</script>
<br/></p>
<p>The fix plus the optimization put together more than did the trick. We tested the Steam Deck after <em>painfully</em> compiling a build with the optimizations and played through a good bit of <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> (and a little of <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a>) at full speed and 2x Internal Resolution without any noticeable slowdown. In fact, you can even throw on Hybrid Ubershaders and get a pretty smooth experience on par with a mid-range desktop!</p>
<hr />
<p>So, at this point you're probably wondering if this optimization carries over into other games. After all, pretty much every game is going to be using primitives, right? </p>
<p>The answer is yes, but the numbers aren't <em>usually</em> this ridiculous. On high-end gaming PCs using Dolphin's default settings, the Super Mario Galaxy games saw an improvement of around 30% when running at 4x Internal Resolution. High polygon games that lack other bottlenecks will improve similarly, but games that have different performance profiles may not see as big of a benefit. If a game is <em>really</em> difficult to run with tons of different bottlenecks, they will see very little gain. <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron 3</a> gains less than ~1.5% performance in most areas.</p>
<p>Most <em>normal</em> games will see an increase in performance ranging from around 5% to 10%, with some anomalies like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> seeing larger gains.</p>
<h4 id="50-17542-update-efb-peek-cache-on-draw-done-and-tokens-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17542/">5.0-17542 - Update EFB Peek Cache on Draw Done and Tokens</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-17542-update-efb-peek-cache-on-draw-done-and-tokens-by-k0bin" title="Permanent link">¶</a></h4>
<p>The other major bottleneck in the <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> games comes from their use of <strong>EFB Peeks</strong>. In essence, an EFB Peek is when the GameCube/Wii CPU reads pixels of the Embedded FrameBuffer (EFB). By <em>peeking</em> into it the game can learn information about one or more pixels, such as their depth, color, etc. </p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy 1</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">2</a> use EFB Peeks for two things, and only one of them is necessary for gameplay. The first thing is a depth check for pixels on screen. This is how the game is able to tell where your cursor is in relation to 3D space. It's used to tell where to shoot starbits and can be used to see if you're trying to grab objects like Pull Stars.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxy-pullstars.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxy-pullstars_thumb.jpg"></a>
<figcaption>Pull Stars are essential to proceed throughout the game, much to the chagrin of many Android users.</figcaption>
</figure>
</div>
<p>The other use <em>doesn't</em> affect gameplay but can hurt performance just as much. This check is only active while a "sun" is on screen. Even when the sun is within the field of view of the camera, that doesn't mean it's actually visible. There might be a wall, planet, ground, or something else occluding (blocking) the view. That's where EFB Peeks come in - the game uses EFB peeks whenever a sun is in front of the camera to make sure it is actually visible! This is why many users complain of slowdown on weak devices <em>only</em> when a sun is on screen!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxyflare-on.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxyflare-on_thumb.jpg" /></a>
<figcaption>Galaxy uses EFB Peeks to look at the screen coordinates where the sun should be.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxyflare-off.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/galaxyflare-off_thumb.jpg" /></a>
<figcaption>If the EFB Peek cannot "see" the sun, the game will not render the sunflare. In this demonstration we disabled EFB Peeks to force it to fail.</figcaption>
</figure>
</div>
</div>
<p>This technique is an easy and effectively free way to sample the screen for occlusion on the GameCube and Wii. Tons of games use this technique (or a variation on it) for rendering lens flares only when the source light is visible. For example, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a> does the same check but with inverted conditions - it isn't checking if the sun is visible but if it is blocked. However, not every developer got the memo on this simple lesson. See <a href="https://wiki.dolphin-emu.org/index.php?title=Rune_Factory:_Tides_of_Destiny">Rune Factory: Tides of Destiny</a>.</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/runefactoryflare.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/runefactoryflare_thumb.jpg"></a>
<figcaption>If only they had used EFB Peeks.</figcaption>
</figure>
</div>
<p>While this technique is more-or-less free on the GameCube, it is an absolute pain to emulate. We've covered something similar in the previous Progress Report so this explanation will be a little familiar.</p>
<p>The GameCube and Wii use a unified memory model, where the CPU and GPU can read or edit eachother's memory at any point with no performance cost. However, Dolphin runs on split memory model systems where the CPU and GPU cannot access eachother's memory easily. To emulate the unified memory model, Dolphin duplicates the GC/Wii Main Memory on both the host's system memory and the host's GPU vram, and we sync any changes across both memory pools. Any time a sync is issued, we have to stop all work until the sync is complete, so the host hardware will just sit and wait while the data is moving through the system. At the speed computers operate, moving data from system RAM to GPU VRAM takes <strong>ages</strong>, so all that waiting causes a sizable performance hit.</p>
<p>Specifically with EFB Peeks, we have to stall the GPU and synchronize the memory pools so the CPU can read the rendered frame.</p>
<p>Fortunately, desktop GPU drivers have many optimizations to minimize the impact of stalls, and modern desktops are so powerful they can usually just eat the performance hit while keeping emulation far above full speed. The only time that EFB Peeks become a problem for Dolphin is in <em>very</em> extreme cases where they are combined with other shenanigans (EFB Pokes, Store EFB Copies to Texture and RAM, etc.) <em>or</em> weaker hardware with iffy drivers and stingy governors.</p>
<p><br/>
Enter Android.</p>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:8%; min-width:120px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png"></div>
<p><br/></p>
<p>Whether you're on Adreno, Mali, or PowerVR, a game using EFB Peeks, Pokes, or one that requires the use of Store EFB/XFB Copies to RAM usually spells doom for performance. In the mobile landscape, everything is optimized to save power. But mobile SoCs do not understand Dolphin's weird workload. If a game triggers a memory pool sync, we have to stall the GPU while data is moving around. Mobile power governors see us stalling and think we are done with work, and immediately drop the clocks back to idle. But a few microseconds later we're back to needing maximum power. Unfortunately, the SoC will take its time and <em>reluctantly</em> raise clocks back up. <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a> will be doing many of these checks <em>every frame</em>. Unless your phone is absurdly powerful or your performance governor is extra forgiving, it's very hard to maintain to maintain full speed with all of this going on. Many of our mobile players have been working around this by only enabling EFB Peeks in stages that <em>absolutely need them</em>.</p>
<p>There is no way to make stalls cheap, and power governors are mostly out of our control, so the challenge becomes bundling and reducing the number of required readbacks as much as possible. This optimization by <strong><a href="https://github.com/K0bin">K0bin</a></strong> helps us get a little more mileage out of our last GPU sync/stall. <em>Instead</em> of just invalidating the EFB Peek cache, on tokens and drawdone, we can queue an update to all previously used EFB tiles. If the game only does work on the CPU between the DrawDone or Token and the actual EFB read, the read is able to hit the prepopulated cache and no longer needs to stall the GPU for another readback. This reduces the number of readbacks in many situations.</p>
<p>With this change, EFB Peeks are significantly less costly. In our testing, a Snapdragon 865 was able to run many stages of <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> at 60 FPS <em>without</em> disabling "Skip EFB Access to CPU", including ones with Pull Stars that would need the performance the most.</p>
<p>Is this a catch all to improve performance across all games? Unfortunately, not really. EFB Peeks are pretty much the <em>best</em> case scenario of readbacks, and this change further cements this. Other games like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> uses Peeks, Pokes, PerfQueries, Store EFB Copies to RAM, and more. Even though this game only runs at 30 FPS (unless you choose to use a 60 FPS mod), the fact it uses so many difficult to emulate features turns it into a performance nightmare on Android.</p>
<p>This optimization has been merged into the setting <em>Defer EFB Cache Invalidation</em>, which is enabled automatically for the Super Mario Galaxy games. Because these cached results <em>could</em> break things in other games, we haven't enabled this optimization everywhere. You can test this change out in other games by enabling it under Graphics Settings > Advanced > Defer EFB Cache Invalidation.</p>
<h4 id="50-17762-d3d12-fix-numerous-hangs-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17762/">5.0-17762 - D3D12: Fix Numerous hangs</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-17762-d3d12-fix-numerous-hangs-by-k0bin" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:180px; float:right; text-align:center;">
<a href="https://dolphin-emu.org/m/user/blog/videocommon/d3d12logo.jpg">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/videocommon/d3d12logo_thumb.jpg">
</a></div>
<p>D3D12 is usually considered Dolphin's most performant backend for integrated and low-end graphics cards on Windows. Unfortunately it's also gotten another reputation among people with stronger computers: the most unstable backend. In fact, there have been dozens of reports of crashing in games specifically when using D3D12, forcing users to switch to other backends.</p>
<p>Things went from bad to worse when unrelated optimizations in <a href="https://dolphin-emu.org/download/dev/master/5.0-17542/">5.0-17542</a> caused <em>more</em> games to start crashing in D3D12. So <strong><a href="https://github.com/K0bin">K0bin</a></strong> was enlisted to figure out why this optimization that improved <em>all</em> backends would only cause problems in D3D12.</p>
<p>After fixing up D3D12's validation layers, which hadn't been touched in a while, <strong><a href="https://github.com/K0bin">K0bin</a></strong> quickly found out there was a slight issue with <code>BindFramebuffer</code> in the D3D12 backend. It seemed <em>very</em> possible for it to rely on a pipeline configuration that hasn't been set. While we had seen a lot of reports of crashes in D3D12, we were never able to figure out an exact cause because of how particular it was to trigger it. You needed specific games, running under specific settings, using a specific GPU and sometimes even a specific driver version. </p>
<p>Ironically, by accidentally making the problem occur more often, <strong><a href="https://github.com/K0bin">K0bin</a></strong> made it much easier to track down and fix. All that was needed was a small change to prevent Dolphin from relying on unset pipeline configurations. This fixed both the <em>new</em> crashes on D3D12, and the previously unsolved crashes that had been plaguing it for years.</p>
<p>We're happy to report that D3D12's stability should finally be on par with the other backends now.</p>
<h4 id="50-17403-add-dynamic-vertex-loaders-for-ubershaders-by-tellowkrinkle"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17403/">5.0-17403 - Add Dynamic Vertex Loaders for Ubershaders</a></strong> by <strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong><a class="headerlink" href="#50-17403-add-dynamic-vertex-loaders-for-ubershaders-by-tellowkrinkle" title="Permanent link">¶</a></h4>
<p>The last couple of changes have been about achieving maximum performance, but now we go into a <em>different</em> kind of performance. As mentioned in the last Progress Report, <strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong> has been working toward smoothing things out with Ubershaders. Due to various issues across various drivers, Ubershaders haven't been able to <em>completely</em> remove stuttering, especially in the modern Graphics APIs.</p>
<p>The <a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">original Ubershaders</a> were created back when D3D12 and Vulkan were the "next-gen" video backends and most of our users were on D3D11 and OpenGL. We were aware that the new APIs used "pipelines" but it wasn't 100% clear the effect they would have on Dolphin yet. For <a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">Ubershaders</a>, it's been a problem, to say the least. <a href="https://dolphin-emu.org/blog/2022/09/13/dolphin-progress-report-july-and-august-2022/#50-16930-reduce-pipeline-compilation-stutter-through-forcing-fbfetch-in-ubershaders-by-tellowkrinkle">We talked about these a bit in the last Progress Report</a> where <strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong> already had one change dedicated toward reducing pipeline counts.</p>
<p>For a quick rundown, the graphics pipeline is a fundamental building block for rendering on newer graphics APIs. It contain all of the data for a draw, taking vertices and textures all the way to the pixels in the render targets. However, since the pipeline contains all the settings for the draw, the display driver can optimize it before feeding it to the GPU. Some drivers then optimize those pipelines by combining the hardware vertex loader settings into the actual shader, which essentially makes our Ubershaders not so Uber anymore. So when the vertex loader on the GameCube changes settings, a whole new shader would need to be compiled with new vertex loader settings, usually resulting in a lengthy stutter.</p>
<p>We did run into this issue with Vulkan when Ubershaders were first implemented, but we were hopeful that API extensions or driver updates would eventually lessen or erase the issue. That hasn't happened.</p>
<p><strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong>'s solution isn't to make pipeline generation faster, but to simplify our pipelines so there are fewer branches and thus fewer pipelines in total. <strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong> was able to reduce our pipeline count so much that now <em>nearly every pipeline</em> is able to be precompiled at boot! And while these changes aren't able to remove the possibility of shader stuttering on <em>every</em> backend on <em>every</em> graphics card, it brings us much closer to that reality. </p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/ubershaders-before.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/ubershaders-before_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Ubershaders weren't fixing the problem on Metal before these changes.</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/ubershaders-after.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/ubershaders-after_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>In newer builds, Ubershaders work as advertised by simplifying things for pipelines.</figcaption>
</figure>
</div>
<p>The Vertex Loader Ubershader, along with some changes leading up to it make a huge difference in shader compilation stuttering on all hardware.</p>
<ul>
<li><strong>Metal</strong>: macOS users can rejoice, as there are now no known drivers that will suffer from shader generation issues when using Ubershaders.</li>
<li><strong>D3D12</strong>: On NVIDIA and AMD graphics cards, using D3D12 should now provide the same stutter free experience as D3D11 has when using Ubershaders. Intel's drivers were not tested, but are likely greatly improved or completely stutter free.</li>
<li><strong>Vulkan</strong>: This is the most complicated case. On macOS via MoltenVK, shader compilation stuttering is completely eliminated <em>except</em> on Apple Silicon, where there may still be rare pipeline compiles. On Windows and Linux, the situation is improved but NVIDIA still tends to have a few noticeable compiles here and there. Wider support of the <code>VK_EXT_rasterization_order_attachment_access</code> extension would help eliminate pipeline compiles across pretty much every driver. That includes mobile drivers too, such as Adreno and Mali!</li>
<li><strong>D3D11</strong>: D3D11 does not have pipelines and doesn't benefit from this change. It also didn't suffer from the problems, so there's that.</li>
<li><strong>OpenGL</strong>: While it does have <em>proto-pipelines</em> with display lists and command lists, this change only targeted the newer APIs. OpenGL worked fairly well on most drivers anyway, so there wasn't <em>too much</em> to gain.</li>
</ul>
<p>Odds are, you probably won't see shader stuttering anymore <em>even</em> if you're on one of the configurations listed as not completely fixed. And if you <em>do</em> see shader stuttering, it'll be greatly reduced compared to before.</p>
<h4 id="50-17691-add-emulation-of-pointsizelinewidth-in-vertex-shaders-by-tellowkrinkle"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17691/">5.0-17691 - Add Emulation of Pointsize/Linewidth in Vertex Shaders</a></strong> by <strong><a href="https://github.com/tellowkrinkle">tellowkrinkle</a></strong><a class="headerlink" href="#50-17691-add-emulation-of-pointsizelinewidth-in-vertex-shaders-by-tellowkrinkle" title="Permanent link">¶</a></h4>
<p>This is a big one for macOS users, but it will have implications for everyone else sooner or later. The GameCube/Wii GPU has features called "Pointsize" and "Linewidth" which allows a developer to draw a point or line and give it an arbitrary size without having to use actual vertices or polygons. OpenGL developers may find that this feature <a href="https://registry.khronos.org/OpenGL-Refpages/gl4/html/glPointSize.xhtml">sounds</a> <a href="https://registry.khronos.org/OpenGL-Refpages/gl4/html/glLineWidth.xhtml">familiar</a>, but that is to be expected as the GameCube and Wii's pointsize and linewidth were based on OpenGL's! However, the GameCube added enough special sauce that they <a href="https://dolphin-emu.org/blog/2015/01/01/dolphin-progress-report-december-2014/#40-4699-line-widthpoint-size-unification-by-armada651">cannot be accurately emulated with OpenGL's native pointsize and linewidth</a>. Since newer APIs have nothing like this and neither does D3D11, all of the APIs our backends use do not support this feature natively.</p>
<p>Many games use these features, and without emulation of pointsize and linewidth, any lines will be <em>1</em> pixel wide and any points don't appear at all!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/networktrans-broken.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/networktrans-broken_thumb.jpg"></a>
<figcaption>Without proper Pointsize and Linewidth emulation, most of <a href="https://wiki.dolphin-emu.org/index.php?title=Mega_Man_Network_Transmission">Mega Man Network Transmission</a>'s effects are barely visible.</figcaption>
</figure>
</div>
<p>So, considering our host GPUs can't <em>natively</em> render this, we had to find a way to emulate it. Our solution has been the use of Geometry Shaders. Geometry Shaders are an optional shader stage that can take a primitive in as an input and can output zero or more primitives. For Dolphin's purposes, we could use the "Point" or "Line" request as the input and then, based on the other properties the game specifies for that point/line, draw triangles that will create an identical shape.</p>
<p>When Dolphin adopted Geometry Shaders, they were a new and promising feature in graphics tech. Unfortunately, they were quickly superseded by newer features because <em>Geometry Shaders are slow</em>, so games avoided them. This put Geometry Shaders in a precarious position that <em>finally</em> reached a breaking point with the Metal Graphics API by Apple - Metal does not support geometry shaders whatsoever. Even though Geometry Shaders work in macOS under OpenGL, but, it's not in Metal. For us, this meant we needed to find a new solution if we were going to emulate Pointsize and Linewidth on modern macOS machines.</p>
<p>Originally, <strong><a href="https://github.com/skylersaleh">skylersaleh</a></strong> (who did Dolphin's port to macOS M1 and now works on <a href="https://github.com/skylersaleh/SkyEmu">skyemu</a>) started an experiment with using tried and true Vertex Shaders. While this could make <em>wide-lines</em> and <em>thick-points</em>, the original experiment failed because it wasn't able to get them to render correctly. <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> picked it up but quickly found that this wasn't a simple fix.</p>
<p>Dolphin as it was couldn't give the Vertex Shaders all of the information it needed to determine the way to orient line caps. A way to work around this was to have <em>Dynamic Vertex Loaders</em>, which would be able to determine the information we need directly in the Vertex Shader. Funnily enough, while <strong><a href="#50-17403-add-dynamic-vertex-loaders-for-ubershaders-by-tellowkrinkle">5.0-17403</a></strong> was designed to make Ubershaders more effective, those same Dynamic Vertex Loaders could be used to finally finish Pointsize/Linewidth with a Vertex Shader!</p>
<p>Support for Geometry Shaders, especially with Metal outright abandoning them, might be on the way out. So having this option is <em>good</em> now, but might be outright necessary later. Currently, we still use Geometry Shaders when they're available, but on GPUs without Geometry Shader support, Dolphin will now use the Vertex Shader implementation instead. Users can also try it out - it can be enabled in Graphics Settings -> Advanced with "Prefer VS for Point/Line Expansion".</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/networktrans-working.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/networktrans-working_thumb.jpg"></a>
<figcaption>With working effects, Network Transmission comes to life!</figcaption>
</figure>
</div>
<p>Because the Vertex Shader implementation is slightly faster, we will probably move over to it as the default implementation. This actually comes into play throughout the <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime:_Trilogy">Metroid Prime Series</a>, where the linewidth effects can effect overall performance. If your machine has a driver with incredibly slow Geometry Shader support, this may help things! However, on most modern GPUs, this is far down on the list of bottlenecks.</p>
<hr />
<p><em>Note: Our D3D11 Backend does not have Vertex Shader Linewidth/Pointsize for now. It's not <em>impossible</em> to accomplish, but due to the inline constant system from D3D12 not existing, it would take a different implementation.</em></p>
<hr />
<h4 id="50-17836-debugging-add-support-for-conditional-breakpoints-by-smurf3tte-and-trytwo"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17836/">5.0-17836 - Debugging: Add Support for Conditional Breakpoints</a></strong> by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> and <strong><a href="https://github.com/TryTwo">TryTwo</a></strong><a class="headerlink" href="#50-17836-debugging-add-support-for-conditional-breakpoints-by-smurf3tte-and-trytwo" title="Permanent link">¶</a></h4>
<p>For people debugging, modding, TASing, or just in general messing around with a game's behavior, this is a major enhancement that will make your life easier. Dolphin has long had support for breakpoints, but the problem was that if it was a frequently used instruction, you'd have no way of telling it only to notify you if the condition you were looking for actually happened. Instead, debuggers would often rely on third party tools in order to debug more difficult issues.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/conditionalbreakpoints.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/conditionalbreakpoints_thumb.png"></a>
<figcaption>Conditional Breakpoints make debugging hot functions much easier.</figcaption>
</figure>
</div>
<p>This change adds support for basic logical conditions, but <strong><a href="https://github.com/TryTwo">TryTwo</a></strong> has already started work on callstack based conditions and support for conditional Memory Breakpoints as well.</p>
<h4 id="50-17902-add-gba-tas-window-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17691/">5.0-17902 - Add GBA TAS Window</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-17902-add-gba-tas-window-by-josjuice" title="Permanent link">¶</a></h4>
<p>When Dolphin added support for the <a href="https://dolphin-emu.org/blog/2021/07/21/integrated-gba/">Integrated GBA</a> there was some excitement about TASing titles that require GBAs. After all, Integrated GBAs worked with Dolphin's movie code as shown by Netplay Support!</p>
<p>Technically, Integrated GBAs could be controlled using TAS input when things were merged, but there was no built-in support. Instead, <strong><a href="https://github.com/Bonta">Bonta</a></strong> hooked up the existing GameCube Controller TAS input to the GameCube TAS Input window. However, as with any major, complex change, this detail was actually overlooked. When the TAS Input Handling was rewritten, this feature was accidentally removed and suddenly there was no way to control Integrated GBAs through TAS Input.</p>
<p>As the guilty party that accidentally removed support, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> quickly jumped on the issue to rectify things as soon as they realized what had happened. But rather than just returning the old normal, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> greatly improved the situation by making a special TAS Input window for Integrated GBAs with all of the controls now clearly labeled.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/gbatas.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/gbatas_thumb.png"></a>
<figcaption>Will we see a Four Swords Adventures 4 player TAS someday? We sure hope so!</figcaption>
</figure>
</div>
<h4 id="50-17907-improve-fpsvps-counting-and-revamp-appearance-by-sam-belliveau"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17907/">5.0-17907 - Improve FPS/VPS Counting and Revamp Appearance</a></strong> by <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong><a class="headerlink" href="#50-17907-improve-fpsvps-counting-and-revamp-appearance-by-sam-belliveau" title="Permanent link">¶</a></h4>
<p>Dolphin's FPS counter has always just been <em>there</em>. We don't even know for sure how long we've had it - we found it in <a href="https://github.com/dolphin-emu/dolphin/commit/38ff37539d54ac53ff79aeb2f4cdc2be10ddd36a">r488 (1.0-488)</a> from 9 Sept 2008, but it could be even older! It has changed a lot in that time of course. Originally it was an overlay built directly into each graphics <em>plugin</em>, before being moved to the Rasterfont system split between videocommon and the video backend, and finally moving to the shared Dear ImGui form we have today. However, despite being moved and rebuilt several times, how our FPS display calculates frames per second has never changed. Until today.</p>
<p>Progress Report newcomer <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> was distracted by how Dolphin's FPS display constantly flickered above and below 60FPS. It annoyed them so much that he decided he was going to do something about it... and fell down a rabbit hole. First of all, he added VPS (v-blanks per second) and emulation speed measures to the performance overlay, so that users in fullscreen and on Android can <em>finally</em> get this essential information.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-newdisplay.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-newdisplay_thumb.png"></a>
<figcaption>The above is correct. In NTSC territories the GameCube and Wii operate at 59.94fps not 60, requiring us to do some shenanigans for correct emulation on modern displays. What you see in Dolphin's titlebar is rounded to whole frames.</figcaption>
</figure>
</div>
<p>And he added color to the performance overlay, providing a very glanceable indicator of Dolphin's performance! The colors are cyan (full speed), green, yellow, orange, then finally red.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-colours.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-colours.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Red is bad. You probably didn't need us to tell you that.</figcaption>
</figure>
</div>
<p>But most importantly, he changed how Dolphin's FPS display is averaged. Before we explain how he did it, here's a before and after of the FPS display with a title running at a perfect 60fps (59.94 technically).</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-noneuler.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-noneuler.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>With the old formula, the FPS counter was a little unstable, with a variance of about half a frame. Unfortunately, it varied above and below 60fps, causing the most significant digits to constantly change. It was difficult to keep track of performance with this display. </figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-euler.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-euler.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>With the new formula, the FPS display no longer flickers the most significant digits and its variance is actually close to Dolphin's rendering! <br/><sub>Note: It isn't staying exactly 59.94 due to the shenanigans we have to do running 59.94 content on a 60hz display.</sub></figcaption>
</figure>
</div>
<p>Previously, the FPS display used an extremely simple formula: <code>number of frames in the sample / microseconds of the sample / 1,000,000</code>. That's it. This is an incredibly basic way to calculate frames per second, and it has worked for Dolphin for a very long time. It does the job. However, the downside of this method is that it is "sample and hold". Between samples Dolphin just shows the previous sample, completely unchanged, which feels unresponsive and could make stutters and other problems either invisible or overly emphasized. To minimize this Dolphin could use a very short sample cycle, but that has the consequence that each sample has little data to work with. If your sample size is only a few frames long, then even a spike lasting a <em>single frame</em> could significantly alter the results of the average, making the FPS display highly unstable. A longer sample time would resolve that, but then we're back to having it feel unresponsive and hiding stutters and other problems. So Dolphin developers of the past chose a sample duration of 0.25 seconds - this leaned a bit toward frenetic and unstable but kept the FPS display reasonably responsive. With a super simple formula like this, compromises are unavoidable.</p>
<p>The solution to this is to use an exponential moving average on top of a standard moving average - we'll call this a "Euler Average" for short. Basically, it averages the framerate over the last second (by default) using a <a href="https://www.fidelity.com/learning-center/trading-investing/technical-analysis/technical-indicator-guide/sma">standard moving average</a>, then applies an <a href="https://www.fidelity.com/learning-center/trading-investing/technical-analysis/technical-indicator-guide/ema">exponential moving average</a> on top to reduce jitter. The result of this math is that Dolphin can sample every frame so it is always up to date, it can smooth out sudden spikes and drops for a stable, legible indicator, and it can update the FPS indicator <em>every frame</em> so it is visually pleasing as well!</p>
<p>To show how this works in action, here is a graph showing the two methods against eachother. The data we're feeding into it is from a Dolphin test with an unlocked framerate, with frame to frame swings as high as <strong>100FPS</strong>. It's a worst case scenario for an FPS display. How do the old and new FPS formulas handle this awful data?</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/eulerfpsdisplay.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/eulerfpsdisplay_thumb.png"></a>
<figcaption>Click for detail.</figcaption>
</figure>
</div>
<p>The purpose of an FPS display is to give a glanceable reference of a game's performance. But the FPS display with the original formula can't handle data that is this variable. It just goes all over the place; even if you stared at it you would have no idea how fast the game is performing! But the Euler average is able to display a proper average of the framerate even from this garbage data. Of course, no one should encounter frametime variance on this level in actual gameplay unless something has gone <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/#dev-diary-putting-a-mac-through-its-paces-by-mayimilae">very very wrong</a>, but even in this worst case scenario our frame rate display is now able to do its job thanks to the new formula!</p>
<p>A consequence of using the Euler Average is that there is a now ramp up. If a game goes from 0FPS to 60FPS in one frame, it will take the whole sample window (1 second by default) to resolve to 60. Averaging the current data with prior data prevents sudden spikes and drops from making the FPS display devolve into noise, so it has to catch up to extreme change. To account for this, this change also adds a control to allow the user to change the sample window duration. A longer window will give a smoother and more consistent indicator, and a shorter window will be more frenetic but will be closer to real time and show smaller drops.</p>
<p>This and other new controls necessitated a move for our performance display options. You'll now find them in Graphics > Advanced under "Performance Statistics". This is not necessarily their permanent home but it's a safe place for <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> to continue working on this feature.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-settings.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/fps-settings_thumb.png"></a>
<figcaption></figcaption>
</figure>
</div>
<p>With this, our performance statistics display is better than ever! But <strong><a href="https://github.com/Sam-Belliveau">Sam-Belliveau</a></strong> is not done. Expect this feature to get even better in the coming months!</p>
<h3 id="more-patches-for-dcache-reliant-games"><strong>More Patches for dcache Reliant Games</strong><a class="headerlink" href="#more-patches-for-dcache-reliant-games" title="Permanent link">¶</a></h3>
<p>Dolphin doesn't <em>currently</em> target emulating the CPU Data Cache (dcache) and once it does, odds are that enabling it will make emulation too slow. For now, we're relying on patching these games that accidentally rely on the GameCube/Wii's CPU dcache behaviors.</p>
<p>The past three months, we've seen two new patches from <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong>, who has done the hard work of reverse engineering these games, figuring out <em>why</em> they need dcache emulation, and patching their code to no longer need it! So if you're playing <a href="https://wiki.dolphin-emu.org/index.php?title=Dead_to_Rights">Dead to Rights</a> (audio issues) or <a href="https://wiki.dolphin-emu.org/index.php?title=Ten_Pin_Alley_2">Ten Pin Alley 2</a> (crashing before gameplay) in the latest development builds, you have <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> to thank!</p>
<p>Note that the patch for <a href="https://wiki.dolphin-emu.org/index.php?title=Ten_Pin_Alley_2">Ten Pin Alley 2</a> is only for the NTSC version of the game.</p>
<h3 id="the-android-gui-refresh"><strong>The Android GUI Refresh</strong><a class="headerlink" href="#the-android-gui-refresh" title="Permanent link">¶</a></h3>
<p>There are far too many changes that have gone into this over the past quarter of the year. <strong><a href="https://github.com/t895">t895</a></strong> has been extremely busy going through the Android GUI and modernizing it. From redesigning buttons, to making things fit your phone's theme/shape/size, and even some optimizations that will allow the menus to run more smoothly with fewer hitches.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-adjustcontrols-before.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-adjustcontrols-before_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-adjustcontrols-after.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-adjustcontrols-after_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<center><p>Everything is at least a little nicer than before!</p></center>
</div>
</div>
<p>One of the biggest keys is that Dolphin now supports Google's "Material You" design system. By default, Dolphin uses its own color scheming under "Material 3", but if you want it to match your system-wide theming better, you can swap over to "Material You" and several other color based options in the theme menu.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-themeswitcher.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-themeswitcher_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption></figcaption>
</figure>
</div>
<p>In addition to the theming changes, <strong><a href="https://github.com/t895">t895</a></strong> has greatly optimized the cover loading/caching mechanism to prevent the lockups on first load when swapping between GC/Wii/WiiWare tabs. This should make app usage much smoother overall. There are tons of minor fixes, especially for those with oddly shaped phones that should prevent things from going off screen or awkwardly resizing.</p>
<p>A bunch of the menus have also been redesigned to make things fit better and look nicer.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-cheats-before.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-cheats-before_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-cheats-after.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-cheats-after_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<center><p>Some changes are subtle.</p></center>
</div>
</div>
<p><br/></p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-gamecard-before.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-gamecard-before_thumb.jpg" /></a>
<figcaption></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-gamecard-after.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-gamecard-after_thumb.jpg" /></a>
<figcaption></figcaption>
</figure>
<center><p>Others are radically better.</p></center>
</div>
</div>
<p><br/></p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-riivolution-before.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-riivolution-before_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-riivolution-after.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-october/androidgui-riivolution-after_thumb.png" /></a>
<figcaption></figcaption>
</figure>
<center><p>But basically every window has been given some needed attention.</p></center>
</div>
</div>
<p><br/></p>
<p>While none of this <em>directly</em> affects emulation, it does make setting up the emulator easier and allows for greater customization. Those of you that want your phone and its apps to be personalized for you should have a lot of fun with these changes. For everyone else, these changes will make setting up and adjusting things from within the emulator much smoother.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2022-09-01&to=2022-12-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-17271/">5.0-17271</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-17995/">5.0-17995</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: July and August 2022
2022-09-13T07:46:32+00:002022-09-13T23:20:38.228907+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2022/09/13/dolphin-progress-report-july-and-august-2022/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/progressreportheader-july2022-2.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/progressreportheader-july2022mini-2.jpg" />
</header>
<p>The Summer tends to consistently be one of the busiest times for Dolphin's development. While sometimes the question is <em>what do we put into the Progress Report</em>, during the summer months it's usually <em>how much can we fit into the Progress Report?</em> This summer's congestion was <em>then</em> compounded by us blog staff having a few things we've been planning coming into fruition. Still, the show must go on, and we're here... albeit a bit delayed.</p>
<p>As such, we've got a huge smattering of changes to go over and many smaller ones that we couldn't quite fit in. macOS users in general will be able to rejoice with the addition of a brand new Metal backend brought to us by veteran developer <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong>. They also brought their graphics expertise to improve things for everyone, greatly reducing the remaining causes of shader based delays/stuttering when using Ubershaders. If you're looking for an easier way to setup a wide variety of controllers, a new SDL2 controller backend has been added for all OSes, and even brings <em>native</em> motion control support without the use of a DSU server to non-Linux operating systems. We also have a wide variety of emulation fixes, more graphics mods added, and the long awaited SD card "folder" feature!</p>
<p>All of that and it's our job to write about it. We've got our work cut out for us.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-16965-macos-add-metal-backend-by-tellowkrinkle-and-50-17206-moltenvk-update-to-v1111-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16965/">5.0-16965 - macOS: Add Metal Backend</a></strong> by <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17206/">5.0-17206 - MoltenVK: Update to v1.1.11</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-16965-macos-add-metal-backend-by-tellowkrinkle-and-50-17206-moltenvk-update-to-v1111-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>Early on in Metal's life, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> experimented with adding a Metal Graphics Backend to Dolphin. Unfortunately, due to Dolphin's <a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">quirks</a> and unfamiliarity with the Metal API, the effort stalled out. However, in the midst of that struggle an alternative arrived - <a href="https://github.com/KhronosGroup/MoltenVK">MoltenVK</a>. As a translation layer between Vulkan and Metal, MoltenVK allowed us to support Metal through our Vulkan graphics backend, with little effort on our end. This proved to be a very successful compromise, and it may very well have saved our macOS support.</p>
<p>But, in theory, a <em>native</em> Metal backend would be faster than MoltenVK. Enter <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> the architect of <a href="https://pcsx2.net/">PCSX2</a>'s macOS port and Metal Graphics Backend. Having conquered Metal on PCSX2, they turned their attention to Dolphin and decided to try their hand at a native Metal backend. The results were <em>immediately</em> apparent.</p>
<p><br/>
<script>
addChart({"title":{"text":"Native Metal vs MoltenVK (With Performance Regression)"},"subtitle":{"text":"5.0-17134 | 3x Native, Dual Core | M1 Max (32 GPU Core)"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"series":[{"name":"MoltenVK","turboThreshold":0},{"name":"Metal","turboThreshold":0}],"data":{"csv":"\"null\";\"MoltenVK\";\"Metal\"\n\"Melee: FoD All Lv9 Ice Climbers<em>\";128;157\n\"Brawl: New Pork All Lv9 Ice Climbers</em>\";129;137\n\"Metroid Prime 3: Elysia Vista (Single Core, 1x Native)\";37;64\n\"Skyward Sword: Skyloft Vista\";80;116\n\"Rogue Leader: Hoth Start\";52;70","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"V-Blanks per Second (VPS)"},"tickInterval":30,"max":180,
plotLines: [{
color: '#00c800',
width: 4,
dashStyle: "LongDash",
label: {text: "Fullspeed", align: "right", style: {'text-shadow': 'rgb(255, 255, 255) 3px 0px 0px, rgb(255, 255, 255) 2.83487px 0.981584px 0px, rgb(255, 255, 255) 2.35766px 1.85511px 0px, rgb(255, 255, 255) 1.62091px 2.52441px 0px, rgb(255, 255, 255) 0.705713px 2.91581px 0px, rgb(255, 255, 255) -0.287171px 2.98622px 0px, rgb(255, 255, 255) -1.24844px 2.72789px 0px, rgb(255, 255, 255) -2.07227px 2.16926px 0px, rgb(255, 255, 255) -2.66798px 1.37182px 0px, rgb(255, 255, 255) -2.96998px 0.42336px 0px, rgb(255, 255, 255) -2.94502px -0.571704px 0px, rgb(255, 255, 255) -2.59586px -1.50383px 0px, rgb(255, 255, 255) -1.96093px -2.27041px 0px, rgb(255, 255, 255) -1.11013px -2.78704px 0px, rgb(255, 255, 255) -0.137119px -2.99686px 0px, rgb(255, 255, 255) 0.850987px -2.87677px 0px, rgb(255, 255, 255) 1.74541px -2.43999px 0px, rgb(255, 255, 255) 2.44769px -1.73459px 0px, rgb(255, 255, 255) 2.88051px -0.838247px 0px'}},
value: 60,
zIndex: 5,
}],
}, "pane":{"background":[]},"responsive":{"rules":[]},"colors":["#ff3100","#006eff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"]})
</script></p>
<p><marquee behavior="alternate">The above graph is not current, please keep reading.</marquee></p>
<p><br/></p>
<p>Our macOS users were extremely excited by these improvements! In GPU heavy titles, such as the GPU focused Skyloft and Elyia tests, the difference was enormous! However, something felt off. Our native Metal backend was performing <em>too much better.</em> Based on our prior experience and general industry knowledge, MoltenVK is an excellent translation layer - a native Metal implementation should only be a little faster. But the new Metal backend was functioning correctly and we weren't going to argue with improved performance, so we cautiously continued forward. When we ran our new Metal graphics backend and MoltenVK through the tests above <em>for this very Progress Report</em>, it finally hit us. The MoltenVK results we were getting, as recorded in the graph above, were far lower than the previous times <a href="https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/#macsimum">we've shown</a> <a href="https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/#50-15538-mmu-support-for-aarch64-jit-by-josjuice">these tests</a>. It varied substantially depending on the test (hence the difficulty isolating this), but in some scenarios MoltenVK was performing up to <strong>45% worse</strong> than before! Something had gone wrong.</p>
<p><br/>
<script>
addChart({"title":{"text":"MoltenVK Performance Regression"},"subtitle":{"text":"Metroid Prime 3 Elysia Vista, M1 Max (32 GPU Core), Single core, 1x Native"},"exporting":{},"chart":{"type":"column","inverted":true,"polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"series":[{"name":"FPS","turboThreshold":0}],"data":{"csv":"\"Backend\";\"FPS\"\n\"MoltenVK Before (5.0-15472)\";60\n\"MoltenVK During (5.0-17134)\";37\n\"Metal (5.0-17134)\";64","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"labels":{"format":"{value} FPS"}},"xAxis":{"labels":{"format":"{value}"}},"colors":["#006eff","#434348","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"legend":{"enabled":false},"pane":{"background":[]},"responsive":{"rules":[]}})
</script>
<p><center>Comparing our native Metal results to our old MoltenVK results, Metal is still better, but by only a little bit.</center></p>
<br/></p>
<p>Now with some solid reproducible cases, we went to work bisecting to isolate this nasty performance regression. We traced it to <a href="https://dolphin-emu.org/download/dev/master/5.0-15474/">5.0-15474</a> - a MoltenVK version update. This was a regression in MoltenVK itself.</p>
<p>Normally the story would end here. We are a tiny volunteer team, we cannot be expected to debug another project! However <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> went above and beyond and, using their Metal knowledge, worked with our testers to isolate the regression in MoltenVK. The end of their bisecting was <a href="https://github.com/KhronosGroup/MoltenVK/commit/4371ef4d2b706d761acac49c1b7f9d413d0d15db">KhronosGroup/MoltenVK@4371ef4</a>, a change that contained a number of optimizations for Vulkan Descriptor Pools.</p>
<p>In Vulkan, descriptor sets are used to tell the graphics driver what resources (textures, buffers, etc) to make available for shaders to use. However, a program cannot create descriptor sets. Instead, the program needs to create a descriptor pool with a specified maximum number of sets, and then the pool itself allocates the descriptor sets.</p>
<p>Most programs implement this with a "growth strategy" where they ask for a small pool of a few thousand sets, then enlarge the pool as required. Dolphin however takes the simple route, and just asks for a pool of <em>100,000 descriptor sets.</em> Though inefficient, by asking for a pool far larger than anything it can ever possibly fill, Dolphin never has to worry about managing the pool.</p>
<div class="media-block wider">
<figure>
<a href="https://github.com/dolphin-emu/dolphin/blob/ffdc8538a162b1ca56e3943c5a78c02358053b2a/Source/Core/VideoBackends/Vulkan/CommandBufferManager.cpp#L96">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/abetterway.png"></a>
<figcaption>Our Vulkan descriptor allocation code has been untouched since <a href="https://github.com/dolphin-emu/dolphin/blob/ffdc8538a162b1ca56e3943c5a78c02358053b2a/Source/Core/VideoBackends/Vulkan/CommandBufferManager.cpp#L96">Stenzek's very first implementation six years ago</a>. If anyone has the know-how and wants to make this better, by all means, have at it.</figcaption>
</figure>
</div>
<p>Once Dolphin allocates the tiny fraction of the pool's descriptor sets that it needs, it uses <code>vkResetDescriptorPool</code> (<a href="https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/vkResetDescriptorPool.html">link</a>) to give the used sets back to the pool for the next draw. Importantly, Vulkan resets <em>only the used sets,</em> leaving the rest of the 100,000 sets untouched - Dolphin's approach only makes sense because of this detail.</p>
<p>And that is exactly where MoltenVK's regression occurred. In the optimizations for Vulkan Descriptor Pools, MoltenVK accidentally made <code>vkResetDescriptorPool</code> reset ALL descriptor sets in a pool, regardless of what was actually used. Most programs wouldn't have any problem with this as they use as small of pools as possible, but Dolphin's 100k pool smashed into this issue. <code>vkResetDescriptorSets</code> was now taking up a significant amount of CPU time, causing many types of GPU heavy titles to become CPU limited within MoltenVK!</p>
<p>Once we had all of this figured out, <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> forwarded our results to MoltenVK. There, the author of the original optimization that caused this regression, <strong><a href="https://github.com/billhollings">billhollings</a></strong>, swooped in. They improved the implementation so it only reset descriptor sets that were actually used, and made a PR within a couple days of our report. Once that was merged into MoltenVK, we quickly tested it to confirm it fixed our issue and <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> made a pull request to update Dolphin to the latest version of MoltenVK. The regression was resolved!</p>
<p>We'll save the full graph for later and focus exclusively on the regression fix for the moment. How much faster is latest master (as of this writing) compared to the version we showed earlier?</p>
<p><br/>
<script>
addChart({"title":{"text":"Percent Improvement 5.0-17134 to 5.0-17268"},"subtitle":{"text":"M1 Max (32 GPU Cores), using previous test data"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"series":[{"name":"MoltenVK","turboThreshold":0},{"name":"Metal","turboThreshold":0}],"data":{"csv":"\"null\";\"MoltenVK\";\"Metal\"\n\"Melee: FoD All Lv9 Ice Climbers\";15.6;5\n\"Brawl: New Pork All Lv9 Ice Climbers\";6;-2\n\"Metroid Prime 3: Elysia Vista (Single Core, 1x Native)\";62;1.6\n\"Skyward Sword: Skyloft Vista\";17.5;0\n\"Rogue Leader: Hoth Start\";13.5;10","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"labels":{"format":"{value}%"},"tickInterval":10},"xAxis":{},"pane":{"background":[]},"responsive":{"rules":[]},"colors":["#ff3100","#006eff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"legend":{}})
</script>
<br/></p>
<p>While we are focusing on MoltenVK right now, Metal <em>also</em> got a little faster on Apple silicon thanks to an unrelated AArch64 JIT optimization that was merged between our sample versions. Our data is a little messy because developers just keep making Dolphin better, how dare they. </p>
<p>In MoltenVK, the performance regression fix (plus that JITARM optimization) lead to noticeable performance gains across the board. But for the the GPU heavy titles that were strongly affected by the regression, such as <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_3:_Corruption_(Wii)">Metroid Prime 3</a>, the performance improvement is <strong>enormous!</strong> It took Prime 3 from completely unplayable to playable with occasional slowdown. All of the performance that MoltenVK had in older builds was back!</p>
<p>This regression fix also improves MoltenVK's performance in Bounding Box, especially on Intel graphics. However this section is already <strong>ginormous</strong> so rather than posting yet another graph, just <a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/mvkboundingbox.png">click here if you want to see the chart.</a></p>
<p>Now with that nasty regression sorted, we can finally return to Metal. How does our shiny new Metal backend compare to MoltenVK now that it's a fair fight?</p>
<p><br/>
<script>
addChart({"title":{"text":"Native Metal vs MoltenVK"},"subtitle":{"text":"5.0-17268 | 3x Native, Dual Core | M1 Max (32 GPU Core)"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"series":[{"name":"MoltenVK","turboThreshold":0},{"name":"Metal","turboThreshold":0}],"data":{"csv":"\"null\";\"MoltenVK\";\"Metal\"\n\"Melee: FoD All Lv9 Ice Climbers<em>\";148;165\n\"Brawl: New Pork All Lv9 Ice Climbers</em>\";137;134\n\"Metroid Prime 3: Elysia Vista (Single Core, 1x Native)\";60;65\n\"Skyward Sword: Skyloft Vista\";94;116\n\"Rogue Leader: Hoth Start\";59;77","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"V-Blanks per Second (VPS)"},"tickInterval":30,"max":180,
plotLines: [{
color: '#00c800',
width: 4,
dashStyle: "LongDash",
label: {text: "Fullspeed", align: "right", style: {'text-shadow': 'rgb(255, 255, 255) 3px 0px 0px, rgb(255, 255, 255) 2.83487px 0.981584px 0px, rgb(255, 255, 255) 2.35766px 1.85511px 0px, rgb(255, 255, 255) 1.62091px 2.52441px 0px, rgb(255, 255, 255) 0.705713px 2.91581px 0px, rgb(255, 255, 255) -0.287171px 2.98622px 0px, rgb(255, 255, 255) -1.24844px 2.72789px 0px, rgb(255, 255, 255) -2.07227px 2.16926px 0px, rgb(255, 255, 255) -2.66798px 1.37182px 0px, rgb(255, 255, 255) -2.96998px 0.42336px 0px, rgb(255, 255, 255) -2.94502px -0.571704px 0px, rgb(255, 255, 255) -2.59586px -1.50383px 0px, rgb(255, 255, 255) -1.96093px -2.27041px 0px, rgb(255, 255, 255) -1.11013px -2.78704px 0px, rgb(255, 255, 255) -0.137119px -2.99686px 0px, rgb(255, 255, 255) 0.850987px -2.87677px 0px, rgb(255, 255, 255) 1.74541px -2.43999px 0px, rgb(255, 255, 255) 2.44769px -1.73459px 0px, rgb(255, 255, 255) 2.88051px -0.838247px 0px'}},
value: 60,
zIndex: 5,
}],
}, "pane":{"background":[]},"responsive":{"rules":[]},"colors":["#ff3100","#006eff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"]})
</script>
<br/></p>
<p>The theory holds true - our own native Metal graphics backend is faster than translating our Vulkan backend to Metal via MoltenVK. Most notable here is <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">Skyward Sword</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Rogue Leader</a>, where Metal has a considerable performance benefit of +23% and +30%. Metal even takes Hoth to a reliably full speed experience for the first time ever on an Apple laptop! That being said, now that it is no longer held back by a performance regression, MoltenVK puts up a hell of a fight.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/macm1/imsorry.jpg">
<img src="https://dolphin-emu.org/m/user/blog/macm1/imsorry_thumb.jpg"></a>
<figcaption></figcaption>
</figure>
</div>
<!-- the above is a spacer -->
<p>After reading all of this you might be thinking, "now that someone has made a native Metal backend, you're going to remove MoltenVK right?" <em>Absolutely not</em>, MoltenVK is here to stay. The MoltenVK performance regression was a huge reminder for us on why we have many graphics backends in the first place.</p>
<p>During the regression, many users came to us and complained that it was slower than before. Some even correctly bisected the regression in Dolphin! However, due to the complexity of the issue, no one was able to clearly give us a reproducible case. Without anything to compare it against, we simply looked at MoltenVK's performance in whatever we wanted to try, found it fine, and moved on. However, once we had the Metal backend and compared it to MoltenVK, we immediately noticed the performance disparity was beyond our expectations and began searching for the problem. The <em>Metal backend</em> is why we noticed the performance regression in MoltenVK! Relying on only one graphics backend for macOS (OpenGL doesn't count anymore) let this regression slip under our noses.</p>
<p>Having other graphics backends to compare against is essential for the maintenance of our graphics backends, and this is especially important on macOS where we have so few. The new Metal graphics backend is our own code, so any issues or regressions with it are on <em>us</em> to solve. We will be relying on MoltenVK to be the benchmark that we compare our native Metal backend against going forward. And it should perform that role excellently, as it is bringing our well tested Vulkan backend to macOS through a very well supported translation layer from a team that has earned our trust.</p>
<p>So while our new native Metal backend is faster, MoltenVK is here to stay. Together, they will help us deliver the most consistently reliable and performant experience that we can give to our macOS users.</p>
<hr />
<p><em>Note: Due to changed (much improved) methodology, the Fountain of Dreams and New Pork tests are not directly comparable to prior results. All other tests maintain the same methodology.</em></p>
<hr />
<h4 id="50-16930-reduce-pipeline-compilation-stutter-through-forcing-fbfetch-in-ubershaders-by-tellowkrinkle"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16930/">5.0-16930 - Reduce Pipeline Compilation Stutter through Forcing FBFetch in Ubershaders</a></strong> by <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong><a class="headerlink" href="#50-16930-reduce-pipeline-compilation-stutter-through-forcing-fbfetch-in-ubershaders-by-tellowkrinkle" title="Permanent link">¶</a></h4>
<p><a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">Ubershaders</a> was a revolutionary moment in GameCube/Wii emulation. It presented a hope, a solution against the problem that TEV changes were <em>instant</em> while generating/compiling new shaders on modern GPUs was not. Under certain circumstances, Ubershaders can <em>completely</em> remove all Shader Compilation Stuttering... but for some users, their limitations meant that they couldn't get a smooth experience.</p>
<p>On top of being demanding, newer graphics APIs have thrown a curveball at Ubershaders. Namely, they have pipelines to optimize rendering, and these pipelines will analyze what is being rendered and only use what is necessary to simplify shaders and increase performance. Because different GPUs and drivers have hardware and software support for different things, the pipeline compilation stuttering can vary depending on the driver. D3D11, through a mixture of not having pipelines + good driver support, was the only backend that <em>completely</em> had Shader Stuttering removed on certain graphics cards... until now.</p>
<p><strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> showed up with the Metal backend and a deep dive in to how Dolphin was generating shaders. They identified some of the weaknesses in what Dolphin was doing and identified them during the development of the the Metal Backend and started coming up with solutions.</p>
<p>One such problem is that Dolphin actually had <em>too many</em> configurations to precompile every pipeline configuration. But, there was a way to mend that. By sacrificing performance and simplifying the Ubershaders to only use a single method for blending, we could actually precompile <em>every</em> pipeline configuration with some other changes down the road. To achieve this, <em>FrameBuffer Fetch</em> is now used for almost all blend unit configurations in the Ubershaders for GPUs that support this feature. Considering that Apple GPUs and some mobile GPUs support FBFetch, many of our users should be able to see a major difference.</p>
<p>This reduces the extra shader compilation stuttering that was happening on Apple and some mobile chipsets and further sets us up to reduce stuttering across all GPUs. <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> has more changes on the way that should completely eliminate* Shader Compilation Stuttering on many GPUs that currently have issues in Vulkan and D3D12 when using Exclusive or Hybrid Ubershaders. Stay tuned.</p>
<h4 id="50-16861-controllerinterface-add-support-for-native-motionrumble-with-sdl2-and-re-enable-sdl-on-windows-builds-by-shuffle2"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16861/">5.0-16861 - ControllerInterface - Add Support for Native Motion/Rumble with SDL2 and Re-Enable SDL on Windows Builds</a></strong> by <strong><a href="https://github.com/shuffle2">shuffle2</a></strong><a class="headerlink" href="#50-16861-controllerinterface-add-support-for-native-motionrumble-with-sdl2-and-re-enable-sdl-on-windows-builds-by-shuffle2" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:20%; min-width:200px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2015-july/Sdl-logo.png">
</div>
<p>Back in July 2015, Dolphin waved goodbye to its SDL input backend. Back then, there wasn't much point for Dolphin to even be using it. It didn't really serve our needs on <a href="https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/#40-6951-linux-add-an-evdev-based-controller-backend-to-replace-sdl-by-phire">Windows or macOS</a>, and on Linux it was essentially just an evdev wrapper that we could (and <a href="https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/?nocr=true#40-6951-linux-add-an-evdev-based-controller-backend-to-replace-sdl-by-phire">eventually did</a>) implement ourselves.</p>
<p><br/><blockquote style="font-size:1.1em">Unfortunately for Dolphin, the vastness of SDL has caused a number of problems over the years, and has slowly been removed bit by bit. For example, in <a href="https://dolphin-emu.org/download/dev/dd413269e30c35a2744c9321323b7fb9d48ce942/">4.0-1628</a> the SDL backend was removed from Dolphin on Windows due to numerous crash reports related to webcams. SDL was reading the <a href="https://forums.dolphin-emu.org/Thread-my-entire-computer-crashes-every-time-i-use-dolphin">webcam as a controller</a> with thousands of buttons, crashing the emulator. <footer><a href="https://dolphin-emu.org/blog/2015/08/01/dolphin-progress-report-july-2015/#40-6951-linux-add-an-evdev-based-controller-backend-to-replace-sdl-by-phire">Dolphin Progress Report: July 2015</a></footer></blockquote><br/></p>
<p>However, over the last seven years, a lot of resources have been pumped into SDL and it's greatly improved from when we waved goodbye. In 2018 it added a feature that was <em>very</em> interesting for us - Motion Inputs. Dolphin didn't yet have the emulated MotionPlus infrastructure, but we've kept our eye on SDL knowing that it might provide an easy way to get Gyro and Accelerometer while also being a stable cross-platform API that we could rely on much like Cubeb has become for audio.</p>
<p>In 2022, we've finally taken the plunge and re-added support for SDL, relying on the new and improved versions of the controller API.</p>
<p>On Linux and macOS, the situation is similar. This is especially important for macOS, where Motion Controls are a lot more annoying to setup. In fact, Wii Remotes <em>can't</em> easily be connected to any macOS version from Monterey onward due to an unknown bug with Apple's Bluetooth stack that seems to be rather low priority to fix. Some users have found success using external Bluetooth adapters or using a DolphinBar.</p>
<h4 id="50-16891-sd-card-folder-syncing-support-by-admiralcurtiss-and-stblr"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16891/">5.0-16891 - SD Card Folder Syncing Support</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> and <strong><a href="https://github.com/stblr">stblr</a></strong><a class="headerlink" href="#50-16891-sd-card-folder-syncing-support-by-admiralcurtiss-and-stblr" title="Permanent link">¶</a></h4>
<p>This is one of the longest awaited features that has been requested many times over the years. You can now set a <em>SD Card Sync Folder</em> that allows you to place files in that folder and let Dolphin automatically create an appropriately sized SD Card. This setup was inspired by how <a href="https://melonds.kuribo64.net/">melonDS</a> handles SD cards and was originally submitted by <strong><a href="https://github.com/stblr">stblr</a></strong> in <a href="https://github.com/dolphin-emu/dolphin/pull/10525">March</a>.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/sdcardfolder.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/sdcardfolder_thumb.png"></a>
<figcaption></figcaption>
</figure>
</div>
<p>Previously, handling SD cards in Dolphin was rather annoying, especially on Windows and Android. On Linux/macOS, it was a <em>bit</em> easier. There, you could mount the sd.raw file that Dolphin uses to simulate the SD card and edit files on it just like you would a real SD card. On Windows, this could only be accomplished by installing a third party program and is generally a bit buggy when trying to unmount virtual drives. On Android, you couldn't edit the sd.raw at all without access to another Operating System!</p>
<p>The new system isn't perfect, but it does simplify things quite a bit. Dolphin still uses the sd.raw file <em>during</em> emulation, but now you can choose a folder that Dolphin can use to <em>build</em> the sd.raw file. No more mounting, no more third party programs, just simply configure your sd card folder how you want it and let Dolphin do the work. Dolphin can also export the current sd.raw into this folder, if you've already been using other methods.</p>
<p>As a potentially added bonus, there is an option to automatically sync this folder at emulation start and end. This will keep your folder up to date if you're using it a lot, but we don't recommend using it on larger SD cards, as this process can take a long time on slower disks and cause a large delay in starting Wii emulation.</p>
<p>Due to the SD card code being rewritten, a few of the defaults have changed as well. Logically, it made no sense that the old SD card <em>default</em> path was inside of the Wii NAND and this gave us a good excuse to finally fix it. While this update won't <em>override</em> existing paths, all new users will have SD card paths moved into the "Load" folder along with other things like texture packs. In new builds, the default sd.raw name has also been changed to WiiSD.raw.</p>
<p>For those of you on Android, there is some good news and bad news. The good news is that this feature has been ported over by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> in <a href="https://dolphin-emu.org/download/dev/master/5.0-16970/">5.0-16970</a>. It works the same as in desktop builds with one exception, which is the bad news. Due to <a href="https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/#50-15438-android-comply-with-scoped-storage-requirements-by-josjuice">Scoped Storage</a>, we cannot let you customize the SD folder location and accessing Dolphin's app data locations may be annoying. On most Android devices, the easiest way to do this would be by connecting it to a desktop and manually accessing the displayed directories for your device.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/androidsdfolder.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/androidsdfolder_thumb.png"></a>
<figcaption>While not ideal, SD Card editing for Android users is now simpler than it was before.</figcaption>
</figure>
</div>
<h4 id="50-16901-flush-command-buffers-after-multiple-efb-copies-by-tellowkrinkle"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16901/">5.0-16901 - Flush command buffers after multiple EFB copies</a></strong> by <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong><a class="headerlink" href="#50-16901-flush-command-buffers-after-multiple-efb-copies-by-tellowkrinkle" title="Permanent link">¶</a></h4>
<p>While working on graphics, <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> spotted a flaw with how <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/">Deferred EFB Copies</a> were working in Dolphin. </p>
<p>As a reminder on what this is, the GameCube and Wii use a unified memory model, where the CPU and GPU can edit eachother's memory at any point with no performance cost. However, Dolphin runs on split memory model systems where the CPU and GPU cannot access eachother's memory easily. To emulate the unified memory model, Dolphin duplicates the GC/Wii Main Memory on both the host's system memory and the host's GPU vram, and we sync any changes across both memory pools. This syncing is very costly, and it is why games that require Store EFB Copies to Texture and RAM are so demanding. Deferred EFB Copies is as an optimization to this process. Rather than syncing every single time the game changes something in memory, Deferred EFB Copies delays EFB Copies to the host system memory so it can batch many EFB Copies to RAM together for a sizable performance boost.</p>
<p>Unfortunately, an oversight in the implementation limited the performance boost this option could give.</p>
<p>When using Deferred EFB Copies, there was a system set up to not flush command buffers if multiple EFB copies were issued in succession, but it only ever checked whether it needed to flush when an EFB copy was issued. <strong><a href="https://github.com/TellowKrinkle">TellowKrinkle</a></strong> noticed that if a game is using a lot of EFB Copies in quick succession, Dolphin doesn't check to see if they need to be flushed <em>during</em> this burst of EFB copies. <em>Not flushing</em> for each EFB copy and then flushing at the end would normally be faster, but Dolphin was waiting far too long after the burst of EFB copies to actually start checking if things needed to be flushed, causing a sizeable drop in performance when the flush and GPU <-> CPU synchronization finally happened.</p>
<p>This is a rather <em>particular</em> scenario that shouldn't be that common, but one of the games that <em>do</em> hit this issue is rather demanding, making this a big optimization: <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_3:_Corruption_(Wii)">Metroid Prime 3</a>.</p>
<p><br/>
<script>
addChart({"title":{"text":"Deferred EFB Copies - EFB Flush"},"subtitle":{"text":"Metroid Prime 3 Elysia Vista | Single Core, 4x Native | Intel i9-9980HK, AMD Radeon Pro 5600M"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"series":[{"name":"Before","turboThreshold":0},{"name":"After","turboThreshold":0}],"data":{"csv":"\"null\";\"Before\";\"After\"\n\"macOS MoltenVK\";44;48\n\"macOS Metal\";53;59\n\"macOS OpenGL\";45;49\n\"Windows D3D11\";56;60\n\"Windows D3D12\";55;63\n\"Windows Vulkan\";55;60\n\"Windows OpenGL\";47;49","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"tickInterval":15,"labels":{}},"pane":{"background":[]},"responsive":{"rules":[]},"colors":["#ff3100","#006eff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<h4 id="50-16926-accurately-handle-the-copy-filter-and-gamma-for-efb-and-xfb-copies-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16926/">5.0-16926 - Accurately Handle the Copy Filter and Gamma for EFB and XFB copies</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-16926-accurately-handle-the-copy-filter-and-gamma-for-efb-and-xfb-copies-by-pokechu22" title="Permanent link">¶</a></h4>
<p>In a finale to the crazy <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> <a href="https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/#50-15484-also-use-copy-filter-for-efb-copies-by-pokechu22">pink tinting issues</a>, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> has made the necessary changes to fix the remaining imperfections with color handling. While it's not as dramatic as the original issue, some of the colors of various objects were still wrong in Dolphin due to differences in rounding and some weird overflow behaviors that were left unemulated.</p>
<p>With this added, <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> now renders perfectly in Dolphin this plus Manual Texture Sampling. Quite a difference from just a year ago.</p>
<h4 id="50-16838-add-hle-broadband-device-by-schthack-and-many-additional-fixes-by-sepalani"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16838/">5.0-16838 - Add HLE Broadband Device</a></strong> by <strong><a href="https://github.com/schthack">schthack</a></strong> and <em>many</em> additional fixes by <strong><a href="https://github.com/sepalani">sepalani</a></strong><a class="headerlink" href="#50-16838-add-hle-broadband-device-by-schthack-and-many-additional-fixes-by-sepalani" title="Permanent link">¶</a></h4>
<p>The GameCube Broadband Adapter (BBA) is another of those "What Ifs" of potential that hit the GameCube. Much like <a href="https://dolphin-emu.org/blog/2021/07/21/integrated-gba/">GBA connectivity</a> there was a lot of potential for great things with the GameCube BBA, but very few games truly took advantage of it. In fact, there are only <strong>six</strong> total games that can use the Broadband Adapter <em>for gameplay</em>.</p>
<ul>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Phantasy_Star_Online_Episode_I_%26_II">Phantasy Star Online I and II (and I and II+)</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Phantasy_Star_Online_Episode_III:_C.A.R.D._Revolution">Phantasy Star Online III: Card Revolution</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart: Double Dash!!</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=1080%C2%B0_Avalanche">1080° Snowboarding Avalanche</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Homeland">Homeland</a></strong> (JP Exclusive)</li>
</ul>
<p>Not all of these were created equal, however. Only the two <a href="https://wiki.dolphin-emu.org/index.php?title=Phantasy_Star_Online_Episode_I_%26_II">Phantasy Star Online games</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Homeland">Homeland</a> supported true online play. All the others only supported local play via LAN (local area network). Much like <a href="https://dolphin-emu.org/blog/2021/07/21/integrated-gba/">GBA connectivity</a>, the feature saw limited use simply because of the expenses and setup required. For an eight kart game of <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart: Double Dash!!</a> with everyone getting their own T.V. you'd need:</p>
<ul>
<li>Eight GameCubes</li>
<li>Eight T.V.s</li>
<li>Eight Controllers (16 if you want two players per kart!)</li>
<li>Eight Copies of Mario Kart: Double Dash!!</li>
<li>Eight BBAs</li>
<li>Networking cables and ethernet switches capable of handling this mess</li>
</ul>
<p>Unlike Mario Kart DS, where people could just pull out their own DS out of their pocket and be in the game in minutes, setting up for GameCube LAN games was a huge endeavor. For games like <a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a> it was hard to justify the cost and setup when the split-screen option afforded identical features with the only downside being less screen real-estate and your opponents being able to see your screen.</p>
<p>Emulation didn't really make things easier or better. If you were willing to go through the daunting setup of creating a TAP adapter on your computer, it was possible to link emulators together. But due to Windows doing <em>Windows things</em>, this was mostly limited to running all of the instances on the same computer. This mostly defeats the point of BBA entirely! On Linux it was a lot easier, but it was still a lot more trouble than it was worth to get working.</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/BBA1.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/BBA1_thumb.jpg"></a>
<figcaption></figcaption>
</figure>
</div>
<p>This is where <strong><a href="https://github.com/schthack">schthack</a></strong> comes in. For those that have been in the GameCube community for a long time, that name may seem familiar because of <a href="https://schtserv.com/">schtserv</a>, <strong><a href="https://github.com/schthack">schthack</a></strong>'s <a href="https://wiki.dolphin-emu.org/index.php?title=Phantasy_Star_Online_Episode_I_%26_II">Phantasy Star Online I and II</a> replacement server that's been keeping the game's online service alive for many, many years.</p>
<p>While Dolphin technically could connect to <a href="https://schtserv.com/">schtserv</a>, it was a less than ideal setup due to how difficult it was to setup on Windows and how fragile it was. While the <a href="https://dolphin-emu.org/blog/2020/07/05/dolphin-progress-report-may-and-june-2020/#50-12233-broadband-adapter-support-for-xlink-kai-by-crunchbite">XLink Kai BBA</a> option avoided the need for a TAP adapter entirely, it required its own service through <a href="https://www.teamxlink.co.uk/">XLink Kai</a> and is primarily used for tunneling LAN games through the internet, like Project Warp Pipe once did during the early days of the GameCube.</p>
<p>Dolphin's BBA emulation was mostly low level (LLE) and functioned very similar to how it worked on console. However, because of how exactly it behaved, it did not work on Windows without a TAP adapter, and didn't work on Android at all. On Unix based operating systems, you'd still have to go through setup with OpenVPN and virtual interfaces, making it quite a process regardless of your choice. In order to make things easier, Dolphin would have to translate what the BBA was doing to something that would immediately work on the host device's network. What we needed was an high level (HLE) solution, and <strong><a href="https://github.com/schthack">schthack</a></strong> wanted to make it happen.</p>
<p>Getting it working was one thing, but actually cleaning up Dolphin's ancient BBA code was another. In fact, Dolphin's LLE BBA implementation originated from documentation from <a href="http://whinecube.emulation64.com/">Whinecube</a>, a rival GameCube emulator that ceased development back in 2006. The documentation (and implementation based off of it) were rock solid enough that it's remained almost untouched since it was implemented. Unfortunately for <strong><a href="https://github.com/schthack">schthack</a></strong>, that also meant that some of the code needed to be modernized for modern Dolphin. Thankfully, <strong><a href="https://github.com/sepalani">sepalani</a></strong>, another network engineer, was available to help harden the networking code. The initial results were astounding.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/bbasetup.jpeg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/bbasetup_thumb.jpg"></a>
<figcaption>A GameCube, a Wii via Nintendont, and Dolphin all connected through BBA!</figcaption>
</figure>
</div>
<p>That isn't to say things were perfect - getting all of the Dolphin instances to detect each other can be a bit annoying, especially on Windows. Cause Windows things. Thankfully, <strong><a href="https://github.com/sepalani">sepalani</a></strong> has continued to improve the HLE Broadband Adapter with a myriad of fixes. While sometimes there are occasionally still detection issues, especially when dealing with real hardware, usually any combination of Dolphin, GameCubes, and Wiis (running BBA emulation through Nintendont) can be connected together with enough dedication.</p>
<p>As a note, there are some limitations with one of the games that has nothing to do with the networking code. <a href="https://wiki.dolphin-emu.org/index.php?title=1080%C2%B0_Avalanche">1080° Avalanche</a> is not compatible when playing against physical hardware. There is some kind of miscalculation in the physics that causes Dolphin instances to desync, ruining the session. While this bug has not been fixed as of this beta, there was originally a <em>second</em> bug involving AArch64 devices, causing them to desync with x86-64 devices! <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> quickly quelled that bug, meaning that theoretically even Android users could join in on the BBA fun... if they had BBA...</p>
<h4 id="50-16950-and-50-16967-android-add-xlinkkai-broadband-adapter-and-hle-broadband-adapter-options-to-gui-by-codedwrench-and-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16950/">5.0-16950</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16967/">5.0-16967</a></strong> - <strong>Android: Add XLinkKai Broadband Adapter and HLE Broadband Adapter Options to GUI</strong> by <strong><a href="https://github.com/codedwrench">codedwrench</a></strong> and <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-16950-and-50-16967-android-add-xlinkkai-broadband-adapter-and-hle-broadband-adapter-options-to-gui-by-codedwrench-and-josjuice" title="Permanent link">¶</a></h4>
<p>If you didn't catch it, Dolphin on Android now has access to Gamecube Broadband Adapters! Thanks to work by <strong><a href="https://github.com/codedwrench">codedwrench</a></strong> to add the XLink Kai BBA option to port everything over to the Android GUI, users now can easily access the settings. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> took that framework and ported that over to support the HLE Broadband device.</p>
<p>This means that GameCube LAN play is now in the palm of your hands. A group of friends (with exceedingly powerful phones/tablets) can now just make sure they're on the same network, select a BBA option, and instantly be able to play any of the LAN supported games against eachother. </p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/void.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/void.png"></a>
<figcaption>This is where the photo of our friends meeting together for an Android BBA session would be, if, well, you know.</figcaption>
</figure>
</div>
<p>Sure, it's limited to just <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC,">Mario Kart: Double Dash!!</a> <a href="https://wiki.dolphin-emu.org/index.php?title=1080%C2%B0_Avalanche">1080 Snowboarding: Avalanche</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a>, but that's fun in and of itself. If you can't gather everyone together but live nearby, setting up XLink Kai might be able to get you playing anyway. Note that these games have a fairly low latency tolerance, so we do recommend being on the same network if possible.</p>
<p>If you're looking to get your fix on for Phantasy Star Online I and II, the Android HLE BBA works the same way as the desktop HLE BBA.</p>
<h4 id="50-16991-dsp-hle-implement-support-for-libaesnd-microcode-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16991/">5.0-16991 - DSP-HLE - Implement Support for Libaesnd Microcode</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-16991-dsp-hle-implement-support-for-libaesnd-microcode-by-pokechu22" title="Permanent link">¶</a></h4>
<p>If you use a lot of homebrew in Dolphin, you're probably someone who commonly swaps over to LLE audio. This is because a lot of Homebrew use special homebrew DSP microcodes called libasnd and libaesnd. Dolphin's DSP-HLE had no way to handle these microcodes!</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/libasndpopup.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/libasndpopup.png"></a>
<figcaption>This popup means you aren't getting audio unless you swap to DSP-LLE.</figcaption>
</figure>
</div>
<p>Feeling a bit of deja vu? Same here. This is the <a href="https://dolphin-emu.org/blog/2022/07/07/dolphin-progress-report-may-and-june-2022/#50-16730-add-hle-version-of-libasnd-by-pokechu22">same change as last Report</a> except this time it's tackling <strong>libaesnd</strong> instead of <strong>libasnd</strong> along with a few more edge cases that cropped up over the years.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/eduke32.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-august/eduke32_thumb.jpg"></a>
<figcaption>This is the Duke Nukem game you've been waiting forever on, right?</figcaption>
</figure>
</div>
<p>With this, most major homebrew should be supported in DSP-HLE. There may be exceptions, and some homebrew may opt to create their own microcodes. In those edge-cases, DSP-LLE will always be there to cover the holes.</p>
<h4 id="50-17132-implement-support-for-nfs-files-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-17132/">5.0-17132 - Implement Support for NFS files</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-17132-implement-support-for-nfs-files-by-josjuice" title="Permanent link">¶</a></h4>
<p>For preservationists and those users who have bought Wii titles from the Wii U eshop, this is a rather important update. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has added direct support for the NFS file format that Wii games are distributed in on the Wii U eshop. Given that the Wii U eshop is going to end the ability to purchase new titles, your days are numbered on how long you can purchase these digital copies. For a full list of games available via the Wii U eshop, please check out <a href="https://en.m.wikipedia.org/wiki/List_of_Wii_games_on_Wii_U_eShop">this link</a>.</p>
<p>While this list is fairly limited, given the price spikes of physical copies, this may be the cheapest way to get some of your favorite Wii games until the shop goes down.</p>
<p>As for the NFS format? There really isn't much interesting about it. It's a lossy format that removes garbage data. Adding support for it was not very difficult, and was mainly done for users wanting to test/use Wii U eshop dumps more easily.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2022-07-01&to=2022-08-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-16795/">5.0-16795</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-17269/">5.0-17269</a>! </p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: May and June 2022
2022-07-07T11:41:26+00:002022-07-07T12:29:08.884149+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2022/07/07/dolphin-progress-report-may-and-june-2022/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/progressreportheader-may2022.jpg"/>
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/progressreportheader-may2022mini.jpg" />
</header>
<p>It's been a very hectic two months. Dolphin's development builds <a href="https://dolphin-emu.org/blog/2022/06/09/leaving-a-legend/">officially dropped support for Windows 7, Windows 8, and Windows 8.1</a> in <a href="https://dolphin-emu.org/download/dev/master/5.0-16393/">5.0-16393</a> when the Windows buildbots were updated to use Qt6. If you read the last <a href="https://dolphin-emu.org/blog/2022/05/17/dolphin-progress-report-february-march-and-april-2022/">Progress Report</a>, you'd know that Windows 7 was already on shaky terms due to rampant breakages, but it was Qt6 that finally ended the legacy operating systems. We wrote an entire article about this, so be sure to read that <a href="https://dolphin-emu.org/blog/2022/06/09/leaving-a-legend/">here</a> if you haven't already.</p>
<p>But with loss, some new has also come. We now have a new builder for Windows on ARM! Dolphin has supported Windows on ARM <a href="https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-report-dec-2019-and-jan-2020/#50-11409-platform-support-for-windows-on-arm64-and-50-11455-dolphinqt-support-compiling-on-arm64-by-stenzek">for a couple of years now</a>, but we haven't provided builds due to a lack of prospective users and a lack of space on the buildbot server. But times have changed - the buildbot has seen some upgrades with a new, bigger harddisk and <strong><a href="https://github.com/shuffle2">shuffle2</a></strong> has renovated parts of the infrastructure to make supporting Windows ARM64 builds easier. With those two hurdles out of the way, we've now configured our buildbot to provide Windows ARM64 builds on our <a href="https://dolphin-emu.org/download/">Downloads</a> page. We're not exactly sure how much use these builds will get, but we're hopeful for the future of the platform. </p>
<p>But by this point, you're probably as sick of hearing about the gives and takes of supporting various operating systems as we are of writing about them, so let's get to some emulation goodness. We've got some highly technical changes, including a new "Graphics Mod" system that allows modders and users to create graphical mods. If you're into the <em>edge</em> of emulation, we've also seen support for the annoying Datel Loader used for Action Replay discs and a few very odd unlicensed devices without needing an original GameCube BIOS or swapping to DSP-LLE. This is somewhat significant for reasons we'll get into later, because using <em>real</em> Action Replay discs does make a difference!</p>
<p>For those who love creative homebrew, we've also added support for the homebrew libasnd microcode to HLE audio, meaning that you no longer need to switch to LLE audio for many homebrew titles. We go into the details of all of this and more on this Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-16763-add-graphics-mod-infrastructure-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16763/">5.0-16763 - Add 'Graphics Mod' Infrastructure</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-16763-add-graphics-mod-infrastructure-by-iwubcode" title="Permanent link">¶</a></h4>
<p>Dolphin's current suite to modify the graphics of games is quite limited. All that we have are post processing shaders with no access to depth or any other fancy features. While things like Texture Packs give some freedom, a lot of players have turned to forks and third party programs in order to make larger graphical overhauls. This situation is due to the fact that post-processing has a fundamental limitation - it's done <em>after</em> the frame is rendered. This approach seriously hinders the goal of modifying the game's visuals. For example, if the game crushes its depth during the rendering process, all post-processing sees is a 2D frame. How are we supposed to apply post-processing effects with depth to this? That exact scenario is sadly extremely common on the GameCube and Wii, and why Dolphin's post-processing excludes depth - it was so unreliable that we decided it be better to not have it.</p>
<p>While most users are probably waiting for our Post Processing system to be rewritten, <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has sneakily been working on a different approach, one that addresses that fundamental limitation in post-processing. The first piece of the puzzle has arrived in the form of a feature called <em>Graphics Mods</em>!</p>
<p>Graphics Mods gives users a way to hook into the game's rendering pipeline and directly modify game assets during the rendering process. It exists as something inbetween post-processing and game modding - it is specific like game modding, but like post-processing it doesn't require the daunting task of learning PowerPC assembly to order to create a game patch. Right now, the feature is in its infancy, but it's already shown a ton of promise in allowing quality of life mods to many games. </p>
<p>These are composed of two parts: an "action" and a "target" group. The action contains what the mod will do with the target, such as a "skip" to prevent the target from rendering, and can be generic. The target is specific, <em>extremely</em> specific, as it defines the precise texture, texture format or EFB Copy format we wish to modify. The target group can have a single target or many targets depending on what the modder wants to do.</p>
<p>This may all sound complicated, but in actual application it is extremely simple. To give an example of what Graphics Mods can do, lets look at <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a> on Dolphin without enabling any Graphics Mods.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smgnativeenlarged.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smgnative_thumb.jpg" /></a>
<figcaption>Super Mario Galaxy's bloom effects look fine at native resolution.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xdefaultbloom.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xdefaultbloom_thumb.jpg" /></a>
<figcaption>At higher resolutions, the bloom becomes <span style="white-space: nowrap;">✧・゚: * <em>sparkly</em> * :・゚✧</span></figcaption>
</figure>
</div>
</div>
<p>But with the power of "Native Bloom" and "No Bloom" Graphics Mods, we can transform how the game looks by directly changing how the game renders!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xnativebloom.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xnativebloom_thumb.jpg" /></a>
<figcaption>By scaling the bloom back down, the 'Native Bloom' Graphics Mod restores the game to a more authentic look at higher resolutions.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xnobloom.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/smg4xnobloom_thumb.jpg" /></a>
<figcaption>If you prefer to use third party bloom or just don't want bloom at all, the 'No Bloom' Graphics Mod completely removes the game's built-in bloom effect.</figcaption>
</figure>
</div>
</div>
<p>The Graphics Mods feature installs hooks into Dolphin's graphics pipeline. This can have a slight cost to performance, so Graphics Mods must be enabled to be used.</p>
<p>For the feature's debut, the following titles have Graphics Mods:</p>
<ul>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Arc_Rise_Fantasia">Arc Rise Fantasia</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Battalion_Wars_2">Battalion Wars 2</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Donkey_Kong_Country_Returns">Donkey Kong Country Returns</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Fragile_Dreams:_Farewell_Ruins_of_the_Moon">Fragile Dreams - Farewell Ruins of the Moon</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=House_of_the_Dead:_Overkill">The House of the Dead: Overkill</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=The_Last_Story">The Last Story</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Link%27s_Crossbow_Training">Link's Crossbow Training</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Little_King%27s_Story">Little King's Story</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Monster_Hunter_Tri">Monster Hunter Tri</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Nights:_Journey_of_Dreams">Nights: Journey Into Dreams</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=%C5%8Ckami">Okami</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Strikers_Charged">Mario Strikers: Charged</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=The_Conduit">The Conduit</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess_(Wii)">The Legend of Zelda: Twilight Princess</a></strong> - Wii version only currently</li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">The Legend of Zelda: Skyward Sword</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Play">Wii Play</a></strong></li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Xenoblade_Chronicles">Xenoblade Chronicles</a></strong></li>
</ul>
<p>These mods mostly consist of Bloom definitions, with a few games having definitions for removing GUI elements. However, Graphics Mods aren't limited to just generic operations like that, they have a set of actions that can be defined to create a multitude of effects, and users are encouraged to create their own Graphics Mods through the actions available.</p>
<ul>
<li><strong>Skip</strong>: Allows the modder to skip rendering this target group.</li>
<li><strong>Scale</strong>: Allows the user to scale/stretch a target group.</li>
<li><strong>Move</strong>: Allows a user to move a particular target group.</li>
</ul>
<p>However, we cannot stress enough that the system is still very early in this initial release and there is a chance that some textures and effects may be reused for multiple things. An example of this is Depth of Field and Bloom sometimes using the same efb copy format, meaning that changing one without changing the other may prove difficult in certain games.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/gmodgui.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/gmodgui.png"></a>
<figcaption>Graphics Mods for supported titles will be in the Game Properties page under the "Graphics Mod" tab.</figcaption>
</figure>
</div>
<p>If you're interested in creating your own Graphics Mods, we'll be maintaining <a href="https://wiki.dolphin-emu.org/index.php?title=Graphics_Mods">a Graphics Mod guide on the Dolphin Wiki</a> that should stay up to date as the feature evolves.</p>
<p><strong>Future Plans</strong></p>
<p><strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has many grand plans to renovate Dolphin's ability to enhance graphics. From post-processing to Graphics Mods, they've got <em>a lot</em> up the pipeline. But if anything was going to get merged, that meant breaking down their projects into smaller pieces. This is just a <em>taste</em> of what Graphics Mods can do, and we can promise that there is more coming in the future. This is a massive undertaking being powered by a single person, so for now things are very barebones on purpose. It was a necessary evil to scale things back so that the system itself could be reviewed and merged.</p>
<p>One issue is Android. While there is nothing stopping Graphics Mods from working on Android, at this point it has not been implemented into the Android GUI. The Android GUI is a bit of a pain to develop for, and not every developer has an interest in dealing with the JNI parts of Dolphin. In fact, no one <em>wants</em> to do it, it's just that some end up <em>having</em> to do it.</p>
<p>As this feature sees more use, we hope to include more Graphics Mods across many titles in Dolphin. If any other creators want to submit their Graphics Mods to be available in the emulator, they can be submitted as Pull Requests.</p>
<h4 id="50-16448-fix-some-dual-core-full-screen-panic-alert-deadlocks-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16448/">5.0-16448 - Fix Some Dual Core + Full Screen + Panic Alert Deadlocks</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-16448-fix-some-dual-core-full-screen-panic-alert-deadlocks-by-josjuice" title="Permanent link">¶</a></h4>
<p>Modern consoles have many cores and do tons of thread management. That's something we're thankful we don't have to worry about emulating, as the GameCube and Wii are from a bygone era of single core processors and games that run directly on bare metal.</p>
<p>But if the GameCube and Wii are <em>Single Core</em> devices, what does Dolphin's Dual Core mode actually do? Most users seem to think that it splits CPU emulation onto multiple threads, and ask why we can't just split it even further to use even more cores. But that's not what it does.</p>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:35%; min-width:72px; float:right; text-align:center;">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/gamecubecpu.jpg"><img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/gamecubecpu.jpg"></a>
</div>
<p>Dual Core is actually moving <em>GPU</em> related CPU tasks onto a separate core. The CPU has to do a lot of work figuring out what to render, handling the Vertex Loader, mipmaps, and other things. This "GPU thread" basically does all the legwork to figure out the GPU commands for what your GPU will then have to render. Because the GPU thread and the CPU thread are almost <em>all</em> of the major work that Dolphin does on a typical configuration, splitting them up can theoretically give <em>up to 100%</em> faster performance depending on the game. </p>
<p>This was <em>essential</em> in Dolphin's early days. Back then, both Dolphin's CPU JIT and the CPUs we'd be running it on were <em>significantly</em> slower than today. Twelve years ago, hundreds of games were too demanding to run fullspeed <em>on the fastest computers in the world</em>. It was a community effort in those days to buy the latest processors and overclock the hell out of them to see what games were now fullspeed on the bleeding edge. In the face of this incredible struggle, developers were willing to cut a few corners in order to make things faster. Dual Core's design is a result of that.</p>
<p>Dual Core relies on the fact that the CPU and GPU threads can do some of their work in parallel without having to interact. If everything goes well, they both run at full speed and don't drift too far apart. Then, when an action that requires the CPU/GPU to communicate is <strong>detected</strong>, they can sync up without any major issues. The more that things can run in parallel, the more efficient that Dual Core is, so it syncs <em>as little as possible</em> in order to get the massive performance gains that it gives.</p>
<p>However, in recent years Dual Core has drawn more and more ire for causing random bugs and crashes across a lot of popular games. But it wasn't <em>always</em> this problematic. Something changed along the way that has exasperated the core problem of Dual Core...</p>
<p>What exactly happened?</p>
<p>After Dolphin 4.0, something <em>flipped</em> that no one in the early days of Dolphin's development could have predicted. With the advent of <a href="https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/">TEV Fixes New</a> and a huge slate of massive JIT optimizations, we actually made it so that the <em>GPU thread</em> was now the bottleneck most of the time!</p>
<p>This turned Dual Core into a much more unstable beast, as a sudden spike that causes the GPU thread to fall too far behind can cause bad data to be executed (unknown opcodes), visual errors, shaky geometry, spiky polygons, and more!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/battalionwars2.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/battalionwars2_thumb.jpg"></a>
<figcaption>A handful of games were the opposite and actually struggled with the GPU thread overrunning the CPU thread, and those have benefitted.</figcaption>
</figure>
</div>
<p>Since Dual Core has become more unstable, there have been a lot of efforts to fix it, but we've ran into a rather difficult conundrum. If we fix the core problem - the fact we allow the GPU and CPU threads to run apart - we lose the performance gains of Dual Core. Fake-completion, a method used for netplay to make Dual Core more deterministic, only works in around half of the library and is roughly 20% slower. It's great for netplay in the games it supports, but not really viable as a general option. SyncGPU, a setting that forces the CPU and GPU thread to synchronize every so many cycles, often ends up slower than Single Core due to thread synchronization overhead and still has some of the same issues as Dual Core.</p>
<p>We've come to the conclusion that fixing Dual Core within the existing design just isn't on the table. If you can't run the game on Single Core, and the game relies on tighter CPU/GPU synchronization, you just have to deal with the occasional unknown opcodes, weird graphical oddities, and the occasional crash.</p>
<p>This pull request <em>doesn't</em> fix any of that, but it does fix something that was making it even worse. A bug in Dolphin's GUI system on desktops was causing popups from the GPU thread to lockup Dolphin <em>if</em> the game was in exclusive fullscreen. Because Dual Core's behaviors can cause various assertions from the GPU thread, this meant that previously non-fatal popups would essentially deadlock the emulator. The only advice we could give users was to disable panic handlers while in full-screen because Dual Core is occasionally going to mess up.</p>
<p>Thankfully, the panic handler issue has finally been stopped. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> introduced a small tweak to the way popups from the GPU thread are handled in order to make sure they do not deadlock when in Full Screen. It's a rather messy solution, but Dual Core itself is messy problem. </p>
<p>This should fix the annoying "Unknown" blank popups that have been stopping people's games when running in Full Screen. If these popups were trying to tell you that a fatal error has happened, then the game might still crash. But if it's just a harmless Unknown Opcode, you might be able to continue.</p>
<h4 id="50-16443-implement-pi-fifo-reset-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16443/">5.0-16443 - Implement PI FIFO Reset</a></strong> by <strong><a href="https://github.com/pokechu22">pokechu22</a></strong><a class="headerlink" href="#50-16443-implement-pi-fifo-reset-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Speaking of annoying unknown opcode popups, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> investigated a case where Dolphin could erroneously execute bad data after a game called the command for a FIFO RESET.</p>
<p>In normal gameplay, you aren't going to see this command very often. In fact, the most common place we've seen this issue reported is from <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">The Legend of Zelda: Ocarina of Time (VC)</a>. This is because randomizer players would abuse soft resets to test particular item checks and use save/quit into reset to quickly travel to specific areas. Randomly during these resets, the data past the FIFO RESET would contain invalid data, which triggered the unknown opcodes.</p>
<p><strong><a href="https://github.com/pokechu22">pokechu22</a></strong> investigated a similar case found in a demo disc that used FIFO RESET between games and menus and found that any data leftover <em>past</em> a FIFO RESET was thrown out. As such, we now throw out any commands immediately following a FIFO RESET before things are reinitialized.</p>
<h4 id="50-16722-and-50-16737-fix-hle-audio-and-hle-boot-of-datel-titles-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16722/">5.0-16722</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16737/">5.0-16737</a></strong> - <strong>Fix HLE audio and HLE boot of Datel Titles</strong> by <strong><a href="https://github.com/pokechu22">pokechu22</a></strong><a class="headerlink" href="#50-16722-and-50-16737-fix-hle-audio-and-hle-boot-of-datel-titles-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Let's be honest here. In the past, booting Datel titles in Dolphin was a pain in the ass. It required both DSP-LLE <em>and</em> an original GameCube BIOS. Otherwise, they would simply hang and/or lock up Dolphin. And when that happens, your settings would likely get reset when Dolphin crashed and then you'd have to figure out what you forgot to change and the cycle continues.</p>
<p>You may wonder: "<em>Why would I want to boot a Datel title in an emulator? All Datel did was make a bunch of unlicensed products, right?</em>" While their stuff may not have been of the highest budget and quality, they did make some rather interesting and useful products. The Advance Game Port allowed you to play Game Boy Advance games on the GameCube through a <strong>GBA Emulator</strong> which loaded real cartridges through a Memory Card expansion device. But, Datel is more commonly known on the GameCube for their slew of Action Replay releases, Freeloader discs, and their weird Max Drive gigantic memory cards.</p>
<p>This brings us to a rather <em>weird</em> point. The Gecko Code loader is free open source software, which allows Dolphin to directly use the same Gecko Code Loader that is used on console. Thanks to that, our Gecko code support is nearly 1:1 with console. However, Datel's Action Replay loader is closed source and protected by copyright, and we cannot include it. So Dolphin uses a reversed engineered cheat code loader for Action Replay codes. While Datel's codes <em>should</em> be able to produce near identical results in Dolphin, it's very obvious that our Action Replay cheat loader is fairly inaccurate in some respects. For example, the "Hold R to Mega Jump" Action Replay code in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a> only works when using a real Action Replay disc to initialize the code.</p>
<div class="media-block narrow">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/arcodelle.mp4" type="video/mp4"/>
</video></div>
<figcaption>We were going to do a comparison, but the code just does nothing with Dolphin's Action Replay loader. So just imagine Link not jumping here. </sub></figcaption>
</figure>
</div>
<p>In an effort to make these unlicensed titles more accessible, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> dug through them to figure out why they didn't work with Dolphin's emulated BS2 (AKA - Skip Main Menu) or with HLE audio. The answers for each were rather interesting.</p>
<p>For the HLE audio issue, the problem was caused by a typo in <em>Datel's</em> code that ended up not mattering on console or DSP-LLE, but completely broke our HLE implementation. Namely, they were supposed to write 0x800 to the DSP control register, which would have started the initialization process. Instead they wrote 0x80, which does absolutely nothing. How exactly did this work on DSP-LLE and real hardware? Well, it didn't, but other data arrived at <em>just</em> the right time just as Datel's initialization code exited. We're not 100% sure why this works, and for once we don't have an overly complicated summary from <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> to rely on yet. All we know is that by improving the timings on DSP-HLE, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> was able to get it working in the same manner that it was on DSP-LLE and console.</p>
<p>Emulated BS2 is our internal name for what users see as "GameCube - Skip Main Menu" in the GUI. If you don't hear that jingle and see that cube before booting a GameCube game, then you're using Dolphin's Emulated BS2. Its job is to make sure that all of the registers and memory are setup correctly as if the Main Menu had run, so that games work the same regardless of if you have the Main Menu dumped from a console or not. Emulated BS2 works so well for most games, that users almost never have to rely on a real Main Menu for compatibility reasons in retail titles.</p>
<p>The reason why Emulated BS2 didn't work with Datel's Loader stemmed from the fact that Datel did <em>way</em> less initialization than actual games. Datel's titles <strong>heavily</strong> relied on the Main Menu to setup almost everything. <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> had to go through various registers <em>and</em> even dive into parts of the graphics code and give them proper default values in order to have the games boot correctly without needing a GameCube Main Menu.</p>
<p>The result of all of this work is that Datel's titles will now boot properly without needing special settings in the latest development builds. However, there are still a lot of problems when using these titles, especially in Action Replay devices that check memory cards. Some Action Replay titles will hang if you have a memory card plugged in on boot. Most Datel titles will throw unknown opcodes as well, and in one rare case in the third Advance Game Port release, enabling MMU will cause the game to crash. </p>
<p>We highly recommend <em>not</em> using GCI Folders with any Datel products that can write to the memory card, especially Advance Game Port's third release, which will actively break things with how it writes Savestates to the memory card. As with any kind of sketchy game (like <a href="https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/?nocr=true#50-15330-raise-program-exceptions-on-floating-point-exceptions-by-josjuicewe">True Crime: New York City</a>) or homebrew that can do unexpected things, please use these titles with caution.</p>
<h4 id="50-16730-add-hle-version-of-libasnd-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16730/">5.0-16730 - Add HLE version of libasnd</a></strong> by <strong><a href="https://github.com/pokechu22">pokechu22</a></strong><a class="headerlink" href="#50-16730-add-hle-version-of-libasnd-by-pokechu22" title="Permanent link">¶</a></h4>
<p>If you use a lot of homebrew in Dolphin, you're probably someone who commonly swaps over to LLE audio. This is because a lot of Homebrew use special <em>homebrew</em> DSP microcodes called libasnd and libaesnd. Dolphin's DSP-HLE had no way to handle these microcodes!</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/libasndpopup.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/libasndpopup.png"></a>
<figcaption>This popup means you aren't getting audio unless you swap to DSP-LLE.</figcaption>
</figure>
</div>
<p>This is because DSP-HLE doesn't actually emulate the DSP hardware, instead it identifies what DSP microcode is running (based on a hash) and directly emulates that microcode without bothering to actually emulate the hardware itself. This is <em>many</em> times faster, to the point where DSP emulation is <em>never</em> a performance bottleneck when using DSP-HLE. Yet in modern builds of Dolphin, DSP-HLE and DSP-LLE have <em>near</em> parity in supported microcodes. Users no longer have to choose between the accurate but demanding DSP-LLE or <a href="https://dolphin-emu.org/blog/2015/08/19/new-era-hle-audio/">old HLE audio</a> that was rife with bugs and only supported a handful of titles well.</p>
<p>Because the GameCube and Wii's retail library is now set, we can be certain that Dolphin's DSP-HLE completely handles those cases with relative accuracy. However, Homebrew (and one demo we found earlier this year!) are the last bastions of unsupported microcodes under DSP-HLE.</p>
<p>And that's the main reason why Dolphin's DSP-HLE hasn't worked for a lot of homebrew. A lot of homebrew uses the libasnd and libaesnd microcodes, which were under active development during most of Dolphin's development life. Writing support for something that could change at any moment seemed silly, but at this point development on the homebrew microcodes seem to have mostly stabilized. The last changes occurred in 2020, and they were minor changes at that.</p>
<p>As part of making homebrew in Dolphin more accessible, it seemed natural to finally add support for the libasnd and libaesnd microcodes that they use. And because they're a part of libogc and open source, adding support for them was far easier than it was figuring out all the crazy behaviors present in various AX and Zelda microcodes! In fact, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> implemented the libasnd microcode used in most homebrew <em>on the side</em> while working on other audio things.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/newoescape.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/newoescape_thumb.jpg"></a>
<figcaption>Play tons of homebrew without needing LLE audio! This is <a href="https://wiibrew.org/wiki/Newo_Escape">Newo Escape</a>, a flight homebrew game that previously played no audio on DSP-HLE.</figcaption>
</figure>
</div>
<p>Some homebrew that use the slightly more complicated liba<strong>e</strong>snd still require LLE audio as of this Progress Report, but work on changing that is already underway.</p>
<h3 id="dev-diary-solving-the-mystery-of-monster-house"><strong>Dev Diary - Solving the Mystery of Monster House</strong><a class="headerlink" href="#dev-diary-solving-the-mystery-of-monster-house" title="Permanent link">¶</a></h3>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> is a game that has been problematic in Dolphin for a very long time. It's right in that zone where it's not <em>popular</em> enough to see a lot of attention, but not <em>awful</em> enough to draw a lot of morbid curiosity. It's a servicable game that falls apart in the final act.</p>
<p>There have been reports that <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> is a cursed game, and is simply unbeatable in Dolphin. Invalid read errors would chase away prospective users looking to sneak into the depths of this seemingly haunted labyrinth. Every time we've taken a glance at this title, it has looked like nothing else but a normal game with no noticeable issues. But again and again on the issue tracker and wiki, another soul would be lost to these mysterious crashes.</p>
<p>After many years of avoiding the eyesore, it was time to send someone in for real. Someone to get to the bottom of <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> and find out the truth.</p>
<p>Our unwilling volunteer this time around was <strong><a href="https://github.com/JMC47">JMC47</a></strong>. He was a skeptic that there would be anything special with this particular game and rolled his eyes at the request. We sent him in anyway and armed him with a squirt gun, some savestates, and a cheatcode to refill health. He should have been completely safe with those tools. Should have. Unfortunately, we lost contact soon after he entered the house. All that we could find were these log files of his exploits.</p>
<hr />
<p><strong>Testers Log - Day 1</strong></p>
<p>I've seen <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> reported a couple of times over the years and bought the game probably over half a decade ago. I've tried it a few times but upon seeing nothing interesting, I'd always put it on the back burner. This game isn't aggressively bad or maliciously coded, it just seems like a pretty mediocre movie tie-in. Compared to something with crazy issues like <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>, it just seemed like it wasn't worth my time. Yet, supposedly this game still isn't playable. We'll see about that.</p>
<p>The game starts out rather suddenly, with the main cast getting thrown into the <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> with little to no setup. This is apparently a movie tie-in game, so apparently telling the story properly is just optional. At the center of the game are three kids. I will dub them Annoying Child, Sarcastic Girl, and Scared Kid. The gimmick of the game is that these three kids are exploring the <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> armed with different weapons and they are trying to destroy it in order to... I don't know honestly. They just seem to want to destroy it. But is it evil? Having played through the first chapter of the game, I'm not entirely sure.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh1.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh1_thumb.jpg"></a>
<figcaption>These kids will be my company during my foray into the Monster House.</figcaption>
</figure>
</div>
<hr />
<p><strong>Testers Log - Day 2</strong></p>
<p>This game is starting to get on my nerves. Maybe it's because the developers were inexperienced, but I'm constantly ending up going the wrong way in a mostly linear game. The reason for this is rather silly.</p>
<p>When you unlock a door in other games, say a 3D Legend of Zelda game, the developers tend to show you the door you unlocked. The developers of this game have seen this and <em>know</em> that, but it seems like they didn't understand <em>why</em> it works. They show me that I unlocked a door in a close up, but then zip back to my character facing whatever direction I was facing when the cutscene started. Compare this to [Wind Waker], which will keep your camera angled toward the door that you unlocked when you regain control. This is a reoccuring problem in Monster House, especially in hallways where you might unlock a vent that is all the way back near where you came.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh2.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh2_thumb.jpg"></a>
<figcaption>I unlocked a door, but it sure isn't this one.</figcaption>
</figure>
</div>
<p>Does this make it a terrible game? No. The game seems solid enough overall, and I haven't seen any signs of really bad programming that would cause a crash. Maybe all of the users before me were just using bad dumps or cheats that don't work.</p>
<hr />
<p><strong>Testers Log - Day 3</strong></p>
<p>I felt a chill run down my spine. I was crawling through a vent when I heard the horrible ding of invalid reads. I thought the <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> had swallowed me alive. </p>
<p>I held frantically mashed enter to try and break free, fearing my journey was over. In the end, I survived. The last invalid read error was squashed and the game loaded the next area. I let out a sigh of relief, as I had made a fatal error in my complacency.</p>
<p>Logging wasn't enabled this entire time - meaning that if this had been a game crash, I would have lost everything. Thankfully, because the game didn't crash, I was able to save and enable logging and other debugging features. The <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> should have stopped me while it had the chance. Now it's war.</p>
<hr />
<p><strong>Testers Log - Day 4</strong></p>
<p>The game put up a rather spirited fight, but i have emerged victorious. </p>
<p>It tried the same trick on me again with the invalid reads <em>and</em> this time crashed afterwards thinking it would fell me. Fortunately, the damage done was minimal as I had been saving regularly since the initial scare. During this attack, however, the game revealed its weakpoint! In the logs I caught "Stale icache" messages right alongside the invalid reads. <strong>This game is just icache sensitive!</strong></p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh3.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh3_thumb.jpg"></a>
<figcaption>This fireplace would have felled a normal tester, but not me.</figcaption>
</figure>
</div>
<p>If I had been playing this game years ago, perhaps I wouldn't have known what to do. Thankfully, by this point we have <a href="https://github.com/dolphin-emu/dolphin/pull/10739">weapons</a> to fight off such a problem thanks to <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> and the infamous <a href="https://wiki.dolphin-emu.org/index.php?title=Scooby-Doo!_Mystery_Mayhem">Scooby Doo!</a> incident. </p>
<p>Oddly enough, those also dealt with mysteries, haunted houses, and monsters... Oh well. It looks like my job is done here. All I need to do is beat the game and write up a report.</p>
<hr />
<p><strong>Testers Log - Day 5</strong></p>
<p>Despite disabling the icache, I'm still getting invalid read errors every now and then. The game hasn't crashed on me, but this shouldn't be happening. Either the game needs <em>accurate</em> icache emulation or the game has programming bugs that cause invalid reads on console that get skipped by their error handler. In order to verify this myself, I decided to enable MMU emulation.</p>
<p>If the game crashes now, I'll be able to follow a stack trace and figure out exactly <em>where</em> in the game code the problem is happening. From there, if the game is relying on icache behaviors to the point of needing <em>accurate</em> emulation of it, we can just patch the game instead.</p>
<p>After dealing with all of that annoying emulator stuff, the game rewarded me with a rather competently made boss fight. Things are starting to look up after all!</p>
<hr />
<p><strong>Testers Log - Day 6</strong></p>
<p>Apparently the developers couldn't design harder enemies and have just decided to make the game harder by throwing a 30+ enemies into every room. What the hell is their problem? There are so many enemies in these rooms that you can't actually move your character half of the time until you clear them out.</p>
<p>And please, can we stop with all the quicktime events?! These QTEs were annoying in the first half of the game, but there they only cost a tiny amount of health as long as you mashed the failure minigame. Now they cause instant death and reset you to the beginning of the section!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh4.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh4_thumb.jpg"></a>
<figcaption>Better hope you weren't doing something or hitting other buttons when this sudden QTE showed up.</figcaption>
</figure>
</div>
<p>This last section I'm in has been a real doozy. Multiple rooms packed with tons of enemies and areas that lock you in until you clear all the enemies, followed by a boss fight, followed by not one <em>but two</em> instant death QTEs?! Come on. That's more than enough, especially considering that the boss had an instant KO move too, even if it was easy enough to dodge.</p>
<p>At least I'm almost done with this maze. Whenever the story switches characters, the game gives me a checkpoint. I just need to find my way out, and every direction just looks the same. Oh, and there are a bunch of extra dead-ends with nothing but collectable bonuses. And if you dare grab the collectable you spawn more enemies. Thanks! That's just wonderful. </p>
<p>AND ANOTHER INSTANT DEATH QUICKTIME EVENT SPACED JUST FAR ENOUGH OUT THAT I LET MY GUARD DOWN SENDS ME BACK TO BEFORE THE BOSS?! You know what, I'm just going to spam savestates. </p>
<hr />
<p><strong>Testers Log - Day 7</strong></p>
<p>Now the #@&$ing cutscenes have #@&$ing quicktime events in them that if you fail you die, or worse, have to fight the boss again. You can't even rest during the cutscenes. At least I'm almost- What.</p>
<p>This game checks to make sure the memory card you're using matches the memory card the save was created on, and I apparently loaded a savestate from before my last in-game save, so now it thinks the memory card doesn't match. At least it doesn't refuse to save - oh great, the game #@&$ing crashed after saving because it's poorly coded. Now I need to make sure this isn't a Dolphin bug.</p>
<p>And, why exactly are the cutscenes where you <em>get caught</em> to switch characters exactly the same as the QTEs that you <em>can't fail</em> or else you game over? Where is the consistency. And, you know what would be a great idea? Putting a room with a thousand #@&$ing enemies and then have a QTE trigger in the same area is just stupid. And guess what, if you manage to get hit as a QTE loads, the #@&$ button prompt won't show up so you're just dead. GREAT. And the button prompts are randomized, so you can't even use the dodge button or something consistent like that.</p>
<p>It's a horrible conundrum. Killing all the enemies takes forever, so I just want to rush through the rooms. But if I don't kill the enemies, I risk glitching out their precious QTE that instantly kills me if I mess up. This section of the game is literal garbage, and honestly sours everything else.</p>
<p>I was willing to forgive the fact that the annoying #@&$ing kid needed a #@&$ing ladder hook in order to grab a ladder that was clearly at arm's height. I was willing to forgive the fact the game's enemy design had as much variety as a modern sitcom. Hell, I was willing forgive the fact that this "movie tie-in" hadn't actually told me anything about the characters or story!</p>
<p>How come the #@&$ing house can seemingly capture these kids at will and kill them but doesn't. The <em>same exact cutscene</em> where the vent comes down and grabs you during a QTE to kill you is used <em>multiple times</em> to force character swaps, but the kid ends up fine in another section anyway! Why? How come they're fine when that happens but not during the QTE?!</p>
<p>This is literally the the final stretch of the game. I just need to push through and finish it so I can mark the game as playable on the Wiki and forget this ever happened.</p>
<hr />
<p><strong>Testers Log - Day 8</strong></p>
<p>@#&$ing this stupid #@&$ing house in this stupid #@&$ing game. You know, the game has truly made me appreciate that last section of enemy mobs and QTEs. You want to know why? Because at least there was <em>gameplay</em>. This is the second to last chapter of the game, and do you want to know what it is composed of? #@&$ing QTEs! THAT'S IT! THERE'S NO MORE GAMEPLAY!</p>
<p>Okay, so get this. The house is chasing me, and I have a three button quicktime event where every so often I have to hit a button to avoid rubble with one of the three characters. Mess up too many times, and you restart the section. The timings aren't all that tight, but considering how long the section actually lasts, it's rather annoying.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh5.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh5_thumb.jpg"></a>
<figcaption>This goes on forever and ever and ever...</figcaption>
</figure>
</div>
<p>This is just wonderful.</p>
<hr />
<p><strong>Testers Log - Day 9</strong></p>
<p><em>This log has been removed due to excessive profanity.</em></p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh6.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh6_thumb.jpg"></a>
<figcaption>Thankfully the game has mercy if you fail the cutcene QTEs and only make your repeat <i>part</i> of the last section instead of the whole thing. Thanks.</figcaption>
</figure>
</div>
<hr />
<p><strong>Testers Log - Day 10</strong></p>
<p>The #@&$ing chase cutscene is still #@&$ing going. I can't believe it. And on this section you can't make any mistakes because the house has caught up.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh7.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh7_thumb.jpg"></a>
<figcaption>Please just let it end.</figcaption>
</figure>
</div>
<hr />
<p><strong>Testers Log - Day 11</strong></p>
<p>After several minutes of playing the worst version of <em>Simon says</em> I've ever seen, the final boss fight has finally commenced. And considering the quality of the last chapter, it is fitting the final boss is <em>barely</em> gameplay. Rather than using the third person shooter gameplay that the game has established up until this point, we get an incredibly janky vehicle boss fight where we take a crane, approach the house, mash attack, back away... rinse and repeat.</p>
<p>There's no actual variety to the fight. The house has one attack that can be mirrored left or right - an extremely slow swipe followed by a reverse swipe. You just backup to avoid it, and then after the attack get close and mash the attack button to deal a tiny pixel of damage to its health bar. But, don't you dare make a mistake, as if the house so much as <em>grazes</em> your crane, it takes off a huge chunk of your health bar. Just don't be greedy and the fight isn't that bad. You can't really get into a rhythm though because there's yet another randomly occurring #@&$ing QTE during the boss. It's just a simple joystick spin, but unless you use the palm of your hand to spin it extremely fast, you're guaranteed to lose some of your precious life every time. If the QTE comes up too many times, you can lose half of your health. It's worth swapping your hand grip to make sure that doesn't happen, because this fight takes way too long to lose to chip damage.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh8.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh8_thumb.jpg"></a>
<figcaption>You even get random QTEs during this limited mobility boss fight which is barely more gameplay than a quick time event.</figcaption>
</figure>
</div>
<p>The boss's health bar is almost depleted... please... just end... YES! IT'S OVER!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh10.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh10_thumb.jpg"></a>
<figcaption>The house is no more! I am victorious.</figcaption>
</figure>
</div>
<p>After all of that, it's hard to judge <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_House">Monster House</a> because of how <em>hard</em> it relies on quick time events toward the end of the game. The core gameplay isn't <em>bad</em>, and while the developer was inexperienced, they did a decent enough job at varying up the characters, enemies, and their first boss fight was well designed.</p>
<p>It's just that the latter half of the game became such a QTE fest that it was hard to play. And the parts after you get out of the house are almost entirely QTEs! But now we're in the ending cutscene and it's all over-</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh9.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-june/mh9_thumb.jpg"></a>
<figcaption>This #@!&ing prompt happens well over 30 seconds after the boss fight is over and serves no purpose but to cause you pain.</figcaption>
</figure>
</div>
<p>What you want me to <strong>hit buttons</strong> during the end cutscene! NO! #@&$ NO NO #@&$! WHO THE #@&$ PUTS A QUICKTIME EVENT AFTER YOU DEPLETE THE FINAL BOSSES HEALTH BAR WHAT THE #@&$ IS YOUR PROBLEM WHY-</p>
<hr />
<p>Unfortunately, the log cuts off there. The random Savestate/Memory Card Crash never happened a second time, so we were unable to confirm if that was a bug in Dolphin or the game, but we can confirm that the game is now playable from start to finish... if you dare.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2022-05-01&to=2022-07-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-16383/">5.0-16383</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-16793/">5.0-16793</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: February, March, and April 2022
2022-05-17T06:39:12+00:002022-05-19T09:58:47.968642+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2022/05/17/dolphin-progress-report-february-march-and-april-2022/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/progressreportheader-march2022.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/progressreportheader-march2022mini.jpg" />
</header>
<p>After a long wait, the Progress Report is back! This time it wasn't so much from a lack of content, but from a lack of <em>content creators</em>. The past three months had illnesses hit one of our writers and the other had a very challenging move. Even with these major hurdles jumped, we're not even close to 100% yet. It's been a battle to get caught up with all of the big changes to Dolphin the past couple of months and because of that this report is a <em>tad</em> late.</p>
<p>Needless to say, there's only one way to start catching up, and that's to get to digging through the past three months of Notable Changes. Enjoy!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-16380-change-default-nus-shop-url-to-dolphins-fake-nus-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16380/">5.0-16380 - Change default NUS Shop URL to Dolphin's fake NUS</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-16380-change-default-nus-shop-url-to-dolphins-fake-nus-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>On the <a href="https://twitter.com/oatmealdome/status/1504206758213947394">16th of March</a> the Wii Nintendo Update Servers (NUS) abruptly went offline. Without them, Wiis can no longer download previously purchased titles, or download critical files needed for setting up your Wii system. Nintendo refuses to say this is anything more than a temporary maintenance blip, but after two months we're starting to believe that this is a permanent change. To our knowledge, the life-support from the Wii Shop has been pulled and the Nintendo Wii is now an offline console.</p>
<p>While it may not seem like much, NUS was an important tool to casual users, the modding scene, and even Dolphin users. Easy access to official System Files (IOSes) and default channels allowed users to easily setup a clean Wii System that is fully up-to-date without needing a game with a late release date. If you made a mistake on a modded Wii, you could easily access NUS to get clean copies of IOS files to unbrick your system. On Dolphin, it made it so users could get a fully up-to-date Wii System Menu setup, complete with channels, with just a few clicks. For preservation of the Wii experience, NUS made things simple.</p>
<p>More importantly, Wii games <em>require</em> various IOS files in order to run. We've had our run-ins with differences between older IOS behaviors and newer IOS behaviors while wrangling with USB Microphone support. There are lots of games that either won't run, or won't run correctly if they're missing IOSes. The good news is that almost every Wii disc title <em>comes</em> with the necessary IOS files to run that game along with a full Wii System Menu and all the default channels. Whenever you insert a disc into a real Wii, it'll prompt you to update if there is a missing System File. Most Dolphin users won't notice much of a change, as Dolphin has a hack for when a game is launched <em>from the gamelist</em> to ignore missing IOS files. For anything more complicated, IOS files are also required in Dolphin.</p>
<p>This may seem like a minor issue, but since the servers have gone down, there's been a huge uptick in issue reports from Dolphin users, along with an increase in bugs relating to incorrectly configured Wii Systems. A lot of users would simply pull something like that the Mii Channel and the Wii System Menu off of a Wii or a Disc, and think that installing that was enough. But, without the IOSes required to run the Mii Channel, you'll either be greeted with a blackscreen, the system menu rebooting, or a notice that the title could not be launched. Issues like these have been running rampant, and we no longer had an immediate solution that would clean up their issues.</p>
<p>Here's the kicker; Nintendo is still hosting all of these core system files for the Wii, they're still available to download... from the Wii U Content Delivery Network (CDN)! It still has all of the Wii's System Files for some reason. As far as we know, the Wii U's Virtual Wii used the Wii NUS. This isn't exactly unusual for Nintendo, as the 3DS CDN <em>also</em> has the Wii System Files!</p>
<p>Because of this duplication, this gives us an option to extend the life of the "Perform Online System Update" functionality in Dolphin. We now have a <strong>Dolphin</strong> Update Server. <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> created a static page and <strong><a href="https://github.com/delroth">delroth</a></strong> configured the server to act as an intermediary Update Server so that Dolphin can use the Wii U CDN for System Updates. Because the same files are on the Wii U CDN, all of this shuffling should amount to no noticeable change from the previous behavior for our users. <em>Perform Online System Update</em> works just how it did before.</p>
<p>Inevitably, the Wii U and 3DS CDNs will eventually go down, but this should buy us time to develop a more permanent solution for when that happens.</p>
<h4 id="50-16005-remove-mmu-default-in-disney-trio-of-destructiontm-by-jmc47"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16005/">5.0-16005 - Remove MMU Default in <em>Disney Trio of Destruction™</em></a></strong> by <strong><a href="https://github.com/JMC47">JMC47</a></strong><a class="headerlink" href="#50-16005-remove-mmu-default-in-disney-trio-of-destructiontm-by-jmc47" title="Permanent link">¶</a></h4>
<p>During the <a href="https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/">previous Progress Report</a> the blog writers, JMC47 and MayImilae, were discussing <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/#memory-management-unit-emulation">MMU (Memory Management Unit)</a> titles. And this exchange took place.</p>
<p><br/>
<blockquote>
MayImilae: do any wii games use mmu?
<br/>JMC47: yes
<br/>MayImilae: which ones?
<br/>JMC47: <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Cars_2">Cars 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Toy_Story_3">Toy Story 3</a>
<br/>MayImilae: oh right, the anti emulation nonsense
<br/>JMC47: no!
<br/>JMC47: actually one of the devs reached out to us
<br/>JMC47: and <a href=https://forums.dolphin-emu.org/Thread-disney-trio-of-destruction%E2%84%A2>explained that the MMU stuff was <em>not</em> anti-emulation</a>
<br/>JMC47: the dcache stuff was
<br/>JMC47: but not the MMU usage
</blockquote>
<br/></p>
<p><a href="https://github.com/Sonicadvance1">Sonicadvance1</a>, MayImilae's partner, happened to see this conversation by peeking at her laptop. He simply pointed at the screen and said, "That's not MMU." and walked away. These three Disney titles we lovingly call the <a href="https://dolphin-emu.org/blog/2017/02/01/dolphin-progress-report-january-2017/#50-2204-hack-to-protect-lower-mem1-from-malicious-game-code-by-booto">Disney Trio of Destruction™</a> had MMU enabled on by default, as without full MMU emulation they emitted a backpatch error then crashed. However, <a href="https://github.com/Sonicadvance1">Sonicadvance1</a> is a former Dolphin developer who <em>made Dolphin's ARM JIT</em> - he knows what he is talking about. It was worth checking. So May immediately passed this on this comment, and JMC gave the three titles a quick test. They ran perfectly fine without full MMU emulation. Huh. Well there's only one thing to do when games are mysteriously fixed like this - bisect!</p>
<p>Through bisecting, we learned that <a href="https://dolphin-emu.org/download/dev/master/5.0-15699/">5.0-15699</a> is what now allows the Disney Trio of Destruction™ to work without full MMU emulation. This change was briefly mentioned in the <a href="https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/#50-15680-textureconvertershadergen-set-alpha-to-1-on-intensity-formats-if-efb-lacks-alpha-by-pokechu22">previous Progress Report</a> but was not explained, so we'll go over it now.</p>
<p>One of the biggest speedups in Dolphin is "fastmem". Emulating memory mapping is a very involved task, as the GameCube and Wii have very different memory mapping than the the hardware Dolphin runs on, and checking the mapping of every memory access beforehand is quite expensive. So Dolphin handles this by... just mapping the memory on the host system directly, differences be damned. Whenever the mappings are shared, as it can be for simple mappings, the host CPU will handle it and we get a massive speedup (fastmem). However, whenever it doesn't match, the host CPU faults. Then Dolphin's fastmem exception handler will backpatch that access to use "slowmem" where Dolphin will manually translate the memory address. Due to the brute force nature of fastmem, it fails a lot, a lot lot, but it's <em>always</em> worth it to try for fastmem on pretty much any memory access - a fastmem loadstore takes as little as 2 instructions, where as the same access in slowmem can take up to <strong>1000 instructions!</strong> However, fastmem can only work because we catch exceptions and backpatch them through slowmem.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-january/trioofdestruction.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-january/trioofdestruction.jpg"></a>
<figcaption>We just had to use this image again.</figcaption>
</figure>
</div>
<p>Even with exceptions, there is an exception. <code>Quantized Paired Single Loadstore</code> instructions, due to various quirks involving said quantization, cannot be backpatched. If one of these were to trigger an exception through fastmem, <em>everything would explode.</em> When fastmem was implemented in our x86-64 JIT long ago, the Dolphin's developers of the time were aware of this. They provided a solution, a "safe" path which uses a "test and branch" approach. Any instruction set to use this safe path will be tested before reaching fastmem, and if the test determines that it would fail in fastmem, it will be routed directly to slowmem without triggering an exception.</p>
<p>However, our predecessors only added test and branch to <code>Quantized Paired Single <strong>Stores</strong></code>. For some reason, they left <code>Quantized Paired Single <strong>Loads</strong></code> out of the safe route. We honestly don't know why. It is our assumption that they never encountered <code>Quantized Paired Loads</code> triggering exceptions after testing hundreds of games, so even though it was dangerous, they decided that the very minor performance hit of the test and branch method was not necessary.</p>
<p>Unfortunately, it appears that they never considered that <em>Dolphin</em> could force <code>Quantized Paired Loads</code> down the path of destruction.</p>
<p>While <a href="https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/#50-15680-textureconvertershadergen-set-alpha-to-1-on-intensity-formats-if-efb-lacks-alpha-by-pokechu22">fixing the graphical issue in Rygar</a>, we noticed that it now required full MMU emulation when it didn't need it before. <a href="https://github.com/JosJuice">Josjuice</a> looked into it, and traced this regression to <a href="https://dolphin-emu.org/download/dev/master/5.0-14829/">5.0-14829</a>. That change <a href="https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-report-august-2021/#50-14829-powerpc-implement-broken-masking-behavior-on-uncached-writes-by-josjuice-with-help-from-eigenform-delroth-phire-marcan-segher-extrems-and-rylie">made Dolphin able to emulate the GameCube and Wii's broken masking for uncached unaligned writes</a>, which was required for a powerful <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a> speedrunning trick. But to accomplish that, we had to make uncached memory accesses always trigger a fastmem exception and go through slowmem. </p>
<p>Rygar just so happens to do a <code>Quantized Paired Load</code> from an uncached memory region. This forced a fastmem exception on a <code>Quantized Paired Load</code> and...</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/cars2explosion.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/cars2explosion_thumb.jpg"></a>
<figcaption></figcaption>
</figure>
</div>
<p>Full MMU emulation happened to work around this. Under full MMU emulation, <em>all quantized memory access instructions</em> use test and branch. Thanks to that, the test caught the <code>Quantized Paired Load</code> and routed it directly to slowmem, bypassing the exception and crash.</p>
<p>Fortunately the solution was very simple. In <a href="https://dolphin-emu.org/download/dev/master/5.0-15699/">5.0-15699</a>, <a href="https://github.com/JosJuice">Josjuice</a> made <code>Quantized Paired Singles Loads</code> safe with test and branch. Now, even without full MMU emulation, we always test <code>Quantized Paired Loads</code> and prevent them from triggering the exception that leads to catastrophy.</p>
<p>And now we return to the Disney Trio of Destruction™. In their case, well we don't know exactly, but we believe they are using a <code>Quantized Paired Single Load</code> to load from MMIO (Memory-Mapped Input and Output). MMIO cannot go through fastmem, so that case will always trigger a fastmem exception. And since it was a <code>Quantized Paired Single Load</code>... boom. But thanks to <a href="https://dolphin-emu.org/download/dev/master/5.0-15699/">5.0-15699</a>, this no longer occurred, and we no longer needed to use full MMU emulation to work around it. Once we discovered this, we were able to safely remove the MMU default from the Disney Trio of Destruction™.</p>
<p>Now that <a href="https://wiki.dolphin-emu.org/index.php?title=Toy_Story_3">Toy Story 3</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Cars_2">Cars 2</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Disney_Infinity">Disney Infinity</a> can run without the extremely performance-intensive full MMU option, what kind of performance improvement will this give us?</p>
<p><br/>
<script>
addChart({"title":{"text":"Cars 2 Performance"},"subtitle":{"text":"Main Menu | 5.0-16350 | AMD Ryzen 5950X | GeForce GTX 1070"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"data":{"csv":"\"null\";\"FPS\"\n\"With Full MMU\";22\n\"Without Full MMU\";22","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"series":[{"name":"Frames Per Second","turboThreshold":0,"marker":{}}],"yAxis":{"max":30,"min":0,"tickLength":10,"tickInterval":5,"title":{"text":""},"labels":{"format":"{value} FPS"}},"legend":{"floating":false,"enabled":false},"pane":{"background":[]},"responsive":{"rules":[]},"xAxis":{"title":{"text":""},"labels":{}},"colors":["#006eff","#434348","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"tooltip":{"shared":false},"lang":{},"credits":{"enabled":false}})
</script>
<br/></p>
<p>Absolutely none - these games are bottlenecked by something else. Oh well!</p>
<h4 id="50-16009-memarena-use-memory-placeholders-for-fastmem-on-windows-to-ensure-nothing-allocates-within-the-fastmem-space-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16009/">5.0-16009 - MemArena: Use memory placeholders for fastmem on Windows to ensure nothing allocates within the fastmem space</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-16009-memarena-use-memory-placeholders-for-fastmem-on-windows-to-ensure-nothing-allocates-within-the-fastmem-space-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>This change added a placeholder for our fastmem address region on Windows, making sure that nothing else can allocate memory within our fastmem address region once we've claimed it. This resolves an issue where very large texture packs could crash Dolphin.</p>
<p>It also broke our Windows 7 support.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7error.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7error.png"></a>
<figcaption></figcaption>
</figure>
</div>
<h4 id="50-16035-memarena-restore-windows-7-support-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16035/">5.0-16035 - MemArena: Restore Windows 7 support</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-16035-memarena-restore-windows-7-support-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<div style="margin-left:2em; margin-bottom:1em; min-width:64px; max-width:10%; float:right; text-align:center;"><img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7logo.svg"></div>
<p>The above change works by using the Windows function <code>UnmapViewOfFileEx</code>. In the words of Microsoft, this function "Unmaps a mapped view of a file from the calling process's address space." This allows Dolphin to preserve fastmem against very large texture packs in a fairly elegant way. However, <code>UnmapViewOfFileEx</code> has a minimum supported version of <em>Windows 8</em>. On Windows 7, Dolphin calls for the nonexisting function and Windows, recognizing that it isn't there, panics and crashes Dolphin.</p>
<p><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a> fixed this with <a href="https://dolphin-emu.org/download/dev/master/5.0-16035/">5.0-16035</a>. With this, Dolphin itself now checks whether <code>UnmapViewOfFileEx</code> is present on the Windows system, and will not use it if it fails to detect it. Of course this means that Windows 7 users may still encounter crashes when using very large texture packs, but that's better than Dolphin not working at all. </p>
<h4 id="50-16214-inputcommon-add-windowsgaminginput-to-controllerinterface-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16214/">5.0-16214 - InputCommon: Add Windows.Gaming.Input to ControllerInterface</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-16214-inputcommon-add-windowsgaminginput-to-controllerinterface-by-billiard" title="Permanent link">¶</a></h4>
<p>Long ago, there was DirectInput (DInput). This was Microsoft's original input API for game controllers on Windows, going all the way back to <em>Windows 95</em>. It was/is fairly messy by today's standards, requiring manual mapping of each button individually, but it was/is extremely flexible, able to handle any and all types of game control devices. However, once Microsoft created the Xbox 360, they wanted a way to easily connect a 360 controller to a PC without mapping or other hassle. So Microsoft created a new input API, XInput. While it is much less configurable than DInput, its simplicity allowed game developers to ship mappings for it within the game itself, so user mapping was no longer required.</p>
<p>Microsoft knew that they would want to add features to their controllers with new consoles, so they added a way to expand Xinput’s functionality with <a href="https://docs.microsoft.com/en-us/windows/win32/api/xinput/nf-xinput-xinputgetcapabilities?redirectedfrom=MSDN"><code>XInputGetCapabilities</code></a> (<a href="https://docs.microsoft.com/en-us/windows/win32/api/xinput/nf-xinput-xinputgetcapabilities?redirectedfrom=MSDN">link</a>). This Windows function allowed a controller to report if it had differing functionality than a 360 controller, potentially allowing for future expandability or even “weird” functionality like touchpads or gyros featured on other controllers. However, it turned out that the majority of programs took a bit of a shortcut and ignored non-essential parts of the XInput spec. If a controller used <code>XInputGetCapabilities</code>, it was very unlikely to encounter software that even noticed. This laziness dripped down toward manufacturers, and many controllers began to improperly implement the XInput API because the games they used to test weren’t enforcing it correctly. If one of these flawed controllers was used in a software that actually supported the full, proper XInput spec, the software could crash. <a href="https://dolphin-emu.org/blog/2017/09/02/dolphin-progress-report-july-and-august/#50-5205-ignore-capabilities-reported-by-an-xinput-device-by-toadking">Ask us how we know.</a></p>
<p>When Microsoft created new Xbox controllers, they wanted to support the controller’s new functionality on Windows. Now with a reason to resolve the <code>XInputGetCapabilities</code> nightmare, Microsoft’s devised a solution - make a new input API. Naturally.</p>
<p>The creatively named “Windows.Gaming.Input” (WGI) is the newest input API for Windows. This ambitious new API seeks to combine the best of both DInput and XInput into a single API, with a new input-centric approach that theoretically will give it the flexibility for many different types of input devices while maintaining easy setup and use. However, those new features haven't been implemented yet, and as it stands today it is basically just XInput plus One/Series controller features. And it's still missing esssential features that aren't on their Xbox controllers, like accelerometers and gyros, so currently WGI is just yet another Microsoft input API for Microsoft input devices.</p>
<p>Regardless, Dolphin's need to emulate Wii Remotes and several <em>odd</em> controllers for the GameCube and Wii makes having robust input API support a higher priority for us than most other programs, so supporting Windows.Gaming.Input was a natural choice. Many benefits are immediate, as it supports up to eight simultaneous controllers (up from four with XInput), support for the Xbox One/Series rumble triggers, and has better battery reporting. Basically everything we were hoping <code>XInputGetCapabilities</code> would be. However, if the input-centric WGI future comes to pass, users may be able to use it for all kinds of different input devices. We shall see.</p>
<p>It also broke our Windows 7 support.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7error2.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7error2.png"></a>
<figcaption></figcaption>
</figure>
</div>
<h4 id="50-16236-corewginput-dynamically-load-winrt-function-addresses-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16236/">5.0-16236 - Core/WGInput: Dynamically load winrt function addresses</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-16236-corewginput-dynamically-load-winrt-function-addresses-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<div style="margin-left:2em; margin-bottom:1em; min-width:64px; max-width:10%; float:right; text-align:center;"><img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/windows7logo.svg"></div>
<p><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a> came to rescue Windows 7 once again. Much like the previous Windows 7 fix, this change made Dolphin use <a href="https://docs.microsoft.com/en-us/windows/win32/api/apiquery2/nf-apiquery2-isapisetimplemented"><code>IsApiSetImplemented</code></a> (<a href="https://docs.microsoft.com/en-us/windows/win32/api/apiquery2/nf-apiquery2-isapisetimplemented">link</a>) to check for Windows.Gaming.Input support before trying to use it. With that, Dolphin's Windows 7 support was saved.</p>
<p>...briefly. But that's a story for the next Dolphin Progress Report.</p>
<h4 id="50-16174-fix-opengl-label-identifiers-for-angle-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16174/">5.0-16174 - Fix OpenGL Label Identifiers for ANGLE</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-16174-fix-opengl-label-identifiers-for-angle-by-iwubcode" title="Permanent link">¶</a></h4>
<div style="margin-left:2em; margin-bottom:1em; min-width:64px; max-width:25%; float:right; text-align:center;"><img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/exynos2200logo.jpg"></div>
<p>This may not sound very interesting, but this was a quick fix necessary to fix Dolphin running under an OpenGLES wrapper called ANGLE. Why exactly?</p>
<p>The story actually started a few months ago, when it was announced that the Exynos 2200 chipset to be used in some models of the Samsung Galaxy S22 would contain AMD's RDNA2 graphics hardware and drivers. This left us very interested. RDNA2 is great hardware, and while AMD's drivers may not be <em>best in class</em>, they are leagues above the horrors we've seen on Android. We were very hopeful!</p>
<p>Now the hardware is out and users have been able to test it. Vulkan performance on the Exynos 2200 is a step above what we've seen on any other phone. It's able to reach full speed in demanding games like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> at up to 2x Internal Resolution <em>without</em> having to disable critical features like EFB Access to CPU. This is notable because GPU readbacks have long been a major bottleneck on mobile devices.</p>
<p>But when we saw OpenGLES on the device, we were taken aback. It's disappointing to say the least. More disappointing than normal AMD OpenGL drivers on Windows. Even more disappointing than <strong>Mali</strong> drivers. That's because there are <strong>no OpenGLES drivers provided for this device</strong>. Instead, it uses a wrapper called <a href="https://github.com/google/angle">ANGLE</a> to <em>translate</em> OpenGLES to Vulkan.</p>
<div class="media-block narrow">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/facepalm.mp4" type="video/mp4"/>
</video></div>
<figcaption>This is how graphics software engineers responded to this news. </sub></figcaption>
</figure>
</div>
<p>ANGLE was designed to translate <strong>WebGL</strong> to other graphics APIs. It was not designed for games, and it is not battle-hardened the way a graphics driver would be. Naturally, there were some <em>growing pains.</em></p>
<p>For us, when the phones first launched Dolphin's OpenGLES backend wasn't even able to run on them due to a minor mistake in Dolphin's OpenGL Label Identifiers. This was a known <em>whoops</em> that <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> found during work on another feature a while ago, but it was so inconsequential that it wasn't a priority to split-off and upstream right away. When given an incorrect Label Identifier, the driver should just return an error saying it is incorrect then continue on. It's harmless. But ANGLE has no validation for this function, so rather than say that the Label is wrong and continue, it hits an <a href="https://en.wikipedia.org/wiki/Unreachable_code">unreachable</a> and <em>explodes</em>. While it may have been a Dolphin mistake that caused this, crashing for such a minor mistake in a harmless debugging feature is <em>absolutely</em> an ANGLE issue.</p>
<p>Once we identified that this was the source of the problem, <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> picked out the Label Identifier fix and we merged it. We never should have needed to fix it, but here we are. With that, the OpenGLES backend now works on the Exynos 2200.</p>
<p>However, because OpenGLES is being translated to Vulkan by ANGLE for this device, performance seems <em>significantly</em> worse than native Vulkan in every recorded instance. If you have an Exynos 2200 device, please do not use the OpenGLES backend on it.</p>
<p><br/>
<script>
addChart({"title":{"text":"Galaxy S22 Exynos 2200 Performance"},"subtitle":{"text":"Super Mario Galaxy Hub Area"},"exporting":{},"chart":{"type":"column"},"series[0]":{"type":"line"},"series":[{"name":"2x Native","turboThreshold":0,"marker":{},"color":"#006eff"},{"name":"3x Native","turboThreshold":0,"marker":{},"color":"#ff3100"},{"name":"Framelimit","turboThreshold":0,"marker":{"enabled":false},"type":"line","dashStyle":"LongDash","dataLabels":{"enabled":false},"ignoreHiddenPoint":true,"intervals":3,"lineWidth":4,"neckWidth":"30%","neckHeight":"25%","showInLegend":true,"allowOverlapX":false,"alternateStartingDirection":false,"allAreas":true,"color":"#00c800"}],"plotOptions":{"series":{"dataLabels":{"enabled":true},"animation":false}},"data":{"csv":"\"null\";\"2x Native\";\"3x Native\";\"Framelimit\"\n\"Vulkan\";60;36;60\n\"OpenGLES (ANGLE)\";41;23;60","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"tickInterval":15,"title":{"text":""},"labels":{"format":"{value} FPS"}},"pane":{"background":[]},"responsive":{"rules":[]},"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<h4 id="50-16301-videocommon-handle-emboss-texgen-with-only-a-single-normal-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16301/">5.0-16301 - VideoCommon: Handle emboss texgen with only a single normal</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-16301-videocommon-handle-emboss-texgen-with-only-a-single-normal-by-pokechu22" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Category:Rogue_Squadron_(Series)">The Rogue Squadron series</a> is a marvel of game engine programming. There seems to be no end to Factor 5's tricks, as we've talked about <a href="https://dolphin-emu.org/blog/2015/02/01/dolphin-progress-report-january-2015/#40-5279-add-zfreeze-emulation-to-hardware-backends-by-neobrain-phire-and-nanobyte011">over</a> and <a href="https://dolphin-emu.org/blog/2014/10/31/dolphin-progress-report-october-2014/#40-3473-fix-mmu-loadsstores-that-cross-page-boundaries-by-fiora">over</a> and <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14019-fifo-runsync-with-the-gpu-on-command-processor-register-access-by-stenzek">over</a> again. But surely, after all these fixes over the years, we should have everything pretty down pat by now. There's no way there would be a major effect that has <em>never</em> worked in Dolphin before, right? RIIIIGHT?</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sanddolphin-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sanddolphin-broken_thumb.jpg" /></a>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowdolphin-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowdolphin-broken_thumb.jpg" /></a>
</figure>
</div><center><p>These sand and snow effects looked alright in Dolphin.</p></center>
</div>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sandconsolenohud.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sandconsolenohud_thumb.jpg" /></a>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowconsolenohud.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowconsolenohud_thumb.jpg" /></a>
</figure>
</div>
<center><p>Until you launched the games on console again and saw what they are <em>supposed</em> to look like.</p></center>
</div>
<p>This is an emboss effect Rogue Squadron 2 and 3 are applying to the sand and snow to give them more dimensionality and texture. Specifically, this is a GameCube implementation of DirectX6-era bump mapping. It's an impressive effect for the time, as the lighting on the ridges will shift and match the sun's angle even as the suns dynamically move through the sky. Bump mapping like this wouldn't become common until <em>the next console generation</em>, and here it is <em>in a GameCube launch title</em> from 2001! </p>
<p>However, there was a reason this effect didn't take off until years later. The DirectX9 and newer forms of bump mapping are painless - developers can use them with very little setup and they are very, very cheap to run. Devs don't even need to think about it. But with this older type of bump mapping, developers had to <em>build the effect themselves</em>. And it was not cheap. For something that just adds a bit of visual flare, most GameCube and Wii developers decided it was not worth it and passed it by.</p>
<p>But not Factor 5. This is Factor 5 we're talking about, of course they used it.</p>
<p>To explain how this all works, here is a bump mapping effect that already worked in Dolphin before this change. This X-Wing will be our example.</p>
<div class="media-block full-width">
<div class="swap" ontouchstart>
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/embossdemo-working.jpg" alt="First Image">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/embossdemo-disabled.jpg" class="img-top" alt="Active Image">
</div>
<p style="margin-top: .5em; max-width: 100%; text-align:center;">Click/Tap and hold to disable the X-Wing's bump mapping.</p>
</div>
<p>To build the effect, Factor 5 first needs to have a color map which contains the color of the object itself, then a height map, aka "bump map", which represents the height of the surface as a greyscale image. Cleverly, Factor 5 wasn't going to need the Alpha channel of the X-wing texture, so they used the Alpha as the height map.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingcolormap.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingcolormap_thumb.jpg" /></a>
<figcaption>This is the color map for an X-Wing in Rogue Squadron II.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingheightmap.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingheightmap.png" /></a>
<figcaption>And here's the height map, converted to traditional greyscale. Factor 5 is using bump mapping to add depth to the panels on the X-Wing.</figcaption>
</figure>
</div>
</div>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingtexture.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2X-wingtexture_thumb.jpg"></a>
<figcaption>But this is the actual texture. The "cut out" areas are the Alpha channel which the game is using as its height map.</figcaption>
</figure>
</div>
<p>The process begins with the game writing the light direction into the Tangent and Bi-normal vectors (registers) with each vertex. As opposed to the Normal vector which tracks movement out from a surface, the Tangent and Bi-normal vectors track movement parallel to the surface. If Normal is Z, Tangent and Bi-normal are X and Y, effectively. </p>
<p>From there, the game reads the texture twice, the first time with the base texture coordinates then again with an offset using the light direction values written into the Tangent and Bi-normal vectors earlier. Then it combines this with the height map to apply the bump mapping to the texture, brightening or darkening the texture based on the height differences. This process burns two TEV stages (out of sixteen), so this is not a cheap effect, but that is how you do bump mapping on the GameCube!</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/embossrecreation.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/embossrecreation.png"></a>
<figcaption>Due to how the effect is built we were not able to dump the final embossed texture. This is a photoshop creation that shows more or less how it would look when applied to the color map.</figcaption>
</figure>
</div>
<p>While this effect is fairly primitive by modern standards, literally just painting the texture, the magic of this effect is that it is tied to the light direction. Thanks to this, the effect does a fantastic job of giving convincing depth to the surface, even in motion!</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2video-bumponly.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2video-bumponly_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Here is the bump mapping in motion, with most other effects and textures removed for clarity. Pay attention to the lines here. After the light moves over it, it flips! It uses the light direction!<br/><sub>Click the video for the high resolution version.</sub></figcaption>
</figure>
</div>
<p>When added to all of the <em>rest</em> of the ahead-of-their-time effects like self-shadowing and reflections, these games look like nothing else.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2video-alleffects.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2video-alleffects_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>This thumbnail does not do this video justice. Please click it for full res.</figcaption>
</figure>
</div>
<p>Now, all that we've covered so far already worked in Dolphin. So why didn't the sand and snow effect appear correctly? Well, the sand and snow are using effectively the same effect, but on these two surfaces <em>the game doesn't supply the Tangent and Bi-normal vectors for the effect.</em> Without them, Dolphin can't know what the offset is, and the effect cannot be rendered. Yet we know this works on console. It was as though Factor 5 used <em>literal</em> magic!</p>
<p>This has annoyed Dolphin developers for years. Factor 5 was clearly getting the offset from <em>something</em>, but try as we might, we couldn't find it. <a href="https://github.com/Sonicadvance1">Sonicadvance1</a> years ago made a guess that it was using default values, and it even passed a hardware test, but further analysis proved this to be incorrect. <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> more recently tried to hardcode some values that looked correct for RS2, but they ended up being very wrong for RS3. No matter what we threw at it, we just couldn't figure it out.</p>
<p>In the end, we didn't - we were told how it was done by Factor 5 themselves when we discovered a <a href="https://www.gamedeveloper.com/programming/shader-integration-merging-shading-technologies-on-the-nintendo-gamecube">2002 article written by a Factor 5 employee</a>.</p>
<p><br/>
<blockquote>A trick that is worth mentioning is how to avoid sending the same bi-normals and tangents for emboss mapping repeatedly to the transform unit (XF) of the graphics processor. It turns out that if these vectors are not present in the vertex format, XF will provide the previously transformed bi-normal and tangent, which reside in internal registers. Thus, if a dummy triangle is drawn with the bi-normal and tangent immediately before the landscape is drawn, then there is no need to send the same vectors over again for the rest of the height-map triangles. This means that only one vertex format is needed for the entire landscape, and it saves memory, transfer bandwidth and most importantly transform performance.</blockquote>
<br/></p>
<p>Basically, the sand and snow are the <strong>exact</strong> same effect as the bump mapping effects that were already working elsewhere in the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Rogue_Squadron_(Series)">Rogue Squadron games</a>. However, the sand and snow have a performance optimization where the Tangent/Bi-normal vectors are written at the start of the terrain's construction, and all the subsequent steps (including the bump mapping) reuse the stale data in the vectors.</p>
<p>After discovering this, we weren't really all that surprised. We had considered this as one of the many possibilities. However, it was very difficult for us to test due to how Dolphin JITs the vertex loader - it was not designed to preserve the vectors and it would not be easy to make it do so. Due to the difficulty, we never tried it. But once we knew for sure that this is what they did, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> did some hardware testing and confirmed it, then stepped in to make the vertex loader able to preserve stale data in the vectors.</p>
<p>And with that, the sand and snow bump mapping effect works in Dolphin! </p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sanddolphin-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS2sanddolphin-working_thumb.jpg" /></a>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowdolphin-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RS3snowdolphin-working_thumb.jpg" /></a>
</figure>
</div><center><p>At long last, Dolphin now properly supports this effect!</p></center>
</div>
<p>Now before we move on, we wanted to share one final thing. While working on this, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> wanted to confirm that the bump mapping on the sand and snow reacted to the light direction, so they set up a time lapse on console by spinning around in circles and taking captures at regular intervals while the suns set. It ended up not being very useful as the stage runs out of time before the light moves enough to confirm it for sure, but <em>it looked awesome</em>. So <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> rerecorded a nicer version in Dolphin for us to share in this Report.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RogueSquadron2-Sunset.mp4">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/RogueSquadron2-Sunsetteaser.jpg"></a>
<figcaption>There will be no hyper compressed thumbnail video for this one. Click the image above to see the timelapse! Humming a certain Star Wars theme is optional.</figcaption>
</figure>
</div>
<h4 id="50-16337-macos-work-around-earlyz-bug-on-apple-silicon-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16337/">5.0-16337 - macOS: Work Around EarlyZ Bug on Apple Silicon</a></strong> by <strong><a href="https://github.com/Oatmealdome">OatmealDome</a></strong><a class="headerlink" href="#50-16337-macos-work-around-earlyz-bug-on-apple-silicon-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>Apple silicon has proven to have an impressive capability at running Dolphin and has charmed the Dolphin developers. But there have been a few bumps here and there. One problem was that a lot of games were having a lot of darkness and strange flickering during some special effects. This ranges from platformers like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> to top-down shooters like <a href="https://wiki.dolphin-emu.org/index.php?title=Ikaruga">Ikaruga</a>.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/ikarugamacos-broken.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/ikarugamacos-broken_thumb.jpg"></a>
<figcaption>Ikaruga was barely recognizable on Apple silicon.</figcaption>
</figure>
</div>
<p>The issue was tracked down by <strong><a href="https://github.com/Oatmealdome">OatmealDome</a></strong> and they found that there was a nasty bug in the Apple driver when using <code>discard</code> while Early Z testing was enabled. Their solution was to simply <em>emulate</em> <code>discard</code> using a framebuffer fetch. This let Dolphin do things correctly while avoiding the broken codepath on the driver. This <em>could</em> result in a slight performance decrease on Apple Silicon, but so far we haven't recorded any noticeable differences.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/ikarugamacos-working.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/ikarugamacos-working_thumb.jpg"></a>
<figcaption>Now that's more like it.</figcaption>
</figure>
</div>
<h4 id="50-16348-rework-scissor-handling-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16348/">5.0-16348 - Rework scissor handling</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-16348-rework-scissor-handling-by-pokechu22" title="Permanent link">¶</a></h4>
<p>This is the second scissor change made to Dolphin in recent years, after the <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14041-scissor-offset-fix-for-super-mario-galaxy-roar-effects-by-ezio1900">Mario Galaxy roar</a> was discovered to use a negative scissor offset. Dolphin developers assumed that meant that the scissor offset could be negative and that was the end of the story. After all, if something else was wrong, wouldn't there be more examples of games having issues?</p>
<p>Well, there was one, we just didn't know it yet. This is the curious case of <a href="https://wiki.dolphin-emu.org/index.php?title=Major_Minor%27s_Majestic_March">Major Minor's Majestic March</a>, a game that barely rendered anything in Dolphin and for the past half decade, no one had much of an idea of why.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-broken.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-broken_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>What's all this? It's just white.</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-working_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Wait <em>this is gameplay.</em></figcaption>
</figure>
</div>
<p>As we've already spoiled thanks to <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> being the change author, we now know <em>way</em> too much about how <a href="https://wiki.dolphin-emu.org/index.php?title=Major_Minor%27s_Majestic_March">Major Minor's Majestic March</a> works and the behaviors it relies on. Let's get technical. And please take notes, as there will be a test at the end.</p>
<hr />
<p>The viewport, the scissor, and the scissor offset are all used to change where things end up on screen. Modern graphics APIs have both a viewport and a scissor, but don't have a direct equivalent to the scissor offset. Let's break down how each of these things work together.</p>
<p><strong>The Viewport</strong> is used to scale vertices into screen coordinates. It uses floating-point numbers, so it doesn't necessarily need to be aligned to a pixel grid, though in practice it is most of the time. This is mostly used to set the size of the rendering canvas.</p>
<p><strong>The Scissor</strong> is used to indicate which pixels get rasterized - pixels that are within the scissor region are drawn to and pixels that are not in that region are ignored. It usually is set to cover the whole screen with values that match the viewport, but can be set to a smaller value to create picture-in-picture style effects. There are 12 bits of space per coordinate, capable of representing a value from 0 to 4095, but testing found that the 12th bit is ignored, allowing only values from 0 to 2047. In Dolphin, it remains aligned to 1x IR pixel boundaries at higher internal resolutions in order to prevent issues.</p>
<p><strong>Scissor Offset</strong> is used to shift pixels <em>after</em> they've been rasterized but before they're written into the Embedded Frame Buffer (EFB). It operates on Pixel Quads, much like our good friend <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14257-bounding-box-account-for-pixel-quads-by-techjar">bounding box</a>, and it has 10 bits of space each for the x and y offsets, which could hypothetically represent a value from 0 to 1023 pixels directly, but instead is multiplied by 2 (to operate on pixel quads). Only 9 bits would be needed to represent a value from 0 to 1022, so the previous change assumed the 10th bit indicated negative numbers. This value is multiplied by 2, so to represent a value from 0-1022 only 9 bits are used, leaving the 10th bit unused. The EFB is 640 by 528 at most, and the largest size a texture can be is 1024 by 1024, so wrapping at 1024 isn't <em>that</em> strange.</p>
<p>All of this so far makes sense, but what follows doesn't. It turns out that much more space is provided than that, which can result in a triangle <em>drawing over itself</em> in a large enough viewport. We don't know of any games that do this, but it's apparently possible with fringe configurations. If you care about all of the hardware testing and strange behaviors, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> documented the <a href="https://gist.github.com/Pokechu22/5f83afb548bef8d75d3575d1c02bd518">details of their hardware tests in <em>copious</em> detail.</a></p>
<p>In the case of <a href="https://wiki.dolphin-emu.org/index.php?title=Major_Minor%27s_Majestic_March">Major Minor's Majestic March</a> they add a 1024 scissor offset to most of their graphics, which resulted in it <em>rendering off screen</em> in Dolphin. If you were paying attention in the lecture above, you'd already know that an offset of 1024 doesn't actually do anything in practice because it <em>wraps</em>! By reworking Scissor Handling to be more correct, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> fixed this issue to make the game finally playable in Dolphin.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/scissorhandling-working_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Marching is a lot easier when you can see.</figcaption>
</figure>
</div>
<p>The fix for Dolphin's Hardware Backends is a bit simplified and doesn't handle certain cases, like a game using an offset to have the same thing render multiple times. This does mean there are some minor cases of graphics disappearing early during certain transitions in <a href="https://wiki.dolphin-emu.org/index.php?title=Major_Minor%27s_Majestic_March">Major Minor's Majestic March</a> and can be observed on the left side of the screen in the demonstration above. Note that this is seen because <a href="https://wiki.dolphin-emu.org/index.php?title=Major_Minor%27s_Majestic_March">Major Minor's Majestic March</a>, on top of the aforementioned initial offset, also uses scissor offset to scroll the screen for transitions! If you want to see these scrolls and the duplicated graphics shown correctly, you'll need to use Dolphin's software renderer.</p>
<p>As an added bonus, these changes also fix a minor issue in <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Golf:_Toadstool_Tour">Mario Golf: Toadstool Tour</a> in which a picture-in-picture effect used for the <em>Hazard</em> placard would render slightly bigger than it should. This was rarely noticed because the issue was seemingly random, and the viewport itself wasn't affected. </p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong-broken_thumb.jpg" /></a>
<figcaption>Sometimes the hazard screen would show up with a bit of garbage on the the right side.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong-working_thumb.jpg" /></a>
<figcaption>This is how it would normally display</figcaption>
</figure>
</div>
</div>
<p>With some hackery, here's what Dolphin thought the game was trying to do.</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/mariogolfloooong_thumb.jpg"></a>
<figcaption>Now that's widescreen.</figcaption>
</figure>
</div>
<h4 id="50-16260-round-viewport-coordinates-when-using-vertex-rounding-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-16260/">5.0-16260 - Round Viewport Coordinates when using Vertex Rounding</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-16260-round-viewport-coordinates-when-using-vertex-rounding-by-pokechu22" title="Permanent link">¶</a></h4>
<p>This is tangentially related to all of the viewport and scissor shenanigans we detailed above, but instead this is a <em>hack</em> to help games render correctly at higher resolutions. In this case, we're targeting <a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Sports_Resort">Wii Sports Resort</a>. At higher resolutions, an annoying blue line would appear in the Archery Minigame.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/archeryline-broken.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/archeryline-broken_thumb.jpg"></a>
<figcaption>The cyan line here gets increasingly worse at high resolutions.</figcaption>
</figure>
</div>
<p>The issue is that the game is trying to reset depth on part of the screen by drawing a rectangle over it, and then clearing the color of the region using an EFB copy. Unfortunately, the coordinates stop matching up at higher resolutions because the game has the x coordinate of the viewport centered at 478.266. These decimals don't result in any problems with the low resolution of the console, but at higher resolutions this strange inaccuracy becomes increasingly noticeable.</p>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> stumbled upon this and decided that it <em>should</em> be possible to fix similar to other high IR bugs by rounding viewport coordinates at higher resolutions. They tried it out and...</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/archeryline-working.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/archeryline-working_thumb.jpg"></a>
<figcaption>No more line!</figcaption>
</figure>
</div>
<p>It turns out that rounding the coordinates off so that they match up again <em>does</em> work, and the solution was presented. Because this is such an edge-case of an edge-case, it was decided not to make Viewport Rounding a new option, but instead it was rolled into the already existing <em>Vertex Rounding</em> which is used for similar looking issues.</p>
<p>If there are any games that need Vertex Rounding that break because of this change, the two options will be split apart, but from our testing this appears to be fairly unlikely.</p>
<h3 id="porpoise-on-deck"><strong>Porpoise on Deck</strong><a class="headerlink" href="#porpoise-on-deck" title="Permanent link">¶</a></h3>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/steamdecknotheader.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-april/steamdecknotheader.jpg"></a>
<figcaption></figcaption>
</figure>
</div>
<p>Between Progress Reports we saw the arrival of the long awaited Steam Deck, a portable x86-based gaming PC/console hybrid from Valve. <a href="https://twitter.com/Dolphin_Emu/status/1494682332212596741">And you know we have one!</a> So how does the Steam Deck handle some very challenging Dolphin workloads?</p>
<p><br/>
<script>
addChart({"title":{"text":"Steam Deck Performance Test"},"subtitle":{"text":"Vulkan, 2x Native, Dual Core | Averages of Specific Scenes"},"exporting":{},"chart":{"type":"column","polar":false,"height":null,"width":null},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"series":[{"name":"VPS","turboThreshold":0}],"data":{"csv":"\"null\";\"VPS\"\n\"Melee Fountain of Dreams All Ice Climbers\";98\n\"Brawl New Pork City All Ice Climbers\";88\n\"Metroid Prime 3 Elysia\";58\n\"Skyward Sword Skyloft (30fps title)\";29\n\"Rogue Squadron II Hoth\";58","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"Frames Per Second (FPS)"},"tickInterval":30,"minorTickInterval":10,"startOnTick":false,"endOnTick":false,"labels":{}},"legend":{"enabled":false},"xAxis":{"title":{"text":""},"id":"VPS","labels":{}},"pane":{"background":[]},"responsive":{"rules":[]},"labels":{"items":[{}]},"colors":["#006eff","#434348","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"]})
</script>
<br/></p>
<p>These are absolutely torturous scenes that we are putting the Steam Deck through, and it's handling them very well. These results easily beat high end Coffee Lake ultrabooks from just a few years ago! We are confident that the majority of titles can run at fullspeed on the Steam Deck.</p>
<p>However, we have noticed that there is a lot of confusion about optimizing Dolphin on the Steam Deck. Here are a few things to keep in mind.</p>
<p>Building Dolphin with our <a href="https://dolphin-emu.org/docs/guides/building-dolphin-linux/">Building Dolphin for Linux</a> guide does not work on the Deck due to its immutable root directory. Fortunately, in desktop mode the deck has an app store called "Discover" which distributes flatpaks from flathub, and it has Dolphin's latest "Beta" build ready for installation. This is our recommended way to install Dolphin onto the Steam Deck. We're working on a better solution, but for now this is the best method available. If you need any help with this process feel free to ask on our <a href="https://forums.dolphin-emu.org/">forums</a>.</p>
<p>To preserve its battery as much as possible, the Steam Deck lowers the clockspeed of the CPU or GPU any chance it can. However, we're a bit unusual, and the Deck may guess incorrectly and take megahertz away from the CPU that we so desperately need. This is particularly present in readback heavy titles that use EFB Access or Store EFB to Texture and Ram. So when optimizing Dolphin on the Deck, be sure to use MangoHud to keep an eye on the CPU clockspeed. If you are below fullspeed and see MangoHud showing a CPU clock in the 2000-2500mhz range, you should make some adjustments - in our testing adjusting Dolphin's Internal Resolution and the Steam Deck's GPU Clocks help most. What you want to see is CPU clocks in the 3000-3400mhz range; then you know all of the Deck's CPU power is available to you. </p>
<p>The Steam Deck doesn't <em>just</em> support Vulkan, it supports OpenGL too. And sometimes, OpenGL can actually be faster than Vulkan! In the <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">Skyward Sword</a> test above, Vulkan tried desperately but couldn't quite reach fullspeed, while OpenGL ran right past it to around 38fps. So when running games on the Deck, be sure to give OpenGL a try.</p>
<p>And that's all for now. We have a lot more tips on the Steam Deck. In fact we even had a setup guide partially completed! However SteamOS is changing so fast that half of it was invalid within a month, so we decided to just cover the important tips. If you need help configuring Dolphin on your Steam Deck, please ask us on our <a href="https://forums.dolphin-emu.org/">forums</a>.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2022-02-01&to=2022-05-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-15995/">5.0-15995</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-16380/">5.0-16380</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
<p><style>
.swap {
position: relative;
display: inline-block;
}
.swap .img-top {
display: none;
position: absolute;
top: 0;
left: 0;
z-index: 99;
}
.swap:active .img-top {
display: inline;
}
</style></p>
Dolphin Progress Report: November and December 2021, January 2022
2022-02-08T12:04:47+00:002022-05-01T04:08:58.103129+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2022/02/08/dolphin-progress-report-nov-and-dec-2021-jan-2022/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/progressreportheader-nov2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/progressreportheader-nov2021mini.jpg" />
</header>
<p>This year, we've hit an important milestone that's been in the works for nearly a decade. In late 2012, <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> began work on Dolphin's ARM JIT. Back then, there weren't any devices that had even a sliver of hope of running Dolphin close to full speed, but that wasn't really the goal. All he wanted to do was see if it could be done; it sounded like a fun, challenging project. However, as time passed the idea turned into more than just a passing curiosity. Users were more than happy to donate to cover the hardware cost of staying on the bleeding edge of a <em>rapidly</em> evolving ecosystem, allowing ARM development to flourish. By 2015, <strong><a href="https://github.com/Sonicadvance1">Sonicadvance1</a></strong> astounded developers and the community alike with footage of <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart: Double Dash!!</a>'s time trial mode running close to full speed.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/-68fDxQAFfk" allowfullscreen></iframe></div>
<figcaption>We've come a long way.</figcaption>
</figure>
</div>
<p>On that note, we're happy to announce that Dolphin's AArch64 JIT has finally reached feature parity with Dolphin's x86-64 JIT. This means that every PowerPC instruction that the x86-64 JIT supports along with every major JIT feature are now supported in the AArch64 JIT! And this is a great time for ARM in general, with each generation of processor pushing the boundaries and companies like Apple adopting the architecture for larger and higher power devices like their M1 Mac line. For those on mobile phones and tablets, Adreno powered devices provide <em>decent</em> enough graphics drivers to get a reasonable experience at this point. And with a critical bottleneck getting fixed just days ago, performance on Adreno GPUs has skyrocketed. You won't have to scroll far for that news, we promise.</p>
<p>But that's only the tip of the iceberg; we've had three months worth of changes pile up and some other important infrastructure news. We've improved the user experience on macOS significantly and restored support for older devices. In fact, enough has happened that we'll be detailing the status of Dolphin's macOS support near the end of the report. </p>
<p>And... we haven't even talked about any emulation fixes yet. The past three months have had tons of changes that would have normally been the highlight of a Progress Report. The three month gap between reports <em>was not</em> because of a lack of changes. Want to take Riivolution games on netplay? You can. Hate the EA VP6 bugs? Make them a thing of the past with a new option. Wish your favorite LogicOp game worked on GLES or MoltenVK? Odds are, it does now! The list goes on, but outlining everything would take way too long, so let's just dive in. Please enjoy the November, December, and January Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-15952-disable-primitive-restart-on-adreno-by-the-dolphin-android-users"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15952/">5.0-15952 - Disable Primitive Restart on Adreno</a></strong> by The Dolphin Android Users<a class="headerlink" href="#50-15952-disable-primitive-restart-on-adreno-by-the-dolphin-android-users" title="Permanent link">¶</a></h4>
<p>As stated in the title of this change, credit for this discovery can't go to any single developer or tester. This change happened because of the greater Android community that spends <em>way</em> too much time trying to get the very most out of their mobile devices. Over the past four years, Dolphin has gotten a lot of optimizations, fixes, and tons of quality of life features. Yet, despite everything a lot of users would swear by old forks and some have taken up the mantle of trying to retrofit them with modern features. Why go through all of that effort? Performance! </p>
<p>Unfortunately, these forks are often just personal endeavors with messy histories, sometimes incoherent changelogs, and some of them don't provide the source code at all (<a href="https://github.com/dolphin-emu/dolphin/blob/master/LICENSES/GPL-2.0-or-later.txt">which is illegal, don't do that</a>). Some users swear by these forks, and we could never know why because there isn't a good way to see how they are different. Yet one thing was for sure: numbers didn't lie, and users said that these old forks allowed their GPUs to run at much higher resolutions than the latest builds, even if it meant losing out on game compatibility and some CPU optimizations. No matter what we did, we couldn't bridge the gap, at least on the Snapdragon line of devices.</p>
<p>And now we know why.</p>
<p>Near the end of January, <a href="https://github.com/Gamer64ytb">Gamer64ytb</a> reported that the difference had finally been found. One of the changes in the old fork was removing an optimization called "Primitive Restart." In fact, the original creator of that fork, <strong><a href="https://github.com/weihuoya">weihouya</a></strong>, tried to upstream this change to master, but their inexperience with contributing to Open Source projects, and a language barrier, left us with a <a href="https://github.com/dolphin-emu/dolphin/pull/7397">rather messy change</a> that had no reported benefits, it was simply because they didn't like the additional complexity Primitive Restart created. Testing of the time didn't reveal any conclusive benefits, yet it caused issues with Vulkan on Android, so Dolphin's developers declined to merge the change. However <strong><a href="https://github.com/weihuoya">weihouya</a></strong> pushed it into their fork anyway and fixed Vulkan separately. And that is what set this all into motion.</p>
<p><br/></p>
<blockquote>
<p>Primitive restart functionality allows you to tell OpenGL that a particular index value means, not to source a vertex at that index, but to begin a new Primitive of the same type with the next vertex</p>
</blockquote>
<p><br/></p>
<p>On the surface, Primitive Restart should be a safe performance benefit. It allows Dolphin to reduce draw calls by merging primitives together. In fact, some GameCube/Wii games natively use Primitive Restart! Unfortunately, Primitive Restart being faster requires the GPU driver to handle things efficiently, and in the case of Adreno that simply was not happening. In fact, it had such a huge overhead, that it became the single biggest bottleneck while using the driver. And profiling the Adreno driver isn't all that simple, so we didn't have a very good way to even see that this was a problem. It was only after <a href="https://github.com/Gamer64ytb">Gamer64ytb</a> reached out to us about this discovery that we were able to go through and analyze things for ourselves.</p>
<p><br/>
<script>
addChart({"title":{"text":"Adreno Primitive Restart Comparison"},"subtitle":{"text":"Need for Speed Carbon (GC) Starting Line, Snapdragon 855 (Asus Zenfone 6)"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"series":[{"name":"Primitive Restart","turboThreshold":0},{"name":"No Primitive Restart","turboThreshold":0}],"data":{"csv":"\"null\";\"Primitive Restart\";\"No Primitive Restart\"\n\"OpenGL 1x Native\";52.5;57\n\"OpenGL 2x Native\";40;47\n\"OpenGL 3x Native\";19;41.5\n\"OpenGL 4x Native\";11.5;27\n\"Vulkan 1x Native\";52;51.5\n\"Vulkan 2x Native\";38.5;51.5\n\"Vulkan 3x Native\";21.5;40.5\n\"Vulkan 4x Native\";12;26.5","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"legend":{"layout":"horizontal","shadow":false,"squareSymbol":true,"itemDistance":50,"floating":false},"pane":{"background":[]},"responsive":{"rules":[]},"colors":["#ff2b00","#1a62ff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"tooltip":{"valueSuffix":"FPS"},"yAxis":{"title":{"text":""},"labels":{"format":"{value}FPS"},"tickInterval":15},"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<p>The chart paints a very clear picture. This is one of the biggest across-the-board performance boosts we've seen in a very long time. This affects all supported Adreno devices, and should speed up Dolphin in any GPU limited situation. On mobile, this is <em>most</em> games, especially beyond 1x internal resolution. According to users and our personal tests, sometimes you'll see games that were lagging at 2x Internal Resolution now able to run at 4x Internal Resolution full speed! If you have an Adreno device and haven't tried Dolphin in a while, now's your chance. You might be pretty happy with the increased performance, along with all of the other changes that have brought compatibility roughly in line with that of desktop versions of Dolphin.</p>
<p>Unfortunately, disabling Primitive Restart is not a magic bullet for literally everything. Low-end Adreno devices with extremely weak CPUs aren't going to see a huge benefit. If you're not able to run a game at native resolution, odds are this won't help you. As well, Mali and Mediatek gain no benefit from disabling Primitive Restart. And on the Desktop side of things, as expected using Primitive Restart is slightly faster on NVIDIA devices and was already disabled on some AMD drivers and backends. This change and the performance implications only affect Adreno/Snapdragon devices. It's just that Adreno/Snapdragon devices also make up some of the best mobile devices that you can run Dolphin on currently.</p>
<h4 id="50-15538-mmu-support-for-aarch64-jit-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15538/">5.0-15538 - MMU Support for AArch64 JIT</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15538-mmu-support-for-aarch64-jit-by-josjuice" title="Permanent link">¶</a></h4>
<p>Dolphin's AArch64 JIT has been highly capable the last few years, but as we've repeatedly noted, there were a few features missing here and there that caused it to be slower in certain titles. The biggest of those was the lack of MMU support.</p>
<div style="margin-left:2em; margin-bottom:1em; min-width:120px; max-width:35%; float:right; text-align:center;"><a href="https://dolphin-emu.org/m/user/blog/finalgcgame/gekko.jpg"><img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/finalgcgame/gekko_thumb.jpg"></a><p>The MMU is a part of the GameCube's CPU. <sub><a href="https://commons.wikimedia.org/wiki/File:Ic-photo-IBM--PPCDBK-EFB486X3--(Gamecube-CPU).jpg">Credit: Wikimedia user ZyMOS / CC by-SA 4.0</a></sub></div>
<p>On the GameCube and Wii, rather than directly accessing available RAM, games interface with virtual memory which is then translated to physical memory by the Memory Management Unit (MMU). The MMU is programmable and gives games a wide array of options for manipulating virtual memory. Fortunately, to our benefit, most games didn't bother to take advantage of that feature and just used the default memory mappings of the MMU. As such, for the vast majority of games Dolphin can just directly translate the virtual memory to host memory, which is simple and speedy. However, a few impressive games did decide to go beyond the default mappings and write their own custom exception handlers to allow themselves to move things around in memory wherever they wanted. <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars:_The_Clone_Wars">Star Wars: The Clone Wars</a> even <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/">changed the Block Address Translations mid-game</a>! Any game that takes advantage of the MMU requires Dolphin to slow down and pay attention so it can emulate all of these behaviors, creating a significant bottleneck on CPU emulation. While it will never be cheap, Dolphin's x86-64 JIT does everything it can to make this as fast as possible.</p>
<p>The AArch64 JIT completely lacked MMU support, forcing all of these instructions to be run through the interpreter instead. This meant that one of our most intensive emulation tasks was being run through our compatibility-focused interpreter, on power limited hardware! For games like <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Rogue Squadron 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron 3</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Spider-Man_2">Spider-Man 2</a> to ever approach fullspeed on AArch64 devices, MMU supported needed to be implemented in the AArch64 JIT. This change essentially proves that, with huge performance gains across all MMU titles. Now that dream of running some of these games full speed on your favorite ARM devices isn't so far-fetched.</p>
<p><br/>
<script>
addChart({"title":{"text":"AArch64 MMU Performance Comparison"},"subtitle":{"text":" M1 Max (32 GPU Core) MacBook Pro 14in, Vulkan"},"exporting":{},"chart":{"type":"column","polar":false},"plotOptions":{"series":{"dataLabels":{"enabled":true}}},"series":[{"name":"Before (5.0-15445)","turboThreshold":0},{"name":"After (5.0-15940)","turboThreshold":0}],"data":{"csv":"\"null\";\"Before (5.0-15445)\";\"After (5.0-15940)\"\n\"Rogue Leader Intro\";22;66\n\"Rogue Leader Hoth\";27;64\n\"Rebel Strike Intro\";29;42\n\"Ultimate Spiderman Rhino Stomps (30fps Title)\";17;42","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":""},"labels":{"format":"{value}FPS"},"max":75,"tickInterval":15},"colors":["#ff2b00","#1a62ff","#90ed7d","#f7a35c","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"xAxis":{},"pane":{"background":[]},"responsive":{"rules":[]},"tooltip":{"borderWidth":2,"borderRadius":4,"followPointer":true,"shared":false,"split":false,"valueSuffix":"FPS"},"credits":{"text":"dolphin-emu.org","href":"dolphin-emu.org"},"legend":{}})
</script>
<br/></p>
<p>Note that this is an M1 Max, the most powerful AArch64 device on the market, and even it can't run <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron 3</a> at full speed. This is because MMU titles are still much more demanding in general, and that particular game does everything that's hard to emulate. Still, all MMU games perform better and <em>normal</em> MMU titles may even be able to run full speed on high-end AArch64 devices.</p>
<h4 id="50-15524-aarch64-support-for-codegen-space-reuse-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15524/">5.0-15524 - AArch64 Support for Codegen Space Reuse</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15524-aarch64-support-for-codegen-space-reuse-by-josjuice" title="Permanent link">¶</a></h4>
<p>If your raw performance is fine, the next thing most users want is for things to run as smoothly as possible. And that's where <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#50-12575-jit-codegen-space-reuse-by-admiralcurtiss">Codegen Space Reuse</a> comes in. By marking spaces of invalidated code as reuseable, Dolphin can minimize costly JIT cache flushes and keep your game running smoothly, even when it's generating dynamic code. This feature has been present in Dolphin's x86-64 JIT for <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#50-12575-jit-codegen-space-reuse-by-admiralcurtiss">over a year</a>, but now <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has ported the feature over to the AArch64 JIT.</p>
<p>Overall, this is a <em>targeted</em> optimization that only targets certain games. Probably the most popular game that used to suffer from this issue was <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_(GC)">Metroid Prime</a> and the other games on that engine. Nintendo 64 Virtual Console games have their very own JIT, so they generate <em>tons of code</em> and would hitch constantly before as the cache would get flushed once or twice every five minutes, but now will only require cache flushes every thirty minutes or so on average. And of course, we can't forget the memory management nightmare that is <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> which used to do... this...</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-january/truecrimestutters.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/truecrimestutters_thumb2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>People did not follow our advice when we said not to play the GameCube version of this game. We're looking at you, Vinny.</figcaption>
</figure>
</div>
<p>These issues are entirely resolved in most cases, and greatly reduced in the most extreme cases with Codegen Space Reuse. In most of the library, you should never see a JIT Cache Flush under normal play. </p>
<p>As a small aside, shortly after this feature was merged, users reported severe performance issues in a few select games, including <a href="https://wiki.dolphin-emu.org/index.php?title=Harry_Potter_and_the_Prisoner_of_Azkaban">Harry Potter and the Prisoner of Azkaban</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=F1_2002">F1 2002</a>. This was due to some minor JIT implementation differences between the x86-64 JIT and the AArch64 JIT, and were quickly rectified <a href="https://dolphin-emu.org/download/dev/80ccb209310b832b57f4fc18cf561ece5c37af4f/">by modifying the AArch64 JIT cache</a> to take into account some differences in how certain instructions are handled.</p>
<h4 id="50-15484-also-use-copy-filter-for-efb-copies-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15484/">5.0-15484 - Also Use Copy Filter for EFB Copies</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-15484-also-use-copy-filter-for-efb-copies-by-pokechu22" title="Permanent link">¶</a></h4>
<p>The EA Sports Active games were EA's response to the <a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Fit">Wii Fit</a>ness game craze. Despite having other franchises on the Wii such as <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Madden_(Series)">Madden NFL</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Category:FIFA_(Series)">FIFA</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Need_for_Speed_(Series)">Need For Speed</a> and many, many others... according to <a href="https://en.wikipedia.org/wiki/EA_Sports_Active">Wikipedia</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> is EA's top selling Wii game. Seriously. It was so popular that they made <em>four</em> EA Sports Active titles, including one that leveraged their NFL license.</p>
<p>Despite seeming like nothing more than simple exercise games, users trying to run the original <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> in Dolphin would find that things weren't exactly looking like they remembered.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eapink.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eapink_thumb.jpg"></a>
<figcaption>Believe it or not, this is a bug. We know it's hard to tell, but trust us.</figcaption>
</figure>
</div>
<p><a href="https://bugs.dolphin-emu.org/issues/6714">This bug was reported in 2013</a>, but was accidentally swept under the rug because <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active:_More_Workouts">EA Sports Active: More Workouts</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active_2">EA Sports Active 2</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active:_NFL_Training_Camp">EA Sports Active: NFL Training Camp</a> didn't suffer from this issue and their naming scheme was less than clear. Because of that, it was mistakenly marked as a duplicate of the more typical <a href="#50-15515-support-for-manually-handling-texture-wrapping-and-sampling-by-pokechu22">"VP6" video bug</a> when there was actually a unique issue present only in the original game! </p>
<p>To what has seemingly become <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong>'s specialty, they decided to investigate this bug in almost too much detail. If you care about exactly what was going on, what the developers were likely thinking, and exactly how the game renders, check out <a href="https://gist.github.com/Pokechu22/49455f9094ed0ff017da64e3f7aa0404">Pokechu22's writeup</a>. For now, we'll just go into the basics.</p>
<p>This game uses the GameCube and Wii hardware feature "Copy Filter". While copying a rendered frame from the Embedded Frame Buffer (EFB) to main memory, the hardware can <em>for free</em> do some very basic effects to each line of the image. This can be used to blur the image slightly, such as the "Deflicker" filters in the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Super_Smash_Bros._(Series)">Super Smash Bros. series</a>, or to brighten/darken the image, as used in fade-out transitions in <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Rogue Squadron 2</a> or gamma adjustments in <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_(GC)">Metroid Prime</a>. This is a non-programmable hardware feature, so after <a href="https://ast.dolphin-emu.org/blog/2018/06/03/dolphin-progress-report-april-and-may-2018/#50-7151-implement-copy-filter-deflickerbrightness-by-stenzek">we implemented it a few years ago</a>, we were confident that we had seen the last of Copy Filter related issues. However, we made a bit of an assumption that would come to bite us later.</p>
<p>With <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a>, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> discovered yet another clever use of the Copy Filter - Color Filtering! Thanks to their research, we can actually get a look at what the game looks like before and <em>after</em> the Copy Filter... filtering.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactiveunfiltered.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactiveunfiltered_thumb.jpg" /></a>
<figcaption>The base colors look a little washed out.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivefiltered.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivefiltered_thumb.jpg" /></a>
<figcaption>After filtering, the game does look a little bit nicer.</figcaption>
</figure>
</div></div>
<p>So how was <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> actually accomplishing this and what exactly were they doing? The game was making two different EFB copies for each frame. The first copy is configured to take the red and green channels of the image, and then the second copy takes the blue channel and uses the Copy Filter to take 1/16th the value of the current line. By separating the values out like this, the game is able to do some custom color/alpha blending to create more contrasty scenes with crisper colors.</p>
<p>When implementing the Copy Filter, we noticed that every known use of the Copy Filter was being done exclusively to <a href="https://dolphin-emu.org/blog/2017/11/19/hybridxfb/#rendering-frames-on-the-gamecube-and-wii">XFB Copies, a special type of EFB Copy where the frame is moved to a specific region of Main Memory designated for scanout</a>. So we assumed that copy filter effects could only be used for XFB Copies, and <em>excluded standard EFB Copies from the Copy Filter entirely</em>. <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> proved us wrong. By merely allowing EFB Copies to go through the Copy Filter, a trivial change, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> corrected the issue and now <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a>'s custom color shenanigans all work as intended.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivebrokencompare-fixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivebrokencompare-fixed_thumb.jpg" /></a>
<figcaption>The game with the bug has a certain eye-searing charm.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivefixedcompare-fixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivefixedcompare-fixed_thumb.jpg" /></a>
<figcaption>And fixed. ...Well that's a lot more boring.</figcaption>
</figure>
</div></div>
<p>Surprisingly enough, after submitting the fix we found out that <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> isn't the only game that uses Color Filtering like this! <a href="https://wiki.dolphin-emu.org/index.php?title=The_Last_Airbender">The Last Airbender</a>, based on the hit movie that Avatar fans love to bring up, used similar color filtering system, just with a much less interesting color palette.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/tlaunfiltered.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/tlaunfiltered_thumb.jpg" /></a>
<figcaption>If you look closely, you can see those same splotchy artifacts in the gray that you could see in EA Active.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/tlafiltered.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/tlafiltered_thumb.jpg" /></a>
<figcaption>With it fixed, the gray background is... well still grey but you can see things now. It's very serious.</figcaption>
</figure>
</div></div>
<p>As with any major change to emulation, adding this did cause a few minor issues here and there. Thankfully, the regressions were found and sorted out <a href="https://dolphin-emu.org/download/dev/dbaebdc585d562c25d4cf9360c8da6e078dcc1a6/">5.0-15518</a>. And then a few more were discovered and addressed in <a href="https://dolphin-emu.org/download/dev/f0136e0eb6468908c7883cdbc978225a2c8e9626/">5.0-15950</a>. And one of our debug features was also broken and finally addressed in <a href="https://dolphin-emu.org/download/dev/8e4155adfe22b60588ee31982cb481c7f981dbb9/">5.0-15961</a>.</p>
<p>Unfortunately there appears to still be a few quibbles to sort out. While working on this Progress Report, we noticed something was a little off about one of the characters and confirmed it does not occur on console.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivenotquite-console.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivenotquite-console_thumb.png" /></a>
<figcaption>On console after filtering, this character is still wearing a pretty normal light blue top.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivenotquite-dolphin.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eaactivenotquite-dolphin_thumb.png" /></a>
<figcaption>But Dolphin renders it as white with pink and blue shadows. Thankfully, a fix is already in the works.</figcaption>
</figure>
</div></div>
<p>If you want to see more details on this issue, please read <a href="https://gist.github.com/Pokechu22/49455f9094ed0ff017da64e3f7aa0404">Pokechu22's writeup on this bug</a>. It goes into a depth that we could never manage in a Progress Report!</p>
<h4 id="50-15515-support-for-manually-handling-texture-wrapping-and-sampling-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15515/">5.0-15515 - Support for Manually Handling Texture Wrapping and Sampling</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-15515-support-for-manually-handling-texture-wrapping-and-sampling-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Fixing the discoloration of <a href="https://wiki.dolphin-emu.org/index.php?title=EA_Sports_Active">EA Sports Active</a> was a win, but unfortunately there was still another problem that affected it and over <em>one hundred</em> other games. The breadth of games was huge, from EA's own sports titles, to the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:James_Bond_(Series)">James Bond series</a>, various <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Harry_Potter_(Series)">Harry Potter games</a>, several <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Need_for_Speed_(Series)">Need for Speed games</a>, the eternal <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Just_Dance_(Series)">Just Dance series</a>, and even strange outliers like <a href="https://wiki.dolphin-emu.org/index.php?title=Target:_Terror">Target: Terror</a>. Odds are if you had a sizeable library of games, you probably had at least one that was affected by this bug... if you had certain hardware.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/nvidiatexsample.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/nvidiatexsample_thumb.jpg" /></a>
<figcaption>If you were on a GPU that suffered from the bug, James Bond cutscenes would be a little hard to watch.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/manualtexsample.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/manualtexsample_thumb.jpg" /></a>
<figcaption>Other GPUs had no issues whatsoever.</figcaption>
</figure>
</div></div>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/targetterror.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/targetterror_thumb.jpg" /></a>
<figcaption>Target: Terror's backdrops and sprites are all FMVs.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/targetterror.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/targetterror-zoom_thumb.jpg" /></a>
<figcaption>You can see the familiar buggy lines if you look closely, since this was taken from a NVIDIA machine.</figcaption>
</figure>
</div></div>
<p>There are probably some readers scratching their head right now. It's very possible you've played many of the games we've mentioned and never noticed any kind of defect like this. That's because <em>this primarily affected NVIDIA GPUs</em>. There are exceptions, but if you haven't been using a NVIDIA GPU, odds are you haven't seen these issues. AMD graphics card users were almost entirely unaffected, and so were <em>most</em> phone and tablet users since Adreno and Mali are did not exhibit this bug. </p>
<p>That's because this is entirely due to <em>texture sampling quirks</em>. Texture sampling is the act of reading texture data (its color data, texture coordinates, etc) as well as texture filtering. As this is a feature that is going to be used, in scientific terminology, a <em>bajillion times per frame</em>, it needs to be <em>extremely</em> fast, so even the latest GPUs use <em>fixed function hardware</em> to accelerate this task. However, not all GPUs sample textures in the same way, but usually the differences from this are so small that they are limited to subpixel quirks.</p>
<p>The afflicted videos are comprised of many tiny and large textures that are combined together to build each frame of the video; a video that doesn't match the resolution the game is using. This already creates MANY opportunities for interpolation differences to crop up, but these video codecs takes things even further. The videos actually have color data from one texture produce an offset to the texture coordinates that are used when reading a second texture. This leads to <em>cascading rounding errors</em>, where even the tiniest differences can explode into view. We understand why they are doing this, but it makes these videos extremely fragile and they require extreme precision to reproduce accurately. In fact, if you look at the <a href="http://www.radgametools.com/bnkhist.htm#Changes%20from%201.8w%20to%201.8x%20(08-11-2007)">Bink Video changelog</a> from this era, you can see them struggling with this <em>on real consoles</em>.</p>
<p>Why are some graphics cards unaffected? While we're not 100% sure, we can at least give some conjecture to why AMD based cards aren't affected. The GameCube and Wii have ArtX graphics processors inside of them, a company that was absorbed by and became ATi and then was later purchased by AMD. It appears as though texture sampling behaviors <em>haven't</em> changed since the days of the GameCube, so these issues don't appear on their modern hardware. This also extends to our Adreno users, as their hardware traces their roots right back to ArtX as well.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eavp6android.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/eavp6android_thumb.jpg"></a>
<figcaption>Score one for Adreno!</figcaption>
</figure>
</div>
<p>Unfortunately for Nvidia users, they had no such luck. They would see the visual issues in VP5, VP6, and Bink videos that used these techniques. Worse yet, the issue actually can extend to cases <em>outside of FMVs</em>, such as the text boxes in <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Party_7">Mario Party 7</a> or the video gameplay elements in <a href="https://wiki.dolphin-emu.org/index.php?title=Target:_Terror">Target: Terror</a> which uses multiple Bink Videos for animated sprites to emulate the look of a classic arcade shooter!</p>
<p>For all this time, Nvidia users have simply had to deal with these issues. Since this is tied to low level GPU hardware differences, how are we supposed fix this for them? Well, we just had to stop relying on the offending bit of the GPU's hardware and do texture sampling ourselves!</p>
<p><em>Note: The Open Source "RADV" drivers for AMD graphics cards do show the sampling bugs. While Texture Sampling is handled by low-level GPU hardware, it's entirely possible for the GPU driver to affect how that low-level hardware functions. Oddly enough, the RADV driver's defects in these situations look slightly different than the defects on every other graphics card, with the vertical lines looking more like they are made up of dots.</em></p>
<h4 id="sorting-through-sampling">Sorting Through Sampling<a class="headerlink" href="#sorting-through-sampling" title="Permanent link">¶</a></h4>
<p>For the most part, Dolphin didn't do anything all that strange when sampling a texture. Outside of the shader, Dolphin would tell its graphics backend what to do while sampling the texture, such as linear sampling, mip mapping, wrap horizontally, wrap vertically, etc, all based on the situation. Regardless of orders sent, the shader then calls upon the fixed-function GPU hardware to sample that texture with the selected settings. Given that this wouldn't work for every GPU in every situation, a new solution had to be devised. What <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> decided to do was to create a way to <em>manually</em> sample the texture instead of relying on the graphics card's texture sampling unit. While it was a fair bit more work and we were concerned about performance, Dolphin itself could read and filter the texture manually in order to ensure results were consistent and correct to precisely what we needed. From there, the shader can look at the texture configuration and find out about other nearby coordinates, mipmap levels, and more with greater accuracy.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp7textbox.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp7textbox_thumb.jpg" /></a>
<figcaption>Inexact texture sampling could cause ugly lines, even at 1x internal resolution sometimes.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp7textboxmanual.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp7textboxmanual_thumb.jpg" /></a>
<figcaption>Manual texture sampling eliminates the issue entirely.</figcaption>
</figure>
</div></div>
<p>The experiment was a huge success right away, but there was a ton of work that had to be done to support literally everything that Dolphin could do. It took literal months to work through everything, but the greater level of control meant that Dolphin could also start emulating some of the stranger behaviors of texture handling of the GameCube and Wii. Most of those cases do not usually occur in retail games, but sometimes happen in mods and homebrew tested in Dolphin. One example of this was when a developer of the <em>Star Fox Adventures: Amethyst Edition</em> reported that textures that worked fine in Dolphin were broken on console. However, with Manual Texture sampling, we have the ability to make these textures behave accurately without forcing people to use the software renderer. If you use Manual Texture Sampling at 1x Native Internal Resolution with Load Custom Textures disabled, you can now catch problems with irregular textures that would have rendered fine otherwise.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/starfoxtexstandard.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/starfoxtexstandard_thumb.jpg" /></a>
<figcaption>Dolphin's standard handling of textures happily accepted these malformed textures and rendered it normally. This is incorrect emulation.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/starfoxtexmanual.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/starfoxtexmanual_thumb.jpg" /></a>
<figcaption>However, the secret title only for console and now Manual Texture Sampling was StarFox StarFox in the issue report.</figcaption>
</figure>
</div></div>
<p>For those that want the most accurate picture possible, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> has also added support for diagonal level of detail, which allows for more accurate selection of the correct texture mipmap if the game chooses to use it. This results in very minor differences that are only evident if you're directly comparing side by side with an identical screenshot from console. All of these cool features and fixes comes with no known regressions at this time, making it a rather safe option to try if you're interested in seeing if an annoying graphical issue is related to texture sampling! Just note that the enhancement "Anisotropic Filtering" is currently not implemented in Manual Texture Sampling, so that feature does nothing when Manual Texture Sampling is enabled.</p>
<h4 id="performance-perils">Performance Perils<a class="headerlink" href="#performance-perils" title="Permanent link">¶</a></h4>
<p>We've talked about having higher accuracy, better picture quality, and less reliance on GPU quirks without any visual regressions. But we haven't talked too much about <em>performance</em>. Since we are bypassing dedicated hardware meant to make texture sampling as fast as possible, a performance hit was inevitable. However, the story is actually rather complicated - how Manual Texture Sampling behaves depends on your GPU's architecture and raw computing power, as well as the resolution you wish to play at. At lower resolutions, i.e. 1-2x Native Internal Resolution, there isn't much of a bottleneck at all. In fact, some games actually run faster on certain hardware. However this will change at a certain resolution, usually around 3-4x Native depending on your GPU, and it becomes a noticeable performance bottleneck. </p>
<p><br/>
<script>
addChart({"title":{"text":"Manual Texture Sampling Performance Comparison"},"subtitle":{"text":"Super Mario Galaxy Complete Hub idle loop, All settings default except specified"},"exporting":{},"yAxis":{"max":150,"tickInterval":30,"title":{"text":""},"labels":{"format":"{value}FPS"}},"series":[{"name":"9900k+3090 Vulkan Standard","marker":{}},{"name":"9900k+3090 Vulkan Manual Texture Sampling"},{"name":"9900k+3090 D3D12 Standard"},{"name":"9900k+3090 D3D12 Manual Texture Sampling"},{"name":"6700k+1070 Vulkan Standard"},{"name":"6700k+1070 Vulkan Manual Texture Sampling"},{"name":"M1 Max Macbook Pro 14in Standard"},{"name":"M1 Max Macbook Pro 14in Manual Texture Sampling"}],"data":{"csv":"\"X Native\";\"9900k+3090 Vulkan Standard\";\"9900k+3090 Vulkan Manual Texture Sampling\";\"9900k+3090 D3D12 Standard\";\"9900k+3090 D3D12 Manual Texture Sampling\";\"6700k+1070 Vulkan Standard\";\"6700k+1070 Vulkan Manual Texture Sampling\";\"M1 Max Macbook Pro 14in Standard\";\"M1 Max Macbook Pro 14in Manual Texture Sampling\"\n1;150;150;147;143;111;115;99;96\n2;149;148;145;142;111;102;93;92\n3;147;144;144;140;111;89;86;69\n4;146;139;143;137;107;68;76;62\n5;143;134;141;134;101;56;73;60\n6;140;128;138;130;90;46;66;52\n7;137;120;136;123;77;37;61;42\n8;133;113;135;112;69;29;60;36\n9;129;104;131;101;63;26;60;30\n10;123;96;128;87;57;21;54;25\n11;119;83;124;79;49;18;47;21\n12;112;76;120;71;43;15;42;18\n13;105;69;112;64;37;13;37;16\n14;100;63;104;59;33;12;34;14\n15;94;58;94;53;29;10;30;12\n16;83;52;87;48;26;9;27;11\n17;77;47;81;43;23;8;25;10\n18;71;43;75;39;21;7;23;9\n19;66;39;69;35;19;6;20;8\n20;61;36;64;32;;;18;7\n21;57;33;59;30;;;17;6\n22;53;30;55;27;;;15;6\n23;49;28;51;25;;;14;5\n24;46;26;47;23;;;13;5\n25;43;24;44;22;;;12;4\n26;40;23;;;;;;\n27;37;21;;;;;;\n28;35;20;;;;;;\n29;29;18;;;;;;\n30;28;17;;;;;;\n31;24;15;;;;;;\n32;23;14;;;;;;","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"pane":{"background":[]},"responsive":{"rules":[]},"tooltip":{"followPointer":true,"borderRadius":5,"borderWidth":2,"shared":false,"valueSuffix":"FPS"},"chart":{"height":600},"colors":["#40c4ff","#2979ff","#ff9100","#ff3d00","#00e676","#388e3c","#e040fb","#8e24aa","#f45b5b","#91e8e1"],"plotOptions":{"series":{"dataLabels":{"enabled":false}}},"legend":{"enabled":true},"xAxis":{"labels":{"format":"{value}X Native"},"minorTickInterval":1,"minorTicks":true,"max":25,"tickInterval":5,"tickLength":10}})
</script>
<br/>
<center><p>Tip: You can hide or reveal items by clicking/tapping them in the legend.</p></center>
</br></p>
<p>If you have an absolute powerhouse GPU, odds are the performance impact won't affect you until you're at a resolution beyond reasonable. Those of us on more modest hardware are hit a bit harder. And those on older GPU architectures that are more sensitive to this, such as Pascal, are hit even harder. Considering that this only impacts certain hardware and can have a sizeable performance impact depending on your resolution and GPU architecture, we've mostly left this option disabled for now. In a few low impact games that heavily rely on FMVs (e.g. <a href="https://wiki.dolphin-emu.org/index.php?title=Just_Dance">Just Dance</a>) we have decided to enable it by default, as they aren't GPU limited in general and see almost no benefit from higher resolution. If <em>every</em> graphics card were affected, the decision of when to enable this would be a lot easier, but that's just not the case. </p>
<p>Eventually, we may need to come up with a <em>conditional</em> default, depending on the user's hardware, much like a driver details bug, but this time handled per-game. For now, if you have an afflicted card, "Manual Texture Sampling" resides in the "Advanced" area of the Graphics Settings Menu. If you enable Manual Texture Sampling, Dolphin will then Manually Sample Textures along with enabling all of those other accuracy bonuses. Our current plans are to find games that have heavy glitches with "Fast Texture Sampling" to the point that they are unplayable, and slowly enable Manual Texture Sampling on a case by case basis. Unfortunately, this does mean that some users with Graphics Cards/Drivers that did not have the error may have the setting enabled despite not <em>really</em> needing it. We'll continue to try to make smart decisions when to enable this feature, especially as we get more data on what games it effects and how it performs on all the vast variety of machines that our users play Dolphin on.</p>
<h4 id="50-15520-and-50-15604-riivolution-fixes-additions-and-netplay-support-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15520/">5.0-15520</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15604/">5.0-15604</a></strong> - <strong>Riivolution Fixes, Additions, and Netplay Support</strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-15520-and-50-15604-riivolution-fixes-additions-and-netplay-support-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>When Dolphin <a href="https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/#50-15407-hle-riivolution-patch-support-by-admiralcurtiss">added High Level Emulation (HLE) for launching and configuring Riivolution mods</a>, users quickly embraced the feature and we saw a huge influx of both appreciation and support requests. The initial implementation was fairly good, but there was no way we could test every mod and find every edge-case. Over the past three months, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> has been busy fixing Riivolution mods that didn't run on Dolphin and adding a few much requested features. Most of these bugs were very silly, and had to with things like "case sensitivity" of filenames and paths, duplicate files in the mod, and were mostly centralized to haphazardly constructed mods.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisportsstorm.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisportsstorm_thumb.jpg"></a>
<figcaption>Wii Sports Resort: Storm Island relies on very peculiar Riivolution behaviors.</figcaption>
</figure>
</div>
<p>On the side of <em>new</em> features, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> has brought some big hitters to the table. First of all, you can now create <strong>Game list Entries</strong> for Riivolution mods, letting you boot preconfigured mods directly from your game list!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/NewerSuperMarioBrosWii.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/NewerSuperMarioBrosWii.png"></a>
<figcaption>Creating game list entries for mods can be done from the Riivolution Menu and then those can be launched directly from the game list!</figcaption>
</figure>
</div>
<p>This may not seem like a huge deal at first, but this was one of the major requirements for booting Riivolution mods on <strong>Netplay!</strong> Once a Riivolution configuration is in your game list, you can use it for netplay. As long as all players in the netplay session have the Riivolution mod configured correctly, it'll work like any other game on netplay.</p>
<p><em>Note: Wii Remote Netplay is still experimental, and <em>only</em> works with Emulated Wii Remotes. Even then, some actions, such as Wii Remotes disconnecting, may not behave properly on netplay and improperly configured netplay sessions may hang on boot. Riivolution Mods for GameCube games and Wii games that support GameCube controllers are much easier to setup and synchronize properly.</em></p>
<p><em>Note 2: If you are planning on using Wii Netplay, please use revision <a href="https://dolphin-emu.org/download/dev/master/5.0-15559/">5.0-15559</a> or newer for reasons that we'll get to... right now!</em></p>
<h4 id="50-15549-and-50-15559-netplay-shutdown-and-wii-save-fixes-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15549/">5.0-15549</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15559/">5.0-15559</a></strong> - <strong>Netplay Shutdown and Wii Save Fixes</strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-15549-and-50-15559-netplay-shutdown-and-wii-save-fixes-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>After all of these years, Wii Netplay is still in a rather experimental state. There are a lot of challenges surrounding it, such as the Wii's internal memory, system files, and of course, those pesky Wii Remotes. Dolphin's netplay infrastructure was designed before the idea of taking Wii games onto netplay was even considered a possibility, so a lot of Dolphin's Wii netplay are tacked on top of an aging foundation. Syncing memory cards is one thing, but how do you synchronize a NAND that can be 500 MB and can contain copyrighted data? Well, that's actually the crux of a lot of bugs on Wii Netplay - synchronizing the NAND.</p>
<p>In order to avoid both legal and bandwidth issues, Dolphin sets up a "Blank" NAND for netplay, and then imports the necessary savefiles for the games the users want to play on netplay. This keeps the footprint small and avoids all the legal issues. When Netplay is over, these files are then exported back to the original NAND <em>if</em> the user has turned on "write saves"... which is actually where a nasty problem cropped up, one that could actually affect your actual NAND's save.</p>
<p>Due to an unfortunate race condition, mixed with Wii Remotes' propensity to want to crash Netplay in general, it was possible for the original save to be lost during the export process due to a race condition. While cleaning up part of the codebase for Riivolution games to function on netplay, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> noticed a bunch of these problems and found himself unable to figure out how the code was actually supposed to work. This may sound outrageous, but it's a fairly common occurence when you dive into the older parts of a project that has had this long of a lifespan. The only option at that point was to rewrite and fix up the code to at least make it work again. As it was, it seemed like Dolphin's Netplay was making assumptions that were no longer true due to changes in other parts of the codebase.</p>
<p>The save loss bug is fixed to the best of our knowledge in the latest builds, meaning it should be safe to take your saves on netplay again. Your original save from your real NAND should never get lost again. However, if Dolphin crashes during netplay, the updates to save files done during netplay will not exported to the main NAND. Do not panic if this happens! Your save data from the netplay session can still be retrieved in a Wii.backup folder contained in Dolphin's user files and manually converted. Do note that starting Dolphin and booting up another game will clear these files.</p>
<h4 id="50-15579-delay-single-core-gpu-interrupts-by-phire"><strong><a href="https://github.com/dolphin-emu/dolphin/pull/10244">5.0-15579 - Delay Single Core GPU Interrupts</a></strong> by <strong><a href="https://github.com/phire">phire</a></strong><a class="headerlink" href="#50-15579-delay-single-core-gpu-interrupts-by-phire" title="Permanent link">¶</a></h4>
<p>Most of the time, Single Core is Dolphin's accuracy option that helps with most random crashes and hangs. But in a few rare games, <em>Dual Core</em> is actually the more stable option. One of those games is <a href="https://wiki.dolphin-emu.org/index.php?title=Bomberman_Jetters">Bomberman Jetters</a>, and the reason why is pretty interesting.</p>
<p>One thing to note is that the GameCube and Wii are single core consoles, so there's only a limited amount of things we can try to parallelize from the main workload. However, early Dolphin developers realized that the GPU-related CPU work, such as sending graphics data and the like, was <em>reasonably</em> safe to split into a second host CPU core. After all, the CPU side of things doesn't interact with the GPU-related CPU work all that often. This meant they could run in parallel on separate host CPU cores for a time and only sync up at important moments (such as specific interrupts) in order to greatly improve performance. While today we know of Dual Core as the source of many random crashes, when it was initially implemented Dual Core mode wasn't as problematic as it is nowadays; usually the GPU thread was more than fast enough to keep up and users were always limited by the CPU thread. Ever since <a href="https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/">TEV_Fixes_New</a> Dolphin's performance profile has flipped, with the CPU thread now actually being faster where as the GPU thread has a lot more to do thanks to improved emulation.</p>
<p>This creates a scenario where the CPU thread may run too far ahead of the GPU thread, and if the GPU thread is too far behind when an interrupt happens, you may run into synchronization issues. There's not much we can do about this problem - the reason why Dual Core is fast is because the threads run without much syncing. If we add more syncing to fix the crashes, performance would drop. Besides, at this point Single Core has been optimized pretty well and on a lot of computers works well enough without any of the risks. It's a properly deterministic option for when a game is problematic on Dual Core.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Bomberman_Jetters">Bomberman Jetters</a> is one of the games where Dual Core's lack of synchronization is actually a <em>good</em> thing. This game expects GPU FIFO processing to take time. In Dual Core, this happens out of pure happenstance because the CPU thread and the GPU thread only meet up once in a while. Single Core executes everything exactly in order on a single thread with no delays whatsoever. Worse yet, the execution time would be <em>backdated</em> to when the FIFO command was first sent, meaning that <em>zero</em> time had passed since the game issued the command!</p>
<p>Rather than trying to emulate the whole pipeline correctly, <strong><a href="https://github.com/phire">phire</a></strong> came up with a little bit of a hotfix that makes FIFO execution a bit closer to correct on Single Core. With this change, FIFO execution is fed through an interrupt scheduler that can delay and make sure interrupts happen at the right time. Here, we just force a minimum wait time so that those interrupts that were happening instantly <em>now</em> happen a tiny bit into the future from when they were issued. It doesn't exactly address the core issue, but it's good enough to get the game booting. Unfortunately, this game is still prone to random hangs even with the initial hang fixed. But the good news is that there is a work-around now - lowering the emulated CPU clock by a small amount significantly (perhaps completely) reduces the likelihood of the game hanging.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/bombermanjetters.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/bombermanjetters_thumb.jpg"></a>
<figcaption>It's fitting that this game would be a ticking time bomb in Dolphin...</figcaption>
</figure>
</div>
<p>This <em>also</em> affects some <a href="https://wiki.dolphin-emu.org/index.php?title=Action_Replay_(GC)">Datel Products</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3</a> when running in Single Core, preventing game breaking hangs from happening. This is important because these <a href="https://wiki.dolphin-emu.org/index.php?title=Action_Replay_(GC)">Datel Products</a> were actually <em>broken</em> on Dual Core too, so having them working at all is rather nice. <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3</a> is kind of in-between. It <em>works</em> on Dual Core, but depending on your device, there's a very small chance of hanging if things go wrong in just the right way. In our limited testing, we were unable to cause any hangs at all in <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3</a>, but some transitions appear to take an abnormally long time, including the initial first door where the game was hanging previously. If this issue is similar to <a href="https://wiki.dolphin-emu.org/index.php?title=Bomberman_Jetters">Bomberman Jetters</a>, it's likely that slightly reducing the Emulated CPU Clock would smooth out any remaining issues if there are any.</p>
<h4 id="50-15586-dont-clear-rtc-flags-on-bs2-reset-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15586/">5.0-15586 - Don't Clear RTC Flags on BS2 Reset</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-15586-dont-clear-rtc-flags-on-bs2-reset-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Some users and developers love using the <a href="https://wiki.dolphin-emu.org/index.php?title=Wii_Menu">Wii Menu (commonly referred to as the System Menu)</a>. It's a lot of fun to go through some of the channels and see various animated game banners that aren't shown from the typical Dolphin GUI. However, if you boot a game and then return to the Wii Menu, the game you were playing wouldn't be present in the Disc Channel. This is because Dolphin was clearing RTC (Real Time Clock) flags on reset, so the emulated console didn't know that it should update the Wii Menu's cache and refresh the inserted disc, leading to stale data being used. <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> made a quick correction to this behavior, so that the correct disc appears in the disc channel after reset.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/discchannel.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/discchannel_thumb.jpg"></a>
<figcaption>Now you don't have to force change disc after every reset to get the correct games to show up.</figcaption>
</figure>
</div>
<h4 id="50-15676-fix-logicops-in-opengles-android-and-moltenvk-macos-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15676/">5.0-15676 - Fix LogicOps in OpenGLES (Android) and MoltenVK (macOS)</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-15676-fix-logicops-in-opengles-android-and-moltenvk-macos-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>This is a workaround for missing LogicOps support in Metal (MoltenVK) and the many mobile drivers (Adreno, Mali, etc.) that do not support the OpenGLES and Vulkan extension. However, this time around, we're not trading one broken game for another; <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> has taken advantage of an improving situation on Android alongside a <em>small</em> hack to MoltenVK to get correct output in LogicOps titles on the afflicted devices.</p>
<p>While <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> is best known for working on Apple features, including a fork of Dolphin designed to run on iOS devices, they've also taken over the burden of helping maintain Dolphin's macOS builds. They've submitted fixes for MoltenVK, helped update the buildbot, and have generally improved the macOS user experience. In this case, they wanted to fix LogicOps features on MoltenVK, but then stumbled into the fact that OpenGLES environments (Android on Non-NVIDIA) suffer from the same problem. A while back, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> added <a href="https://dolphin-emu.org/blog/2019/08/04/dolphin-progress-report-june-and-july-2019/#50-10758-approximate-logic-op-with-blending-if-unsupported-by-stenzek">LogicOps approximation through blending</a> to fix <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> on Windows 7 D3D11 and OpenGLES devices.</p>
<p>Unfortunately, restoring some remedial emulation broke things in other situations, and left some games like <a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a> looking a little dark.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/kirby-broken.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/kirby-broken_thumb.jpg"></a>
<figcaption>The game is still quite playable, if you're used to blindfolded runs.</figcaption>
</figure>
</div>
<p>Why exactly is this happening in <a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a>? To answer that, we need to talk about LogicOps and how they work on the GameCube/Wii. LogicOps (Logical Operations) are a more complex version of Blending operations, allowing a game to perform a wide variety of binary commands in the blending stage. The GameCube and Wii support this natively (based on the OpenGL implementation). In the hardware, they are bitwise operations that use the output color from TEV and/or the current color of the framebuffer and use them in various ways. The result of the operation is then written to the framebuffer and used.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Kirby_Air_Ride">Kirby Air Ride</a> uses the alpha value on the framebuffer to determine where to draw shadows on the screen. At the start of the frame, the game sets the alpha of the rectangle 255. However, it also uselessly uses the SET logic op, which sets the output color to the current TEV color. This is fine if the system supports one of Dolphin's proper LogicOp paths. However, this goes completely wrong under Dolphin's LogicOps approximation with blending path. In this case, Dolphin sets the source and destination factors for the color, but does not set factors for the alpha. This causes the alpha to be set to zero for the entire frame. Even when the game attempts to modify the value to mark where shadows should be drawn, it remains at zero.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/beforelogicopmidframe.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/beforelogicopmidframe_thumb.jpg" /></a>
<figcaption>If we simply disable LogicOps, everything is bathed in shadow.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/logicopmidframe.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/logicopmidframe_thumb.jpg" /></a>
<figcaption>If LogicOps are emulated properly, all of the non-shadowed portions are brightened.</figcaption>
</figure>
</div></div>
<p>If you feed in black rather than the alpha value, instead of lightening the scene, it instead gets shrowded in darkness. Emulating LogicOps with blending is already a last resort, so to improve the situation, <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> had to go another route. With macOS and MoltenVK, Metal does not support LogicOps, so <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> modified our MoltenVK implementation slightly to enable SPIRV-Cross to convert Vulkan's subpass inputs into a framebuffer fetch. This allows Apple Silicon GPUs to support LogicOps, but unfortunately all other macOS GPUs still will not work as they do not support this function. For OpenGLES, there is an <em>extension</em> to support LogicOps, but of course no mobile drivers bother to support it. Instead, we rely on <code>GL_EXT_shader_framebuffer_fetch</code> or <code>GL_ARM_shader_framebuffer_fetch</code>, which can give us the colors of the framebuffer and then we can handle the LogicOps logic in the shader itself. This is slightly slower than native support, but much better than using blending approximation.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/kirby-working.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/kirby-working_thumb.jpg"></a>
<figcaption>And then OatmealDome said, let there be light!</figcaption>
</figure>
</div>
<p><em>Note: The modifications to MoltenVK will not be upstreamed. This is because the behavior we're utilizing is specific to what Dolphin needs. It works for <em>our</em> purposes, but chances are that other programs probably wouldn't want this. Eventually MoltenVK should mature to the point that this hack won't be necessary, but for now this helps make the game's playable on Apple Silicon.</em></p>
<h4 id="50-15680-textureconvertershadergen-set-alpha-to-1-on-intensity-formats-if-efb-lacks-alpha-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15680/">5.0-15680 - TextureConverterShaderGen: Set alpha to 1 on intensity formats if EFB lacks alpha</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-15680-textureconvertershadergen-set-alpha-to-1-on-intensity-formats-if-efb-lacks-alpha-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Sometimes an obscure game can lead you to some rather interesting effects. <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a> was a cash-in port of an already <strong>six year old</strong> PS2 game, <a href="https://en.wikipedia.org/wiki/Rygar:_The_Legendary_Adventure">Rygar: The Legendary Adventure</a> which was a follow up to <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar">Rygar (Arcade)</a>, which is playable on the <a href="https://wiki.dolphin-emu.org/index.php?title=Arcade">Wii Virtual Console Arcade</a>. Based on the reviews people gave to <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a>, that might actually be the better Rygar game on Wii.</p>
<p>And that's just about all the information we could find on this game. However, any game, no matter how good or bad, can become notable to emulation developers. All it has to do is have <em>one</em> thing that confuses everyone. For <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a>, that ended up being what made it fun for us. An <a href="https://bugs.dolphin-emu.org/issues/12763">issue report</a> mentioned that some screens would be washed out in Dolphin, which eventually was tracked down to its bloom effect. Initial experimentation with the effect and how it worked led us to wonder if the effect <em>even worked on console</em>. But, that was easily tested and it turned out that it was yet another weird edge-case.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarbroken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarbroken_thumb.jpg" /></a>
<figcaption>This dark and moody game is looking very washed out.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarfixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarfixed_thumb.jpg" /></a>
<figcaption>The game is supposed to have a much darker tone.</figcaption>
</figure>
</div></div>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> took interest and you can probably guess what happened next if you've been reading these reports. A hunch was quickly surmised that this problem might be related to other visual glitches throughout the game. After testing things in the latest development versions, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> found that the bug was present in most scenes throughout the game with varying degrees of aggressiveness. </p>
<p>Rather than just trying to see what was wrong in Dolphin, they instead did a <a href="https://gist.github.com/Pokechu22/f9c6f22388f1c37570a546b80fdd7ddc">deep dive</a> into exactly how the game was rendering the effect. Once the effect was understood, the answer to what was going wrong would be simple. It turns out the game's bloom actually uses a clever trick to work around a hardware limitation - that the GameCube and Wii can only work with a single framebuffer. If a developer wishes to make other computations using the GPU, such as creating a texture for dynamic shadows, then they will need to draw on top of what's already been drawn on the screen. This is similar to the difficulties and problems <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> ran into when rendering the shadows in <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Spongebob Squarepants: The Battle for Bikini Bottom</a>.</p>
<p>Long story short, because the game was having to render over what it had already rendered, it created an EFB Copy without an alpha channel. Because of that, the alpha channel would return 1, or totally opaque. While that's <em>normally correct</em>, Rygar was making an EFB copy from a texture using an intensity format. While normal textures as EFB copies would <em>usually</em> be 1, when using an intensity format, Dolphin was setting it to zero! This completely changes how things are rendered in <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a>, and is the key to their rather interesting dynamic bloom technique.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarplayable.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/rygarplayable_thumb.jpg"></a>
<figcaption>Rygar: The Battle of Argus still has some nice set pieces throughout it.</figcaption>
</figure>
</div>
<hr />
<p>As custom after running into a unique issue, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> started looking through fifologs and issue reports to see if there were any other bugs that were potentially related. Oddly enough, they stumbled into a <em>much more widely known game</em>: <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Battle_Revolution">Pokemon Battle Revolution</a>! For the past couple of years, it had been suffering with a regression that caused the screen to shift whenever a special effect that used the EFB was on screen.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonbrokencompare.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonbrokenalone_thumb.jpg"></a>
<figcaption>This regression frustrated users, as the black border (right and bottom) would appear during most special effects.</figcaption>
</figure>
</div>
<p>Unfortunately, we had no real leads as to what was wrong, but we didn't end up needing any. Fixing <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a> <em>also</em> fixed <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Battle_Revolution">Pokemon Battle Revolution</a>. However, because no one knew <em>why</em> <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Battle_Revolution">Pokemon</a> was fixed, the job wasn't completely done. It turns out, what was happening here was actually <a href="https://gist.github.com/Pokechu22/e9fa9037fe21312ff32475638b78ba27">two separate bugs</a>, and one of them actually happens on console! The screenshifting a huge amount was a Dolphin bug, but many of the special effects were also broken on console to a degree. That's because the game accidentally crops the bottommost and rightmost row of pixels, and then because of texture clamping, those rows get used for anything that would use content off of the screen.</p>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> found <em>their</em> bug and created a game patch, which caused a bunch of special effects to render like they were intended for the first time.</p>
<div class="media-block" style="max-width:100%">
<div class="row more-padding">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonbrokencompare.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonbrokencompare_thumb.jpg" /></a>
<figcaption>This is how the game was broken in Dolphin before.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonfixedcompare.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonfixedcompare_thumb.jpg" /></a>
<figcaption>Here's what it looks like with the issue fixed, essentially matching the output on console.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonintendedcompare.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/pokemonintendedcompare_thumb.jpg" /></a>
<figcaption>And here is how the effect was originally intended to look, with the game bug patched.</figcaption>
</figure>
</div></div>
<p>And with that, our dive into these two games was complete. . . . Except it wasn't. Shortly after investigating <a href="https://wiki.dolphin-emu.org/index.php?title=Rygar:_The_Battle_of_Argus">Rygar: The Battle of Argus</a>, it was noted that the game no longer worked in the latest development builds, crashing with a backpatch error unless full MMU was enabled. This regression was fixed in <a href="https://dolphin-emu.org/download/dev/ddb3bad9c91300448ed28bc9f5538aaba4b2b019/">5.0-15699</a> to return the game to normal.</p>
<h4 id="50-15928-add-online-wii-system-update-functionality-to-dolphin-on-android-by-simonx22-and-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15928/">5.0-15928 - Add Online Wii System Update Functionality to Dolphin on Android</a></strong> by <strong><a href="https://github.com/Simonx22">Simonx22</a></strong> and <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-15928-add-online-wii-system-update-functionality-to-dolphin-on-android-by-simonx22-and-oatmealdome" title="Permanent link">¶</a></h4>
<p>Another major feature lands in the Android GUI. If you're looking to see some of the Wii's more advanced features or run homebrew, having a full assortment of System Files is necessary. On Android, getting those System Files could be a bit tricky, as actually updating the emulated Wii wasn't as simple as on Desktop versions of Dolphin. <strong><a href="https://github.com/Simonx22">Simonx22</a></strong> and <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> teamed up to rectify this issue, with <strong><a href="https://github.com/Simonx22">Simonx22</a></strong> handling the Android side of things and <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> helping with the C++ part of the implementation.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisystemupdate1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisystemupdate1_thumb.png" /></a>
<figcaption>Performing an Online Wii System Update goes through the same steps as a real Wii would to update.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisystemupdate2.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wiisystemupdate2_thumb.png" /></a>
<figcaption>...Do remember that this does use the internet, though! Watch your mobile data usage!</figcaption>
</figure>
</div></div>
<p>Once you've run a Wii System Update, you'll be able to access the Wii Menu and be able to boot channels, games, and even things like the Open Homebrew Channel!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/freshsystemmenu.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/freshsystemmenu_thumb.jpg"></a>
<figcaption>A "Fresh" Wii NAND running on Android.</figcaption>
</figure>
</div>
<p>For most users, this won't be too important, but it does allow for easy access to the Wii Menu and will allow booting discs and channels from it without the need for a PC for downloading or copying files.</p>
<h4 id="50-15931-disable-unknown-opcode-popup-for-0x1-to-0x7-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15931/">5.0-15931 - Disable Unknown Opcode Popup for 0x1 to 0x7</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-15931-disable-unknown-opcode-popup-for-0x1-to-0x7-by-pokechu22" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Party_5">Mario Party 5</a> players have been complaining to us for <em>many</em> years about a very peculiar bug. "Why does Dolphin crash when I use a Wiggler Orb"? </p>
<p>Technically, Dolphin wasn't crashing, but notifying the user of an unknown opcode. While this did interrupt play, all the user had to do was proceed through the message boxes and the game would keep going as if nothing happened. Over the years we found this to be a harmless occurrence and no cause for concern, but we didn't want to remove the message. After all, it was correct and pointed to a <em>likely</em> bug in Dolphin's GPU emulation.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp5fullnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/mp5fullnative.png"></a>
<figcaption>Console doesn't hang or crash here, so surely this is a Dolphin issue, right?</figcaption>
</figure>
</div>
<p>However we couldn't really investigate the scene further, as Dolphin's Fifoplayer was unable to record scenes with unknown opcodes. At least it wasn't... until very recently. We've said this name a lot, but once again <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong>, has found time between investigating all of these issues to renovate our Fifoplayer with fixes and new features. One such consequence of their fixes is that the Fifoplayer can now record scenes with unknown opcodes. What mysteries would be awaiting us with the Wiggler Capsule after it had evaded our gaze for all of these years? For this, we'll let <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong>'s own writeup explain.</p>
<p><br/>
<blockquote style="font-size:1em;"></p>
<p>Basically, the Wiggler capsule's animation draws a bunch of rings. Each ring has 128 vertices in it, with positions moving around a circle and texture coordinates going up by .03125 (1/32) for each horizontal step. The position, color, and texture coordinate data for each vertex is indexed into several arrays, with the first set of 4 vertices using indices 0, 1, 3, and 2. However, after all 128 vertices are written, the game writes data for 4 more vertices, again using indices 0, 1, 3, and 2. But since the game said it would only draw 128 vertices, not 132, those 4 vertices are instead interpreted as graphics commands. Opcode 0 is a NOP, and my brief hardware testing indicates that opcodes 1-7 are also treated as NOPs, so on real hardware these are ignored, but Dolphin didn't like that extra data. ...</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wigglerfifo.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wigglerfifo_thumb.png"></a>
<figcaption>By isolating an individual ring from the effect, we can see something isn't quite right.</figcaption>
</figure>
</div>
<p>If we modify the FIFO data to say that there are 132 vertices, then the first part of the ring is drawn twice, which indicates that vertices 129-132 normally go unused.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/extravertices.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/extravertices_thumb.png"></a>
<figcaption>If we force render the extra vertices, one section of the ring gets brighter. This means that these vertices really aren't rendered.</figcaption>
</figure>
</div>
<p></blockquote>
<br/></p>
<p>This confirmed a rather exciting event! For the first time in many, many years, this is a case of an "Unknown Opcode" popup actually caused by an Unknown Opcode in a retail, licensed game. Most of the time these popups are disregarded as Dual Core misbehaving or strange GPU timing issues. There's a reason the message written by developers well over a decade ago seemingly disregard that the popup could be caused by an actual unknown opcode.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/unknownop.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/unknownop_thumb.png"></a>
<figcaption>Unlikely, but here we are.</figcaption>
</figure>
</div>
<p>How exactly did this slip by the game's developers? Well, our best guess is this effect was programmed rather haphazardly and developers didn't realize how broken it was. The effect is broken in multiple ways, one of which is <em>visual</em> in the form of a texture defect. While normally this would be very, very difficult to see on console, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> devised a way to use the HW Fifoplayer (a Fifoplayer that runs on an actual console) along with some fancy stitching of XFB copies to create high resolution screenshots on console. This isn't <em>perfect</em> but it does give us a chance to get a very high quality look at how this effect renders on console and confirms that Dolphin is emulating it right.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wigglercapsuleconsole.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/wigglercapsuleconsole_thumb.jpg"></a>
<figcaption>With some advanced techniques and a lot of stitching, we can see that everything renders the same on console. It's a game bug!</figcaption>
</figure>
</div>
<p>With this game's issues fully understood and Opcodes 0x1 -> 0x7 confirmed to be Nops (No Operation), the Unknown Opcode popups have been disabled for these Opcodes. This means that in the latest development builds, you no longer have to worry about the Wiggler Capsule causing any interruptions to your gameplay experience. As this is a strange behavior, Dolphin will continue to log Unknown Opcodes 0x1 -> 0x7 behind the scenes as it can give us a clue toward other bad behaviors and potential visual issues.</p>
<h4 id="50-15936-android-alternative-infrared-pointer-control-by-lynxnb"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15936/">5.0-15936 - Android: Alternative Infrared Pointer Control</a></strong> by <strong><a href="https://github.com/lynxnb">lynxnb</a></strong><a class="headerlink" href="#50-15936-android-alternative-infrared-pointer-control-by-lynxnb" title="Permanent link">¶</a></h4>
<p><strong><a href="https://github.com/lynxnb">lynxnb</a></strong> returns with another Android centric change, this time an alternative control scheme for Touchscreen Pointer. Currently in Dolphin, you control the IR pointer by touching the screen, and then the cursor moves to the approximate point your finger tapped. This isn't very exact due to how different games are calibrated differently, and how large fingers are relative to the targets on screen. This change adds a second mode, where instead of the Infrared Pointer following your finger's position, it instead follows your finger's movements - like a touchpad. This is especially useful in shooters where you're going to do a lot of turning. </p>
<h4 id="50-15974-android-add-support-to-importexport-user-files-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15974/">5.0-15974 - Android - Add support to import/export User Files</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15974-android-add-support-to-importexport-user-files-by-josjuice" title="Permanent link">¶</a></h4>
<p>The <a href="https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/#50-15438-android-comply-with-scoped-storage-requirements-by-josjuice">Scoped Storage</a> situation on Android has turned out to be a confusing, frustrating place for both users and developers alike. Depending on your phone, manufacturer, and the version of Android that you're on, your experience with Scoped Storage and its problems are going to vary. Some manufacturers seem to lock down app specific directories <em>entirely</em>, even preventing users from copying files in from a desktop computer. This means that users can't copy in saves, setup Riivolution mods, or backup their data in a meaningful way whatsoever. Given that this was a rather dire situation, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> decided to rush in an option that will at least give users <em>something</em> they can use to import and export their user settings.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/importexportandroid.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/importexportandroid_thumb.png"></a>
<figcaption>Under "Config/User Data" you now have the option to import and export User Data.</figcaption>
</figure>
</div>
<p>Do note that we're not going to implement our own file manager <em>just</em> to handle user settings. Currently, Dolphin can import .zip files that contain the user directory. A "Dolphin.ini" must be present in the "Config" folder for it to be considered valid user data. Do note that importing User Data will overwrite and delete all existing User Data. When exporting your User Data, it will be exported into the same kind of zip file that Dolphin expects for importing, so you can use that as a guide to see how the zip file should be laid out. Currently, support is a bit spotty, so making as "basic" of a compressed zip file as possible is for the best. We'll continue to explore other avenues for managing User Data now that we know this is going to be a problem from here on out.</p>
<h4 id="50-15862-panic-alert-improvements-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15862/">5.0-15862 - Panic Alert Improvements</a></strong> by <strong><a href="https://github.com/pokechu22">pokechu22</a></strong><a class="headerlink" href="#50-15862-panic-alert-improvements-by-pokechu22" title="Permanent link">¶</a></h4>
<p>This is an overhaul that was quite overdue. Essentially, Dolphin's Panic Alert system had a few <em>minor</em> bugs. Namely, sometimes they wouldn't display all of the information we intended and translations weren't working, meaning even though some of the Panic Alerts <em>were</em> translated, the translations would never get shown regardless of the user's language. In between solving all of those crazy graphics bugs, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> found time to fix them up a bit.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/panicbefore.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/panicbefore_thumb.png" /></a>
<figcaption>This Panic Alert says the bare minimum, but it could be better.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/panicafter.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/panicafter_thumb.png" /></a>
<figcaption>And now in the latest builds, that better has finally come.</figcaption>
</figure>
</div></div>
<h3 id="port-settings-to-new-configuration-system-by-admiralcurtiss"><strong>Port Settings to new Configuration System</strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#port-settings-to-new-configuration-system-by-admiralcurtiss" title="Permanent link">¶</a></h3>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:25%; min-width:150px; float:right; text-align:center;">
<a style="text-decoration: none;" href="https://openclipart.org/detail/175418/cut-onion">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-june/Onion.svg">
</a></div>
<p>We haven't talked about the new configuration system in quite a while. To be honest, it's actually not that new anymore, now is it? This summer, it'll actually be five years old, the <em>Layered Configuration System</em> (Layered Config) is a more powerful configuration system that allows layers of overrides while also keeping multiple settings in mind. <a href="https://dolphin-emu.org/blog/2017/07/01/dolphin-progress-report-june-2017/#50-4171-videoconfig-port-to-layered-configuration-system-by-merrymage">To harken back to a simpler time</a>, Layered Config is an overlay configuration system with multiple layers - like an onion - and each layer lays over the one beneath it. Even though Dolphin only acts on the final result of all of the layers, each layer exists at all times in the config system, allowing Dolphin to know what settings layer is affecting what and why. This allowed users to make changes on the fly, without actually overriding the defaults as soon as they opened the menus. Unfortunately, once the important settings were ported over, progress of moving things over to Layered Config stalled and we have <em>two</em> active configuration systems for the past five years. The classic, fast, but limited <strong>SConfig</strong>, and the newer, more robust, but sometimes difficult to optimize <strong>Layered Config</strong>.</p>
<p>The fact that Dolphin has two very different Configuration Systems has led to a bit of technical debt, and has limited Dolphin's ability to move forward in some ways. Want a "Return to Default Settings" button? Well, that's not easy to do because there are two active configuration systems. Want to add a certain setting to your Game Config? SConfig settings aren't guaranteed to work in GameINIs! Want to change a setting while playing Dolphin on Android? Well, if that setting is handled by SConfig, odds are you'll have to stop emulation first. The list goes on, but simply moving everything over was a rather big task.</p>
<p>In recent months, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> has taken the mantle to <em>finally</em> remove all of the remaining reliances on SConfig and simplify Dolphin's configuration system in general. The end goal of all of this will be new, easier ways to manage Dolphin's settings so that you don't need to be an expert to get the most out of your Dolphin experience. But right now, we're still porting over a few stragglers in preparation for bigger things. Stay tuned.</p>
<h3 id="redump-has-made-the-wii-database-public"><strong>Redump Has Made the Wii Database Public!</strong><a class="headerlink" href="#redump-has-made-the-wii-database-public" title="Permanent link">¶</a></h3>
<p>While this isn't directly a <em>Dolphin</em> change, it's a change that affects disc verification. Dolphin's disc verifier can now verify good dumps of Wii games by making use of the <a href="http://redump.org/">redump.org</a> Wii database. In builds with the disc verification feature, notice that Dolphin can now tell you when you're using a good dump of a Wii game. This actually extends backwards to builds <em>before</em> the database was public, as the functionality had been prepped for this eventual release.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/verifywii.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/verifywii_thumb.png"></a>
<figcaption>You can finally be sure if you're using a good dump for Wii games.</figcaption>
</figure>
</div>
<h3 id="macos-gets-some-love"><strong>macOS Gets Some Love</strong><a class="headerlink" href="#macos-gets-some-love" title="Permanent link">¶</a></h3>
<p>macOS has been in an odd position with Dolphin the past few years. We've had to deal with Apple deprecating their already neglected OpenGL support, ignoring Vulkan to set up their own graphics API, and Bluetooth changes to macOS 12 Monterey that took connecting Real Wii Remotes from <em>occasionally possible on a good day</em> to <strong>no chance in hell</strong>. Add in their strict security measures, and it's been very difficult to give users on macOS a good experience when using Dolphin. While there are still some problems, <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong>, along with a few others, have taken up the mantle of maintaining and renovating macOS support in Dolphin. These past three months saw two significant steps forward for the OS.</p>
<h4 id="maybe-someone-should-have-checked-that"><strong>Maybe someone should have checked that</strong><a class="headerlink" href="#maybe-someone-should-have-checked-that" title="Permanent link">¶</a></h4>
<p>Under macOS, our official minimum supported version is macOS 10.13 High Sierra. We do have a High Sierra system on hand for verification, however, after the recent move to the new Universal Builds, we never actually got around to trying those builds on the High Sierra machine. Intel machines were tested, of course, but never ones running older versions of macOS. Since Universal Binaries go all the way back to macOS 10.4.4 Tiger, we weren't worried about it.</p>
<p>Six months after the Universal Builds were introduced and two months after the Intel-only mac builder was turned off, we recieved an <a href="https://bugs.dolphin-emu.org/issues/12752">issue report</a> of macOS failing to launch on a macOS 10.14 Mojave system. Well, there was only one way for us to respond. After digging through a shelf and wiping off some dust, the High Sierra system was retrieved and finally got to see the new Universal Builds. They didn't work. With great irritation our eyes immediately glared toward Qt, after all it was what forced us to a minimum of High Sierra in the first place, but Qt wasn't to blame. <strong><a href="https://github.com/tellowkrinkle">TellowKrinkle</a></strong> found that the Universal builder was set up with a new SDL version that had a minimum support of <strong>macOS 11</strong>, a year-old version of macOS. That's not acceptable at all! Fortunately, once this issue was discovered it was pretty simple to resolve, and now the latest builds of Dolphin run on High Sierra once again. </p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/2012macbook2.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/2012macbook2_thumb.jpg"></a>
<figcaption>A 2012 MacBook Pro running 2022 Dolphin!<br/><sub>Almost ten years old now, this venerable laptop has spent its entire life serving Dolphin, from programming work initially to over five years writing Dolphin blogs, to now helping maintain the bounds of macOS support. It was even the sole macOS testing device for <strong>years.</strong> This MacBook has probably helped Dolphin more than any other single machine, and hopefully it will continue to do so for many more years to come.<sub></figcaption>
</figure>
</div>
<h4 id="notorious-notarizing"><strong>Notorious Notarizing</strong><a class="headerlink" href="#notorious-notarizing" title="Permanent link">¶</a></h4>
<p>Our macOS builds have been signed for years and years, so Gatekeeper's slowly tightening jaws didn't matter to us. That was until macOS 10.14.5 turned on the notarization requirement. Signing your application was no longer enough, now macOS developers were expected to also send a copy of their builds to Apple to have Apple themselves scan it for malware and verify the signing key. We were not very enthusiastic about these strict new requirements. It clashed with our buildbot systems of the time and it would have been non-trivial to implement, so the maintainer chose to not to. Unfortunately for our users, that meant that Gatekeeper now treated our builds as if they weren't even signed.</p>
<p>So for the past two years, users could not simply double click to open new Dolphin builds. Gatekeeper would complain saying that it could not be sure that it was safe and refuse to let Dolphin load. To bypass this, users had to ctrl-click Dolphin and click Open, then click Open in the resulting prompt. Then Dolphin would open... or the prompt would disappear and require the user to double click on Dolphin manually. If anyone knows why it did that sometimes please let us know, that quirk made explaining this process to new users an absolute nightmare.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/gatekeepersaysno.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2022-january/gatekeepersaysno.png"></a>
<figcaption>Every macOS Dolphin user has seen this screen <em>A LOT</em>.</figcaption>
</figure>
</div>
<p>Regardless of the problems of the past, <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> sorted out most of the pain with notarization and the new Universal buildbot was painlessly updated to include it. Now the latest builds will run on macOS <em>without</em> all of those annoying popups and workarounds. Just double click Dolphin and it works, how novel!</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-11-01&to=2022-02-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-15448/">5.0-15448</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-15993/">5.0-15993</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: September and October 2021
2021-11-13T07:36:31+00:002023-02-15T09:31:00.494961+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2021/11/13/dolphin-progress-report-september-and-october-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/progressreportheader-oct2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/progressreportheader-oct2021mini.jpg" />
</header>
<p>It's the beginning of the month and time for another Dolphin Progress Report! ...That line doesn't exactly work when it's midway through the month, huh? This Progress Report ended up being a very technically challenging report to write with several huge rabbit holes that go through the history of Dolphin and the games themselves. The first rabbit hole showcases TMEM, the GameCube and Wii's texture cache. Dolphin's approach to emulating this bit of the hardware has been to effectively ignore it exists. Trying to even <em>begin</em> to rectify the problems with this approach and explain the reasoning behind why it <em>sort of</em> wasn't emulated go very, very deep. This Progress Report also contains collaboration with the <a href="https://pcsx2.net/">PCSX2</a> development team as they helped us understand some of the behaviors of Floating Point Math on the PlayStation 2. The fact that the PlayStation 2's floating point behaviors mattered to us for this Progress Report <em>should</em> tell you the kinds of things we were up against when writing up the changes.</p>
<p>If that wasn't enough, Dolphin also welcomed support for a wealth of mods through support for <strong>Riivolution</strong>. An easy to use GUI for launching Riivolution mods was added both to desktop Dolphin builds <em>and</em> Android. Speaking of Android, users may have noticed we pushed out an early beta last month. This beta was mostly to showcase and let users on the Play Store try out the newly finished Cheat GUI! We'll finally showcase that after a lengthy delay between when that extra beta was pushed and this Progress Report. While it's not related to Dolphin <em>directly</em>, Apple released the new M1 Max and we got our hands on one to see how it stacks up against the M1 with some rather interesting performance numbers at the end of the report.</p>
<p>With that out of the way, there's no point in delaying things any further. Please enjoy these rather lengthy Notable Changes!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-15178-android-update-gui-for-cheat-management-and-creation-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15178">5.0-15178 - Android: Update GUI for Cheat Management and Creation</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15178-android-update-gui-for-cheat-management-and-creation-by-josjuice" title="Permanent link">¶</a></h4>
<p>Dolphin has the ability to hook in various types of cheat codes and patches, so even though the Android version lacked the GUI for it, it has always had the ability to use cheat codes. For the past couple of years, enterprising Android users have gone through the trouble of setting up cheat codes by hand through text editors or using the Desktop version to create the settings files they wanted. Some forks of Dolphin even hooked a <em>conventional text editor</em> into the program to try and make editing cheats easier! But all of these stopgaps weren't actual solutions, they were working around the problem. Someone had to get down and dirty and make serious additions to the Android GUI if we were to ever have a permanent solution.</p>
<p><strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has been dealing with <a href="https://dolphin-emu.org/download/dev/master/5.0-14066/">Android</a> <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14203-android-fix-controller-inputs-not-saving-properly-by-josjuice">issues</a> <a href="https://dolphin-emu.org/blog/2021/04/05/dolphin-progress-report-february-and-march-2021/#50-13944-add-gpu-syncing-options-to-android-gui-by-josjuice">for</a> <a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#50-13386-use-storage-access-framework-scoped-storage-for-the-gamelist-on-android-by-josjuice">quite</a> <a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#50-13440-make-wii-save-import-behave-more-like-sd-import-by-admiralcurtiss-and-50-13562-android-add-wii-save-import-functionality-by-josjuice">some</a> <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#the-android-user-experience-overhaul">time</a>, and has become more familiar with the JNI (Java Native Interface) that powers the Android GUI. Much like how DolphinQt calls into Dolphin to handle things like enabling/disabling cheats and editing GUIs, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> completely replicated Dolphin's Cheat interface without duplicating the core code within Android. This means all of the same features that you already enjoy on desktop related to enabling, disabling, and adding cheats are all there, and work exactly the same!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidcheatsui.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidcheatsui_thumb.png"></a>
<figcaption>The cheats menu finally arrives in Android.</figcaption>
</figure>
</div>
<h4 id="50-15438-android-comply-with-scoped-storage-requirements-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15438">5.0-15438 - Android: Comply with Scoped Storage Requirements</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15438-android-comply-with-scoped-storage-requirements-by-josjuice" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:15%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>The fated day has finally come. <a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#50-13386-use-storage-access-framework-scoped-storage-for-the-gamelist-on-android-by-josjuice">Nearly a year ago</a> we expressed our frustrations with the upcoming Scoped Storage requirement in Android. Since then... not much has changed about our concerns, but <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has done their best in order to make sure the experience of Dolphin on Android doesn't change much. The main difference is that Dolphin is now locked to using an app-specific directory for a majority of its user files on Android 11 and up.</p>
<p>Unlike some other emulators, Dolphin does not have the option to simply ask for permission to use other directories. For managing things like the Wii NAND and GameCube GCI folders, Dolphin is reliant on accessing tons of files in quick order. If access to those files is too slow, the user may see noticeable lag, or in dualcore games could even crash. When using directories <em>other than the app-specific one</em>, performance on accessing files is terrible, so much so that it would impact emulation in a negative manner. This doesn't apply to your games however, as when using most game formats in Dolphin, you're only accessing a single file. The main culprit in Scoped Storage performance issues is dealing with <em>many smaller files</em>.</p>
<p>Using the app-specific directory may not seem like a big deal, but there are some tricky things to keep in mind. First of all, you will have an <a href="https://www.reddit.com/r/Android/comments/j3zgmm/managing_files_in_the_androiddata_folder_on/">incredibly difficult</a> time trying to copy files into the app-specific directory with the default file manager on Android 11 and up. This is problematic as things like the Wii NAND and Texture Packs need to be in the app-specific directory. The good news is, if you have a PC, you can connect your phone and navigate to the new directory (Android/data/org.dolphinemu.dolphinemu/files/) the same as the old one on most devices. Some users have reported difficulties editing these folders on certain devices, but we've been unable to verify the reports to this point. While this may be a bit frustrating, our biggest fear with Scoped Storage was that, by default, uninstalling Dolphin would <em>delete user files including save data</em>. Thankfully, there is a work-around to that problem provided by Android called <em>fragile userdata</em>. Essentially, we mark the files in Dolphin's app-specific directory as fragile, so if you uninstall Dolphin to downgrade, bisect, or do something else where you would want to reinstall it later, Android will ask you if you want to keep the App's data files. <strong>This only works when uninstalling from Android itself; if you uninstall from the Play Store you will lose all of your data</strong>.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/scopestoragedelete.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/scopestoragedelete_thumb.png"></a>
<figcaption>If you want to protect your savefiles and other user data when uninstalling Dolphin, make sure to *not* delete your user data!</figcaption>
</figure>
</div>
<p>There is one other exception we should note. Scoped Storage does not apply to you if you upgrade from an older version of Dolphin <em>without ever uninstalling it</em>. So if you download <a href="https://dolphin-emu.org/download/dev/207c931a04c8e2629a735bc2b3f36b5c89365ca7/">5.0-15260</a>, for example, and then just continually upgrade without ever uninstalling, then Scoped Storage won't come into effect for you until Google closes this loophole. Though going through that trouble shouldn't really be necessary as all of the known issues have already been quelled. Unless you <em>specifically</em> need things like custom directories for tons of Wii NANDs that cannot be within the app-specific data directory for some reason, you shouldn't see much of a difference if any with the latest builds.</p>
<p>For more information on if Scoped Storage affects you, please check <a href="https://wiki.dolphin-emu.org/index.php?title=Controlling_the_Global_User_Directory#Android">Dolphin's Wiki</a>.</p>
<h4 id="50-15249-add-broken-dual-source-blending-bug-to-moltenvk-on-intel-gpus-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15249/">5.0-15249 - Add broken dual source blending bug to MoltenVK on Intel GPUs</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-15249-add-broken-dual-source-blending-bug-to-moltenvk-on-intel-gpus-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>MoltenVK was introduced to Dolphin 3 years ago, and it has since become the defacto backend for macOS users wanting to play games in Dolphin. However, it hasn't exactly been smooth sailing. In many games, such as <a href="https://wiki.dolphin-emu.org/index.php/Super_Mario_Galaxy">Super Mario Galaxy</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Colors">Sonic Colors</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Paper_Mario_(Series)">the Paper Mario games</a>, have considerable geometry flickering when MoltenVK is used on some Macs.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/soniccolors-flicker.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/soniccolors-flicker_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>This got old pretty fast.</figcaption>
</figure>
</div>
<p>We assumed it was a MoltenVK bug and ignored it, thinking that it would be fixed eventually in a MoltenVK update. After the issue remained for three years, macOS and iOS veteran <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> decided to look into this longstanding issue and sus out the source. It turns out it MoltenVK wasn't the issue at all, but <em>Intel's macOS graphics drivers</em>. On newer Macs with Intel Graphics, if <code>ocol1</code> is present in the fragment shader and dual source blending is enabled, entire primitives will not be written to the depth buffer if any fragment is discarded. There's our flickering. Fortunately (or unfortunately), we have already experienced dual source blending issues on other drivers, so we already have a fallback path set up that only allows dual source blending when absolutely necessary. <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> added Intel Graphics on macOS to the list and now the flickering is gone.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/soniccolors-deflicker.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/soniccolors-deflicker_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Now Mac owners with newer Intel Graphics finally can play games without flickering!</figcaption>
</figure>
</div>
<h4 id="50-15294-extend-minimal-tmem-cache-implementation-by-phire"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15294">5.0-15294 - Extend Minimal TMEM Cache Implementation</a></strong> by <strong><a href="https://github.com/phire">phire</a></strong><a class="headerlink" href="#50-15294-extend-minimal-tmem-cache-implementation-by-phire" title="Permanent link">¶</a></h4>
<p>In the early years of Dolphin's life, developers were very limited in what they could do to emulate the GameCube and Wii. These consoles are quite different from PCs, and most of the tricks that today's computers can use to work around these differences simply didn't exist back then. So developers did whatever they had to, and usually that meant <em>hacks</em>, but sometimes that even meant <em>not</em> emulating something if that happened to work. Now that proper emulation is possible, for the past eight years Dolphin has been unraveling those knots, replacing hacks with better solutions as they come up. However, a lot of these old tricks still remain, especially in cases where they aren't a major source of issues and/or where the work required to replace them would be very high. And one of those such places is emulating the GameCube and Wii's texture cache - TMEM. </p>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:25%; min-width:72px; float:right; text-align:center;">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/flipperdieshot_zoom.png"><img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/flipperdieshot.jpeg">
</a>
<p><a href="https://www.ign.com/articles/2001/10/12/ati-discusses-flipper-part-2"><sub>SOURCE</sub></a></p>
</div>
<p>Texture Memory (TMEM) is a 1MiB piece of super fast SRAM that lives within the consoles' GPU. Not large enough to hold a frame but much faster than going to Main Memory (10.4 GiB/s for TMEM vs 2.6 GiB/s to Main Memory), TMEM by default operates as a hardware-managed texture cache that is completely transparent to the game. In this hardware mode, TMEM sits inbetween Main Memory and the GPU and caches every 32 byte texture chunk it can, so if the GPU asks for a texture that happens to be in TMEM, TMEM will provide it instead of Main Memory and the GPU gets it much faster. There are limitations to this of course. While TMEM is HUGE for a texture cache of the period (the PS2's texture cache is 8KiB, for reference), it can still only hold so much, so texture chunks are constantly flowing in and out of the cache every frame. Also, the game can edit textures in Main Memory at any time and TMEM will never know. As such, TMEM is expecting games to explicitly order a TMEM invalidation in this event.</p>
<p>Dolphin ignored all of that. In fact, it ignored that the consoles even have a texture cache. Instead, Dolphin <em>kind of</em> replaced the TMEM's hardware mode with <em><strong>Dolphin's Texture Cache</strong></em>.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/luigiscream.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/luigiscream_thumb.jpg"></a>
<figcaption>A Dolphin developer after hearing "Dolphin's Texture Cache".</figcaption>
</figure>
</div>
<p>Textures straight from the GameCube or Wii will not work on modern GPUs; Dolphin needs to convert them. This takes time and processing power, so Dolphin stores converted textures in a cache on the host GPU for a long time to make the most of this work. However, this cache would balloon to enormous scale if it isn't constantly pruned as even the tiniest variation is stored as a separate texture in the cache, so Dolphin has a <em><strong>horrifying cacophony</strong></em> of heuristics to guess what textures a game will or won't use every frame. It's terrifying, and no sane Dolphin developer <em>will even go near it.</em></p>
<p>In Dolphin, it is Dolphin's Texture Cache, not TMEM, that is sitting inbetween the GPU and Main Memory. As such, Dolphin's Texture Cache should be respecting TMEM's behaviors to be accurate. It wasn't. Instead, every draw call Dolphin simply hashed all textures in Main Memory, and if the hash didn't match, Dolphin would invalidate the cached copy. That's it. This is what Dolphin does for <em>every texture</em> already, so Dolphin is more or less ignoring that the consoles have their own texture cache at all. Yet for the majority of Dolphin's catalog, this is fine. As TMEM's hardware-mode texture cache is transparent to the game anyway, Dolphin could just take the texture caching job and implement it in a way that worked best for Dolphin, and everything just worked. <em>Mostly.</em></p>
<p>Four years ago <strong><a href="https://github.com/phire">phire</a></strong> discovered one of the limitations of this strategy. <a href="https://wiki.dolphin-emu.org/index.php?title=Spyro:_A_Hero%27s_Tail">Spyro: A Hero's Tail</a> has a highly complex SDR bloom effect which uses 16 EFB copies to build, where it reads the screen then blurs and brightens multiple copies of what it read before stacking them all on top of eachother for scanout to the screen. As it is manipulating textures in Main Memory, the game dutifully invalidates TMEM along the way - except for one step.</p>
<p>In one of the stages of the process, <em>A Hero's Tail</em> orders the GPU to scale a texture from Main Memory up to twice the size. While performing this operation the GPU reads the texture in Main Memory, and TMEM automatically caches it. Then the game EFB copies the 2x version over the original copy in Main Memory while explicitly NOT invalidating the cached version in TMEM. The game then reads from the 1x original in TMEM to generate another texture which it writes elsewhere in Main Memory, then invalidates TMEM. This is a bit of an abuse of the GameCube hardware to help build a complex effect. Dolphin, however, couldn't do this. Dolphin's "emulation" of hardware-mode TMEM and Dolphin's Texture Cache for converted textures in Main Memory <em>are one and the same</em>; it ignored that the consoles have a seperate cache that may have different contents than Main Memory. If something was changed in Main Memory, the version in Dolphin's Texture Cache was automatically changed too. So in Dolphin, when Spyro overwrote the texture in Main Memory with the 2x version, Dolphin did just that, but there was no other cache that still contained the 1x version. When the game tried to read the 1x size version from TMEM, Dolphin's Texture Cache gave it the 2x version instead, breaking the bloom effect. </p>
<div class="media-block wider">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-bug1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-bug1_thumb.jpg" alt="spyro-bug1.png" /></a>
<figcaption>Store EFB Copies to Texture Only resulted in bloom haphazardly dragging across the screen.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-bug2.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-bug2_thumb.jpg" alt="spyro-bug2.png" /></a>
<figcaption>Store EFB Copies to Texture and RAM resulted in bloom nonsensically flickering anywhere it felt like it.</figcaption>
</figure>
</div></div>
<p><strong><a href="https://github.com/phire">phire</a></strong>, as later cleaned up by <strong><a href="https://github.com/mimimi085181">mimimi</a></strong>, dealt with this by adding a backdoor that allows Dolphin to bypass the hash check if a heuristic determines it is safe to do so. With this, some changes to cached textures are allowed to occur without invalidating the cached copy as long as the texture was the same size, the same address, and no explicitly requested TMEM invalidation took place. Since <a href="https://wiki.dolphin-emu.org/index.php?title=Spyro:_A_Hero%27s_Tail">Spyro: A Hero's Tail</a>'s bloom fell within that criteria, Dolphin now keeps both the 1x version of the texture and the 2x version of the texture in Dolphin's Texture Cache, allowing the bloom effect to be built correctly.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2017-august/spyro-working_thumb.jpg"></a>
<figcaption>Bloom now works in EFB Copies to Texture+RAM, and works with EFB Copies to Texture Only as long as you aren't underwater. That's a different bug.</figcaption>
</figure>
</div>
<p>This isn't proper hardware-mode TMEM emulation, not even by a longshot. Dolphin's wildly different texture caching approach is still there - the patch essentially added a dirty heuristic to “do the right thing” in an edge case. But this was still an important step toward accurate emulation, as it broke Dolphin’s longstanding assumption that textures were always fetched directly from Main Memory and introduced basic awareness of TMEM.</p>
<p>However, there is a reason why no one wants to touch Dolphin's Texture Cache. After this change, a slow trickle of regressions started to flow.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/uhoh.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/uhoh.png"></a>
<figcaption>Uh oh.</figcaption>
</figure>
</div>
<p>The common thread through most of these games is FMVs. Their videos would become stuck, only playing audio. While the games themselves didn't freeze, this regression made it frustrating to play certain games or impossible in the case of <a href="https://wiki.dolphin-emu.org/index.php?title=NHL_Slapshot">NHL Slapshot</a>.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/zerogravityfmv-broken.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/zerogravityfmv-broken_thumb.png"></a>
<figcaption>Imagine a bunch of music and sound effects playing behind this for a few minutes.</figcaption>
</figure>
</div>
<p>So what are these FMV games doing differently from other games with FMVs? Normally, games will store many frames in a buffer in Main Memory, streaming a frame at a time as it goes through the buffer. Once it reaches the end of the buffer, it loops around to the beginning where new frames are waiting. That method of FMV streaming still worked fine after the heuristic was added. But the games above (minus <a href="https://wiki.dolphin-emu.org/index.php?title=NHL_Slapshot">NHL Slapshot</a>) share a common FMV library that, in a curious choice, has a buffer in Main Memory of <em>one frame</em>. To the GameCube and Wii's GPU it appears that the same texture is being reused over and over again, because technically <em>it is;</em> the texture is just being updated outside of the GPU's awareness. However, it is hardware-mode TMEM's job to cache textures that are used repeatedly, and it does indeed cache this texture. If TMEM delivered that cached frame, the FMV would become stuck just like Dolphin did after adding the heuristic. However, each frame is too large to fit into TMEM. Once TMEM is full, it just keeps caching, replacing the first parts of the texture with new parts. After the draw call is complete and the GPU asks for the frame again, TMEM notices that it doesn't contain the first parts of the texture, so TMEM lets the GPU get it from Main Memory instead. The FMV library doesn't even need to worry about explicitly invalidating TMEM, as the size limitation naturally invalidates it and prevents the cached frames from appearing on screen.</p>
<p>Dolphin's Texture Cache, however, didn't care at all about hardware-mode TMEM or the fact that it has limited space. It cached the entire texture, and when the GPU called for it again, Dolphin's Texture Cache provided it. And over and over it goes, displaying the first frame of the FMV over and over again until the FMV is done. Before the addition of the heuristic, Dolphin was <em>so simple</em> it managed to escape this trap. The hash check caught the changing contents of the texture in Main Memory and <em>coincidentally</em> followed the pattern the game expected by invalidating the cache texture after the frame was changed. But the heuristic determined (correctly) that the same texture was being reused and bypassed that hash check, allowing it to be cached and breaking the FMVs.</p>
<p>To fix this, Dolphin was going to need to start caring about what fits into TMEM. <strong><a href="https://github.com/phire">phire</a></strong> returned to do just that, with an expanded version of their original work that make's Dolphin's hardware-mode TMEM emulation able to keep track of the contents of TMEM and whether or not an incoming texture is too large for it. This allows Dolphin's TMEM hash bypassing heuristic to be much better at estimating whether or not an invalidation is necessary, and brings Dolphin a little bit closer to actual hardware-mode TMEM emulation. </p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/zerogravityfmv-working.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/zerogravityfmv-working.png"></a>
<figcaption>Now we can see the FMVs in their full motion-captured glory once again.</figcaption>
</figure>
</div>
<p>The odd one out for this whole case is <a href="https://wiki.dolphin-emu.org/index.php?title=NHL_Slapshot">NHL Slapshot</a>. It's bug is not related to FMVs at all, instead, it has columns of static graphics during gameplay. We're not completely sure what's going on with this one. We know it is also not respecting the TMEM invalidation rules, and that it is continuously reusing a texture like the FMVs did, presumably for some sort of post-processing effect. But it was fixed before we got the chance to look into it in detail.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/slapshot-broken.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/slapshot-broken_thumb.jpg"></a>
<figcaption>This is not playable.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/slapshot-working.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/slapshot-working_thumb.jpg"></a>
<figcaption>Now the players are much more visible.</figcaption>
</figure>
</div></div>
<p>Of course, this is still yet another patch for our not-emulation of TMEM. Rather than actually emulating TMEM so quirks in its behaviors just occur naturally, we're manually accounting for those quirks and stepping in to force it to work. This approach is fixing games, but it is a very unsatisfying solution that is definitely not ideal. It is <strong><a href="https://github.com/phire">phire's</a></strong> intention to eventually remake this whole system and genuinely emulate TMEM. It won't be easy, but it is possible with modern APIs. <strong><a href="https://github.com/phire">phire</a></strong> promises it will be done within this century, so we wait with bated breath.</p>
<h4 id="50-15330-raise-program-exceptions-on-floating-point-exceptions-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15330">5.0-15330 - Raise Program Exceptions On Floating Point Exceptions</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-15330-raise-program-exceptions-on-floating-point-exceptions-by-josjuice" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> has shown up on the Dolphin Progress Report a <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#the-mmu-swapping-code-into-and-out-of-aram">couple</a> of <a href="https://dolphin-emu.org/blog/2020/02/07/dolphin-progress-report-dec-2019-and-jan-2020/#50-11318-add-memory-management-unit-settings-to-main-gui-and-disable-by-default-by-josjuice">times</a> now. It's been laughed at for being an incredibly buggy, broken game, that was a stress test for Dolphin's memory management due to how much it swapped data and code between MEM1 and ARAM. But there was another intriguing thing about the game: the game would instantly crash in Dolphin when standing on any kind of dynamic object and no one knew why. This was the primary reason why people within the project knew the game existed, and over the course of seven years, developers spent <em>hundreds</em> of hours debugging the issue. Just glancing at it, we thought it was a typical bad game, but the more we were able to play it the more we realized just how wrong we were.</p>
<p>From the outside, the issue plaguing Dolphin seemed to be simple enough. The game ran fine, but any time your character contacted a physics object, the game would freak out and send you out of bounds. Because of a separate JIT bug, Dolphin would then crash. This isn't especially surprising to see in an emulator, as improperly emulating a CPU instruction can result in the wrong values being passed and eventually result in strange clipping issues or other problems that compound into the catastrophic failure you see here. For the longest time, we thought there was a bug somewhere in Dolphin's CPU emulation but we didn't have many leads. Thankfully, the game <em>actually</em> has a (semi) functional debug menu that let us examine the actual positional coordinates of the player during the crash!</p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls muted playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrime-debug_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Pause, go to the map screen. Hit right, then Hold L and R as it transitions and then tap left to access the debug menu. <br/><sub>Click to play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrime-debug.mp4">here</a> for fullsize.</sub></figcaption>
</figure>
</div>
<p>Unknown issues to developers are like a lamp is to mosquitos. The fact that no one knew what was going wrong just made it all the more enticing to fix! <strong><a href="https://github.com/booto">booto</a></strong> literally followed a bad NaN (Not a Number) value backwards through tons of functions before eventually finding an operation on an INF (Infinite) that came from a divide by zero, but even then it didn't seem like Dolphin was doing anything wrong. As far as everyone could tell, Dolphin was behaving correctly. By the time 2020 rolled around, <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#50-12575-jit-codegen-space-reuse-by-admiralcurtiss">developers started to realize this was anything but an ordinary game</a>. Rather, it had a <em>special</em> quality about it. At first developers lashed out against it, calling it garbage game that was poorly coded. And why wouldn't they? The game <em>is</em> super buggy and barely functional on console. In fact, the game will <em>crash</em> if you try to debug it with a USB Gecko, meaning that we couldn't even test to see what was happening in memory on console. All seemed lost... when something amazing happened.</p>
<p><strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong>, after having felled several other difficult problem games, decided that <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> was worth a look. From there, they realized a rather sickening truth: The fact that the physics engine was dividing by zero wasn't a bug in Dolphin. It was all part of the game's plan. On Dolphin, these DIV0s would result in INFs, which then would become NaNs when used in other math operations that would result in the crashes. Until this point, we thought the way to fix the NaNs would be to stop the DIV0s, but <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> realized that the <em>game itself</em> was using a custom Floating Point Exception handler to catch DIV0 exceptions and stop the INFs/NaNs from happening. Throughout the entire GameCube/Wii library, no one had run into anything like this so there was some skepticism that this was really happening, but the evidence was pretty strong. </p>
<p>Rather than investing a ton of time modifying Dolphin to support a custom Floating Point Exception handler without even knowing if the hypothesis was correct, <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> instead hacked up the JIT to replicate what the Floating Point Exception Handler in <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> would have done. Paydirt. This hacked up build unlocked Pandora's Box and could finally emulate <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>. It wasn't a "real" solution, but for the first time we could examine the game and how it worked. Now the mystery became <em>why</em>. Why in the world was the game doing this? To do that, we had to dive into the game's history and collaborate with emulator devs from across the land.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot1.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot1.png"></a>
<figcaption>The GameCube version of True Crime: New York City is something else sometimes...</figcaption>
</figure>
</div>
<hr />
<p>The latter half of the sixth gen of consoles was the era of the "Grand Theft Auto Clone". After the success of Grand Theft Auto III, everyone wanted to get a piece of the action. <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_Streets_of_LA">True Crime: Streets of LA</a> was a surprise hit and one of the more well-liked GTA clones of the era. It was successful enough to spawn a sequel, which leads us to <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>. With a bigger budget and a taste of success, they set out to make an absolutely massive game with a huge scope. It's easy to point and laugh at it now, but looking back it was clear that the developers were trying to make a special product, even if the final game didn't turn out well. Something as simple as driving down the streets is rather impressive as you can use a <em>real map of New York City</em> instead of the in-game map and actually get around!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/126thBroadwayTrueCrime.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/126thBroadwayTrueCrime_thumb.jpg"></a>
<figcaption>You can navigate the game reasonably well using directions from GPS providers.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/126thBroadwayGoogleMaps.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/126thBroadwayGoogleMaps_thumb.jpg"></a>
<figcaption>This is the same spot in-game on <a href="https://www.google.com/maps/place/17+Convent+Avenue/@40.8161969,-73.9574991,3a,90y,298.08h,93.58t/data=!3m6!1e1!3m4!1sUjEzCt48-tOvSE2YE1ewjg!2e0!7i16384!8i8192!4m5!3m4!1s0x89c2f66c705c463f:0x168e14a883923883!8m2!3d40.8133141!4d-73.9529487">Google Maps</a>.</figcaption>
</figure>
</div></div>
<p>For a sixth generation open world game, the map is absolutely huge and densely packed with detail. The world isn't static either; as you clean up New York City, both the exteriors and interiors of buildings will change depending on what you do. If you're a bad cop ignoring crimes and just chasing your own goals, buildings get vandalized, windows are shattered, and stores across the city close down. On the other hand, being a good cop makes the place look nicer. Plants are watered, interiors clean up, and there are even nicer cars on the streets. This even spills into gameplay, as cleaner parts of the city have stores stay open later, which gives you more time to buy health items, weapons, and other upgrades during critical missions.</p>
<p>The story itself also had a lot of potential, with a lot of big name voice actors, <em>branching</em> missions where you can fail them and have to find a new lead, and tons of side activities that you'd expect in an open world game, including dynamically generated crimes. When we first started looking into <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>, we thought it was just a case of incompetent developers making a bad game, but everything we saw while playing it made us realize that this wasn't the case. The people behind this game obviously cared about the product and put a ton of thought into the mechanics to really make the world <em>breathe</em>. Unfortunately, development constraints like budget and time cut out massive parts of the game, limited testing, and rushed the game out the door in an obviously unfinished state. And <em>this</em> is just referring to the original PS2 version. The ports weren't quite as lucky.</p>
<p><br/>
<center><blockquote class="twitter-tweet" data-dnt="true"><p lang="en" dir="ltr">It... took me 15 years to realize True Crime: New York City has broken engine sounds on PC. Compare this to Xbox gameplay, where engine revs actually <em>do</em> change 😖<a href="https://www.youtube.com/watch?v=Gd5atcKpGBY&t=65s">https://www.youtube.com/watch?v=Gd5atcKpGBY&t=65s</a></p>— Silent (@__silent_) <a href="https://twitter.com/__silent_/status/1432083265112924162?ref_src=twsrc%5Etfw">August 29, 2021</a></blockquote></center>
<br/></p>
<p>The PC version is... special. Framerate is inconsistent, sounds are broken/missing, and playing the game on a modern computer is an exercise in futility. The Xbox version <em>looks</em> competent on the surface, but the developers accidentally pushed the <em>wrong build of the game into production</em> according to what we know. The build they pushed has extra AI pathing issues, physics issues, and a mid-boss where the throw mechanic is broken, instead requiring <em>frame perfect inputs</em> or else you'll be softlocked. But none of these other versions can prepare you for the atrocity that is the GameCube version of the game. After playing the game for a few weeks, we've found so many issues with it that <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">Dolphin's Wiki Entry</a> on the game contains a list of bugs for users <em>not to report</em> because they are confirmed to happen on console. While the other three versions of the game look <em>relatively</em> close at a glance, the GameCube version is missing tons of effects and textures and looks like a plastic toy in comparison.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrimecomparisongc.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrimecomparisongc_thumb.jpg" /></a>
<figcaption>Dolphin can only do so much for the GameCube version. It's lacks many of the game's special effects, has much worse shading, and the texture resolution is abysmal.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrimecomparisonps2-adjusted.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/truecrimecomparisonps2_thumb.jpg" /></a>
<figcaption>On PCSX2, emulating this game currently requires the software renderer, which means it only renders at native resolution. However, the superior texture quality and shading are immediately evident.</figcaption>
</figure>
</div></div>
<p>While both the Xbox and GameCube version were ported by <a href="https://en.wikipedia.org/wiki/Exakt_Entertainment">Exakt Entertainment</a>, it appears that the GameCube version got far less effort overall. Lighting and shading has been simplified resulting in a flatter looking world, especially during daytime scenes. A lot of other effects are missing completely, such as water physics in flooded basements. Perhaps because the GameCube used mini-DVDs, even texture quality has seen a massive downgrade, with some textures removed and everything being blurrier overall. They even broke the Main Menu, which is just a black screen with text on the GameCube version while the other versions have the Main Menu running on top of the backdrop of the city.</p>
<p>If all of these downgrades meant the GameCube version <em>ran</em> better, maybe it would be forgivable, right? If so, they were <em>really</em> struggling as the game runs a silky smooth <em>12 to 20</em> FPS while driving around the city on console. If you have a powerful PC and turn up the emulated CPU clock rate to ~170%, you can get a stable 30 FPS when emulating it. This is the one saving grace of running the game in Dolphin, as it makes driving around the city much more pleasant than it could ever be on console. Even then, the port still sucks and we haven't even gotten to the actually problematic part of the port: the physics engine!</p>
<p>As we said above, the physics engine is flooded with NaNs when playing the game on Dolphin. The reason why is because the PlayStation 2 supports <a href="https://forums.pcsx2.net/Thread-blog-Whats-clamping-And-why-do-we-need-it">extended floats</a>. Rather than doing things how most other processors, such as PowerPC, x86-64, AArch64, etc. handle things, the PS2 decided that it would be faster to throw away all of that pesky error checking and special casing when handling floating point math. With the help of developers that work on the PlayStation 2 emulator, <a href="https://pcsx2.net/">PCSX2</a>, we started to learn about just how devious that console was when it came to Floating Point Math.</p>
<p><br/></p>
<pre><code>GameCube:
1/0 = INF
sqrt (-4) = NaN
INF - 1000 = INF
INF/INF OR INF - INF = NaN
PlayStation 2:
1/0 = Greatest Positive Float Number (0x7ffffffff)
sqrt (-4) = sqrt(abs(-4)) = 2
7fffffff - 1000 = 7fffefff
7fffffff/7fffefff = 1
</code></pre>
<p><br/></p>
<p>Essentially, the PlayStation 2 doesn't really have INF or NaN. One of the reasons that our friends working on <a href="https://pcsx2.net/">PCSX2</a> have so much trouble emulating Floating Point Math on modern computers is because it's just not possible to emulate it quickly and correctly at the same time. We asked for a quote regarding their thoughts on Floating Point Math on the PS2, unfortunately due to the <em>mostly</em> worksafe nature of the Dolphin Progress Report, we didn't see it fit to broadcast such harsh language and we do not approve of insulting one's mother, even if it is the mother of a mathematical concept.</p>
<p>The important part to note about this is that <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> divides by zero <strong>a lot</strong>. As in, every single time you step on a dynamic object, these divide by zeroes flood the physics engine to the point where we had to assume there was something wrong with Dolphin's emulation of a CPU instruction. We never actually considered that the game engine was doing all of this on purpose... yet, we now know that is indeed the case. It is likely <a href="https://en.wikipedia.org/wiki/Exakt_Entertainment">Exakt Entertainment</a> didn't have the time nor budget to rewrite and fix up the physics engine to get rid of the INFs. So their solution was to let the game divide by zero, raise an exception to be handled by their custom floating point exception handler, and change the INF to zero. This left us in the awkward position of needing to implement support for Floating Point Exception Handling, something that the developers who designed Dolphin's JIT never expected to need.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot5.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot5_thumb1.jpg"></a>
<figcaption>Where is the person I'm supposed to arrest?</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot5.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot5_thumb2.jpg"></a>
<figcaption>Oh.</figcaption>
</figure>
</div></div>
<p>With us finally able to understand what was going wrong, the hard part of solving the problem was over. Now all developers had to do was add support for custom floating point exception handlers. The easiest way to do this was to add support to Dolphin's CPU interpreter, and then modify the JIT instructions so that they fallback to the interpreter when FPE handlers are enabled. And that's exactly what we did. The only downside is that there is a performance penalty to using the interpreter for these instructions, but it ended up not being a big deal.</p>
<p>By default, Floating Point Exception Handling is <strong>disabled</strong>. It was important that we don't let this change impact performance across the library just to support <em>one</em> really weird game. Then there are two settings for <em>enabled</em> Floating Point Exception Handling, with one of which being used for <em>two</em> games in their INI settings. The first is to enable Floating Point Exception Handling for DIV0 (Divide By Zero) exceptions. This allows Dolphin to emulate <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> and another game ported by <a href="https://en.wikipedia.org/wiki/Exakt_Entertainment">Exakt Entertainment</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Call_of_Duty:_Finest_Hour">Call of Duty: Finest Hour</a>, both of which rely on catching DIV0 exceptions to prevent game issues. However, that isn't <em>correct</em> emulation, so there is a second option that allows you to enable <em>Full Floating Point Exception Support</em>. This option is <em>incredibly</em> slow but allows Dolphin to accurately emulate console behavior when dealing with Floating Point Exceptions, even when the game is using a custom handler. This more or less exists for people working on homebrew or if we run into any unknown problems in the future that <em>maybe</em> would need full accuracy in this department.</p>
<p>Note, the original hack by <strong><a href="https://github.com/Smurf3tte">Smurf3tte</a></strong> didn't have much of a performance penalty, but it also wasn't a real solution. Adding a bunch of code to the JIT to support <em>just</em> <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>, not even <a href="https://wiki.dolphin-emu.org/index.php?title=Call_of_Duty:_Finest_Hour">Call of Duty: Finest Hour</a>, just isn't reasonable. Even with the interpreter solution we chose, both games run full speed on modern computers, and the DIV0 fallbacks don't cost very much performance.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrime-CutSecondIsland.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrime-CutSecondIsland_thumb.jpg"></a>
<figcaption>There's a cut second island in the game. It's still there and somewhat functional, but the bridges to it have no collision. Except for one. Clip through an invisible wall and take a <em>very long walk</em> and you can reach the cut island. Note that most areas of the island count as out of bounds and will kick you back to the mainland, so be careful where you walk!</figcaption>
</figure>
</div>
<h4 id="warning"><strong>Warning</strong><a class="headerlink" href="#warning" title="Permanent link">¶</a></h4>
<p>The following is a bit of an odd request, but we at the Dolphin team <em>highly recommend</em> that casual users do not play <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> in Dolphin or on GameCube/Wii at all. Period. The GameCube version has tons of serious problems, including reports that it could outright corrupt your memory card and cause you to lose <em>all of your savedata</em>. While we never saw anything that corrupted our memory card, we did have one instance where <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> just stopped saving until we restarted the game and all of our previous savefiles were missing. Thankfully, with the power of hexediting we were able to fix the savefiles, but any game that has a bug like that should be considered risky to play. We did play through the game on console as well, but unfortunately we were unable to trigger any of the memory card issues there, so we cannot confirm the type of memory card corruption that happened on console that players reported back when the game released.</p>
<p>Even ignoring that risk, this is the type of game where it's common for enemies that you need to kill to just spawn out of bounds where you can't reach them unless you know how to get out of bounds yourself. Sometimes, you can't even use glitches to fix your situation as loading zones might just stop working. And there are the typical problems of random crashes, physics issues with both driving and walking around the city, and you're better off just not unlocking the special driving techniques. Hell, even the <strong>controls</strong> are broken on the GameCube version as they mapped the horn to the same button as change song and there's no way to remap your buttons! The controls suck on GameCube overall because they ran out of buttons for other things so you have to do a lot of two button combos for actions that just use one button on the other systems. It's a game that fights you the whole way.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/lQryk9zXO-c" allowfullscreen></iframe></div>
<figcaption>(Mostly) muted glitch showcase showing off some of the oddities of this game.</figcaption>
</figure>
</div>
<p>Is it possible to beat <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> in Dolphin? Yes. One brave developer <strong>100%ed</strong> the game in Dolphin, unlocked both endings, and beat the bonus mission. At some point it was less about completionism and more about proving it was even possible given some of the issues in the game, including the fact that one segment of the city will usually crash on the GameCube version. If you have fond memories of this game, you're probably remembering the superior PS2 version, which is buggy in some pretty funny ways while still being playable. Again, if you want to play this game, the PS2 version of the game is cheaper to buy, <a href="https://wiki.pcsx2.net/True_Crime:_New_York_City">compatible with PCSX2</a> and is a much better game in almost every way. There's no reason to go out of your way to play the GameCube version...</p>
<p><strong>Unless.</strong></p>
<p>If you're looking to experience one of the most bizarre, buggy, and nonsensically broken GameCube releases, <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> is the closest thing we have to a <a href="https://en.wikipedia.org/wiki/Sonic_the_Hedgehog_(2006_video_game)">Sonic 06</a> level of trainwreck. Throughout testing, every time we played it we discovered new oddities, crashes, and just plain weird behaviors. The sad thing is that the game isn't all that bad when it is working, it's obvious that the developers were trying to build something so much better than what they made. If you have a powerful enough PC to run the game at a healthy emulated CPU overclock, the game can be fun at times. Just remember, we warned you of the risks.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot3.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/TrueCrimeScreenshot3.png"></a>
<figcaption>Do not do this.</figcaption>
</figure>
</div>
<h4 id="50-15407-hle-riivolution-patch-support-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15407/">5.0-15407 - HLE Riivolution Patch Support</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-15407-hle-riivolution-patch-support-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>The Riivolution patching infrastructure is one of the most popular ways to create large scale game mods for the Wii. By taking advantage of complex IOS patches provided by the Riivolution homebrew launcher, mod developers can redirect disc reads to the SD card, making it easy to develop and distribute mods. For users, it was also simple as there was no extra patching process, and the fact that you could play the mods using genuine game discs made it feel safer for purists. </p>
<p>This format is essentially the standard for a lot of different mods, and Dolphin users have been asking about support for years. Unfortunately, the situation was rather murky. There were methods to convert Riivolution mods to a pre-patched ISO, but this was rather tricky and most mods didn't provide instructions nor did they want users to use the mod that way. Supporting it accurately isn't really an option: supporting cIOS mods requires Low Level Emulation of the Starlet Coprocessor, and Dolphin isn't even close to that. This would also bring a rather hefty performance penalty to users trying to run these mods.</p>
<p><strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> noticed that there was another option. Riivolution's mod format isn't all that complicated, and could be recreated <em>without</em> the need for cIOSes rather easily. Instead of trying to emulate it, he decided to go the same direction as Dolphin's IOS emulation and directly reimplement the functionality in Dolphin. Thus, he began work on supporting Riivolution mods and making playing them in Dolphin as simple as it is on console.</p>
<h5 id="riivolution-support-in-dolphin"><strong>Riivolution Support in Dolphin</strong><a class="headerlink" href="#riivolution-support-in-dolphin" title="Permanent link">¶</a></h5>
<p>Dolphin's Riivolution support uses the same Riivolution mods you download for console and works similarly overall, just with a splash of HLE to implement some cIOS functionality. All users need to do is extract the Riivolution mod to the correct directory (On Windows by default - Documents\Dolphin Emulator\Load\Riivolution) just like you would on a Wii. Because this is handled through High Level Emulation, there's no need to mess with Dolphin's virtual SD card or anything like that, putting it in the folder is good enough. Then, simply right click the game in the gamelist and click <em>Start with Riivolution Patches</em>. Enable the one you want and launch and you're ready to go. Eventually, we plan to add support for being able to boot Riivolution mods directly from the gamelist and on netplay once a few more issues are ironed out.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/riivolution-mh3city.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/riivolution-mh3city_thumb.jpg"></a>
<figcaption>Monster Hunter Tri has Riivolution mods to re-enable Online Play via various backup server options...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/riivolution-mh3counter.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/riivolution-mh3counter_thumb.jpg"></a>
<figcaption>And you can add new quests to the game for added difficulty and rewards!</figcaption>
</figure>
</div></div>
<p><strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> also implemented a lot of niceties to make sure that playing Riivolution games is robust and simple. Pretty much any game mod should work, and savegame redirects <strong>are</strong> supported if you want to have different saves between Riivolution mods and the base game. Not <em>everything</em> works however. Advanced features such as RiiFS and the such are not currently implemented in Dolphin. As well, Dolphin's disc read timings are currently disabled when playing Riivolution mods. This is because Dolphin is not currently able to differentiate which files are located on the virtual SD card and which files are on the disc. A game might expect to be able to jump between a lot of different files on the SD card quickly, but if Dolphin were to apply disc seek timings to the reads, it would cause a huge slowdown and maybe even break the game.</p>
<p>To this point, it may seem like the choice of HLE only comes with downsides outside of performance and ease of implementation. However, there's one rather interesting benefit as well. On console, because Riivolution relies on IOS patching, it can only be used in Wii mode on Wii games. Dolphin's Riivolution support <strong>does not have this limitation</strong>. It is possible to create Riivolution mods for GameCube games in the same manner as Wii games and run them directly in Dolphin. You don't need to worry about complicated patching instructions that users will stumble over <em>or</em> potentially running amiss of copyright holders by trying to distribute pre-patched files. Combined with features like <em>CPU Clockrate Override</em> and <em><a href="https://dolphin-emu.org/blog/2020/05/05/dolphin-progress-report-april-2020/#50-11969-configurable-mem1mem2-sizes-by-minty-meeo">Extended MEM1</a></em>, there are a lot of possibilities for powerful GameCube mods using an infrastructure that modders are have been using for years. We've already seen some modders embrace this feature with Shadow the Hedgehog 2p working directly in GC Riivolution in Dolphin. </p>
<div class="media-block wider">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/MQ-Dzm_uE3E" allowfullscreen></iframe></div>
<figcaption>Shadow the Hedgehog has a very dedicated fan community and a myriad of game mods.</figcaption>
</figure>
</div>
<p>As one final note, Riivolution patches are not supported on WiiWare titles, as they do not use disc reads.</p>
<h5 id="riivolution-support-and-android"><strong>Riivolution Support and Android</strong><a class="headerlink" href="#riivolution-support-and-android" title="Permanent link">¶</a></h5>
<p>A lot of times, new features sometimes lag behind in the Android version because of GUI issues. Thankfully, Android users won't have to wait for Riivolution support. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> jumped on porting over the Riivolution launching/loading interface so that you can run your favorite Riivolution mods on your preferred mobile device.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidmod-menu.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidmod-menu_thumb.png"></a>
<figcaption>A GUI for configuring and activating Riivolution Mods was also added to Android.</figcaption>
</figure>
</div>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidmod-newermario.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/androidmod-newermario_thumb.jpg"></a>
<figcaption>Launching Newer Super Mario Bros. Wii has never been easier.</figcaption>
</figure>
</div>
<h3 id="macsimum"><strong>Macsimum</strong><a class="headerlink" href="#macsimum" title="Permanent link">¶</a></h3>
<p>A new machine has entered the Dolphin family - a 14in MacBook Pro with an M1 Max. Naturally, we promptly ran it through the same benchmarks we put the M1 MacBook Air through in our <a href="https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-apple-dolphin-on-macos-m1/#putting-the-m1-hardware-to-the-test">prior</a> <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14295-apple-m1-support-for-macos-by-skyler">tests</a>. How did it fare?</p>
<p><br/>
<script>
addChart(
{"chart":{"type":"column","polar":false},"title":{"text":"M1 Family Combined CPU/GPU Performance Test"},"subtitle":{"text":"5.0-14295, Vulkan, AArch64 JIT, Dual Core, 3x Native, Pre-compile shaders on startup "},"tooltip":{"headerFormat":"<span style=\"font-size:10px\">{point.key}</span><table>","pointFormat":"<tr><td style=\"color:{series.color};padding:0\">{series.name}: </td><td style=\"padding:0\"><b>{point.y:.1f} vps</b></td></tr>","footerFormat":"</table>","shared":true,"useHTML":true},"plotOptions":{"column":{"pointPadding":0.2,"borderWidth":0},"series":{"animation":false,"dataLabels":{"enabled":true}}},"series":[{"name":"M1 MacBook Air (7 GPU Core)","turboThreshold":0,"_colorIndex":0,"marker":{"enabled":false},"colorByPoint":false},{"name":"Native","turboThreshold":0,"_colorIndex":1}],"data":{"csv":"\"Category\";\"M1 MacBook Air (7 GPU Core)\";\"M1 Max MacBook Pro 14in (32 GPU cores)\"\n\"Super Smash Bros. Melee - FoD\";120;142\n\"Super Smash Bros. Brawl - New Pork City\";111;139\n\"Metroid Prime 3 - Elysia (1x Native, Single Core)\";50;60\n\"Skyward Sword - Skyloft\";80;92\n\"Star Wars Rogue Squadron II - Hoth\";39;39","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"Frames Per Second (VPS)"},"labels":{}},"colors":["#ff3100","#006eff","#808080","#00c800","#8085e9","#f15c80","#e4d354","#2b908f","#f45b5b","#91e8e1"],"legend":{"floating":false,"verticalAlign":"top"},"credits":{"enabled":false},"lang":{},"exporting":{},"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<p>Some of you may view the above and be surprised. Sure it's <em>better</em> but the M1 Max is not trouncing the original M1 - it's only a notch above. That's simply because of Dolphin's workload. The M1 Pro and M1 Max have more multithreaded CPU power thanks to many more performance cores, but those are the exact same performance cores that are in the M1, running at the exact same clockspeed. As an application that depends on single thread CPU performance, the CPU power available to Dolphin is basically the same for both SoCs and the performance is similar. The improvements we're seeing here are from removing every bottleneck that constrained the M1, thanks to the M1 Max's cache, memory bandwidth, and significant GPU improvements.</p>
<p>What isn't shown on that chart is the absolutely <strong>monsterous</strong> GPU the M1 Max delivers. Native res for the display (5x native for the 14in) is trivial, and many games can run fullspeed at 8k (12x native) in our tests. The original M1 choked on 4x native, hence picking 3x for the original testing.</p>
<div class="media-block wider">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/m1max-windwaker_thumb.jpg">
<figcaption>This is a 17x native (10880x8160) screenshot. It was recorded while running at fullspeed <em>on a laptop</em>.</br><sub>Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/m1max-windwaker.png">HERE</a> for the full 10880x8160 image. It may crash your browser.</sub></figcaption>
</figure>
</div>
<p>Now that we have direct access to M1 hardware, we took the opportunity to revisit our framepacing tests that previously revealed <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/#dev-diary-putting-a-mac-through-its-paces-by-mayimilae">framepacing issues on Macs with Intel graphics</a>, and confirmed that it is not an issue on M1. Macs with Intel graphics STILL suffer from this problem. For you are not familiar with frame timing and frame pacing, we briefly explained it <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/#dev-diary-putting-a-mac-through-its-paces-by-mayimilae">previously</a>.</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/macosframetimesrevisit.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-september/macosframetimesrevisit.png"></a>
<figcaption>Both Macs are able to handle this test at faster than full speed, but on Intel there is constant stutter. The M1 Max performs excellently, with only one drop in ~12,000 frames. <br/><sub>Click/tap the image for detail.</sub></figcaption>
</figure>
</div>
<p>Expect to see more of this MacBook Pro in tests going forward.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-09-01&to=2021-11-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-15107/">5.0-15107</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-15445/">5.0-15445</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: August 2021
2021-09-07T10:39:35+00:002021-09-07T21:59:21.514950+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2021/09/07/dolphin-progress-report-august-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/progressreportheader-august2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/progressreportheader-august2021mini.jpg" />
</header>
<p>Many gaming communities over the years have reached out to thank emulator developers for their efforts. Emulators are an important part of many classic game communities and give players access to features like netplay multiplayer, modding, and savestates, while also opening up the doors to enhancements not possible on console. Sometimes it's simply more convenient to use an emulator that runs on your desktop, tablet, or phone rather than to dig out and hook up the original console every time you want to play one of your favorite games. However, it's important to state that our relationship with gaming communities is mutual, and without the help of players and fans, there's no way we could handle maintaining a library of thousands of games.</p>
<p>In this Progress Report, the gaming communities were the direct catalyst to many of the changes. They went on difficult debugging adventures, caught small issues that would be invisible to anyone who wasn't extremely familiar with the game, and even came up with patches to make games friendlier to emulator enhancements. All of these contributions, even if it's not code, are appreciated and help make Dolphin what it is today. </p>
<p>So, without further delay, let's get started with the August Progress Report! Enjoy.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-14795-jit-fix-fma-negation-ordering-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14795/">5.0-14795 - JIT: Fix FMA Negation Ordering</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14795-jit-fix-fma-negation-ordering-by-josjuice" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a> is the final Wii release in the beloved <a href="https://en.wikipedia.org/wiki/Inazuma_Eleven">Inazuma Eleven soccer series</a>. Featuring tons of characters, special moves, and a lengthy RPG story mode where you build up your soccer team, level up characters, and defeat rivals, there's a lot to love about the game. So much so, that it's built up a cult following around the world, despite only releasing in Japan. There are fan translations, an active tournament scene featuring cross-country clashes, and even a "World Cup"!</p>
<div class="media-block narrower">
<figure>
<a href="https://challonge.com/Inast1">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-tourney_thumb.png"></a>
<figcaption>There have been several tournaments and online events just this year!</figcaption>
</figure>
</div>
<p>With full support on <a href="https://wiimmfi.de/">Wiimmfi</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a> is still played online via <a href="https://en.wikipedia.org/wiki/Nintendo_Wi-Fi_Connection">Nintendo Wi-Fi Connection</a> to this day, and many users choose to use Dolphin. It's one of the few Wii games left where you can actually find matches today, especially if you go to one of the community Discord servers. Everything works great in Dolphin, with one annoying caveat: Dolphin could not sync with Wiis. Upon attempting to block <em>Hissatsu</em> (special moves) or tackling, the game would detect a problem and rollback to a point before the problem happened, usually dropping the ball into a stationary position. This meant scoring with the powerful special moves was impossible and tackling your opponents wasn't an option. The game was unplayable.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video controls muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-desync_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>The animation shows a failed catch, yet after some loading, the catcher has the ball in their hands. This is a rollback to recover from a desync.<br/><sub>Click/Tap to play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-desync.mp4">HERE</a> for a higher quality version.</sub></figcaption>
</figure>
</div>
<p>One of the world cup matchups that the community was doing was France VS Japan, which presented a problem. The French community primarily uses Dolphin, while a majority of the Japanese players solely play on console. This meant that players would either have to swap to an unfamiliar setup or matches would have to be cancelled due to this bug. The users across the communities decided enough was enough: they were going to get to the bottom of this issue no matter what it took. Inazuma veterans, including players Obluda, AS, GalacticPirate and many others, joined together to try to track down an absolutely nightmarish emulation bug.</p>
<p>What made this issue such a problem was the particularly specific conditions that were required to reproduce it. Normally when examining potential CPU bugs, you'll want to do things like pause emulation, attach debuggers, examine registers, and do other technical things to watch exactly what is happening. And in addition to all of that, developers often rely on Dolphin's interpreter as a sanity check for the JITs in order to determine what kind of bug was being dealt with. In the past, tools like these alongside hardware tests have helped developers find differences in calculations that once caused replay desyncs in games like <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Brawl">Super Smash Bros. Brawl</a>, and many others.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a> is a similar problem but with a constraint that makes it very difficult to examine. In order for the bug to manifest, <em>the emulator had to be on Wi-Fi connected to a Wii</em>. This meant that Dolphin had to be running <em>close</em> to full speed and couldn't be paused for long periods of time, or else the connection would be lost. This essentially cut off most ways we would normally use to examine and test a CPU related bug, and made even checking if the issue happened on the interpreter a non-starter. A full instruction bisect through typical means simply wasn't realistic either, as that would also lower performance too far. And while everyone <em>suspected</em> this was a JIT bug, we couldn't be sure as there was no way to verify if switching to interpreter fixed it!</p>
<p>Despite all of these hurdles, the Inazuma community pressed on. Instead of relying on a conventional bisect, they went on the painstaking journey of falling back small groups of instructions to interpreter at a time. Combined with a fast enough processor, they could keep the game full speed while slowly testing each interpreter version of the instructions to see if one of them fixed it. Eventually, they proved successful when going through the <em>JIT Floating Point</em> instructions. By disabling a group of them, they were able to fix the desync while <em>just</em> hovering close enough to full speed to stay connected to the Wii. With this lead, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> chipped in to help guide users into bisecting the remaining instructions and they landed within the floating point <a href="https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation">Fused Multiply–Add (FMA)</a> instructions. Developers were a bit skeptical of this bisect, as both the x86-64 and AArch64 JITs have been put through the gauntlet. They should have been bit perfect by this point, as confirmed by hardware tests and the many games with replay files.</p>
<p>Others joined in and one developer even imported the game in order to verify what was going on. With the <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO</a> community's assistance, we were able to see what was going on first hand and confirm the instruction bisect. Something was definitely going wrong in Dolphin's FMA calculations. The problem was that there were still no conclusive problem that could be found, even though we knew what was broken. After staring at the issue for what felt like weeks, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> finally figured it out: The problem turned out to be from differences in precisely <em>when</em> negation occured. Let's get technical.</p>
<div class="media-block wider">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/gamecubecpu-bigger.jpg">
</figure>
</div>
<p>"Negation" is changing the sign from positive to negative or vice versa on demand. This is typically bundled in duplicate versions of FMA instructions for efficiency, i.e. <code>madd</code> (multiply-add) has a negated variant <code>nmadd</code> which should, in theory, have the opposite sign of <code>madd</code>. However, different CPU architectures can apply the negation at different points in the calculation, changing the result. PowerPC's <code>nmadd</code> and <code>nmsub</code> (negated multiply-subtract) instructions negate at the end of the the operation, with the equation <span style="font-family:monospace; font-weight:bold; white-space: nowrap;">-(A * C ± B)</span>. This makes sense, so of course nothing else does it this way.</p>
<p>x86-64, in its infinite wisdom, <em>negates the multiply operation result</em> then does the add or subtract. The equation for this is <span style="font-family:monospace; font-weight:bold; white-space: nowrap;">-(A * C) ± B</span>, which is very different than the PowerPC version and is not compatible at all. However, past Dolphin developers discovered a clever workaround for this issue. All we had to do was simply swap ADD and SUB for these instructions. Just by doing the opposites, we could get the results that the game's PowerPC code expected.</p>
<p>AArch64 flips the table. The AArch64 <code>nmadd</code> equation is <span style="font-family:monospace; font-weight:bold; white-space: nowrap;">-(A * C) - B</span>, which is exactly x86-64's <code>nmsub</code> equation! Having an <em>add</em> instruction <em>subtract</em> is a curious decision from ARM, but thanks to this we didn't need to do our SUB swapping trick as AArch64 already did it for us, allowing PowerPC's <code>nmadd</code> to map directly to AArch64's despite very different equations. But if that wasn't weird enough, AArch64's <code>nmsub</code> equation is <span style="font-family:monospace; font-weight:bold; white-space: nowrap;">(A * C) - B</span>, which <em>isn't negated at all</em>. Yet AArch64's <code>msub</code> is negated, for whatever reason, so we used that instead. We've learned not to question it.</p>
<p>These tricks are clever, and have proven to be very accurate. However, as <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a> proved, they were not perfect. <strong><a href="https://github.com/booto">booto</a></strong> discovered that due to differences in negation ordering between the equations, this method breaks when all inputs are zero — PowerPC's <code>nmsub</code> would give -0, while x86's <code>nmadd</code> and AArch64's <code>msub</code> would give +0. Whoops. We don't know exactly what <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma</a> is doing to rely on this unusual behavior, but this is the bug that was causing its desyncs when Dolphin and Wiis were mixed on Wi-Fi Connection.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-thewall.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazuma-thewall_thumb.jpg"></a>
</figure>
</div>
<p>While <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma</a> was handled, further inspection revealed more possible issues. The tricks above gave the same results as console no matter what we threw at them... when they are performed by normal math. On actual hardware these equations are being performed via <a href="https://www.youtube.com/watch?v=PZRI1IfStY0">floating point math</a>, so our good friend <em>floating point rounding errors</em> crops up once again. By performing the negation at different points in the equations, the floating point calcuations were rounding differently from the PowerPC originals. Usually it was fine, but at the extremes of rounding, such as rounding toward infinity, it would round differently enough to create a different floating point result. We're not aware of any software encountering this issue yet, but it is best to fix discovered flaws like this if we can.</p>
<p>To solve for all these quirks, we now just use the standard <code>madd</code> and <code>msub</code> instructions (and <code>nmsub</code> on AArch64), and negate them afterwards ourselves with dedicated negation instructions. This simple change resolves all these edge cases and allows Dolphin to play against real Wiis in <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a>! While there is an extremely small performance hit from using two instructions instead of one, we assure you, you won't notice. Probably. Surely there isn't a game being dumb with basic FMA negation instructions to such a degree as to cause a noticeable performance hit. SURELY. (link to next month's Progress Report here)</p>
<p>Without the amazing Inazuma community doing a nightmarish instruction bisect with the strict condition that they couldn't slow down performance <em>too much</em>, this issue may never been fixed. If you're looking to try out this game, there's still an active community, tournaments, and plenty of guides for this stylized soccer game. We must specifically thank <a href="https://twitter.com/inazuma_france">Inazuma France</a> for reaching out to us.</p>
<h4 id="50-15009-iosnetworking-make-name-resolution-asynchronous-by-sepalani"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15009/">5.0-15009 - IOS/Networking: Make Name Resolution Asynchronous</a></strong> by <strong><a href="https://github.com/sepalani">sepalani</a></strong><a class="headerlink" href="#50-15009-iosnetworking-make-name-resolution-asynchronous-by-sepalani" title="Permanent link">¶</a></h4>
<p>When testing the online for <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven GO: Strikers 2013</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a>, and other WiFi supported games on backup servers like Wiimmfi, it was noted that the initial connection had some very large stutters. Since online features were being tested <em>anyway</em> due to the <a href="https://wiki.dolphin-emu.org/index.php?title=Inazuma_Eleven_GO:_Strikers_2013">Inazuma Eleven</a> WiFi issues, it gave the perfect chance to test <strong><a href="https://github.com/sepalani">sepalani</a></strong>'s change to asynchronously handle domain name resolution. By performing the operation on a separate thread, the stutters when connecting to a Wi-Fi enabled game are completely alleviated.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazumaasyncloading-stutter_thumb.mp4" type="video/mp4"/>
</video></div>
<figcaption>Before, connecting was anything but smooth.<br/><sub>Click/Tap to play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazumaasyncloading-stutter.mp4">HERE</a> for a higher quality version.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<video controls playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazumaasyncloading-smooth_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>But now it acts just like it does on console.<br/><sub>Click/Tap to play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/inazumaasyncloading-smooth.mp4">HERE</a> for a higher quality version.</sub></figcaption>
</figure>
</div>
<h4 id="50-14810-50-14848-and-50-15105-gameini-heavy-iron-studios-games-quality-of-life-changes-by-the-community-and-developers"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14810/">5.0-14810</a></strong>, <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14848/">5.0-14848</a></strong>, and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15105/">5.0-15105</a></strong> - <strong>GameINI: "Heavy Iron Studios" Games Quality of Life Changes</strong> by <strong>The Community and Developers</strong><a class="headerlink" href="#50-14810-50-14848-and-50-15105-gameini-heavy-iron-studios-games-quality-of-life-changes-by-the-community-and-developers" title="Permanent link">¶</a></h4>
<p>As a developer of licensed games for <a href="https://en.wikipedia.org/wiki/Sixth_generation_of_video_game_consoles">sixth generation consoles</a>, it's hard to have a better legacy than <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a>. One of their games, <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">SpongeBob Squarepants: Battle for Bikini Bottom</a> is a cult classic that was popular enough to see an <a href="https://en.wikipedia.org/wiki/SpongeBob_SquarePants:_Battle_for_Bikini_Bottom_%E2%80%93_Rehydrated">HD remake on modern consoles</a>, and their other games range from <a href="https://wiki.dolphin-emu.org/index.php?title=Scooby-Doo!_Night_of_100_Frights">mostly competent</a> to <a href="https://wiki.dolphin-emu.org/index.php?title=The_SpongeBob_SquarePants_Movie">pretty good</a>. Overall, they're fun games that used the IP well and made for enjoyable experiences with well known characters. </p>
<p>As these license games have a rather large fanbase, users have wanted to play through them in Dolphin with the many enhancements that emulation provides. Unfortunately, there were some limitations. Dolphin could emulate these games correctly... but the most powerful enhancement it offers just didn't work well. Raising the Internal Resolution brought forth severe graphics issues, essentially locking these games to native resolution. This isn't some kind of bug in Dolphin, either! Most of <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a>' games are built in a way that makes it so <em>they can't actually be played in higher resolutions</em> due to tricks used during rendering, at least not without a little bit of trickery from users and emulator developers. </p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-oldsd.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-oldsd_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>While Battle For Bikini Bottom was fine at 1x Native Internal Resolution...<br/><sub>Click the video to see it in full size.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-oldhd.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-oldhd_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>High internal resolutions would cause significant visual errors.<br/><sub>Click the video to see it in full size.</sub></figcaption>
</figure>
</div>
<p>This issue goes back to the first game that <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> released on the GameCube — <a href="https://wiki.dolphin-emu.org/index.php?title=Scooby-Doo!_Night_of_100_Frights">Scooby Doo: Night of 100 Frights</a>. It does the same techniques as <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Battle for Bikini Bottom</a> with one key difference. This game sets up the projection matrix incorrectly; it's set up for a 639 by 479 output instead of the actual 640 by 480 output. Because of this, when the game copies a 256x256 chunk of the framebuffer out of memory, it ends up going through the incorrect projection matrix when being copied back in and ends up slightly malformed to a 256.401 by 256.534 chunk instead. The easiest way to imagine this bug is to compare it to photoediting. Imagine copying out a portion of an image, resizing the rest of the image down <em>very slightly</em>, but then copying back in the chunk you copied out earlier without resizing it, and then scaling the full image back to its original size. This isn't a perfect analogy, but it at least gives you an idea of the types of visual issues this causes. The thing is that the GameCube's native resolution is so low, these slight imperfections don't result in any visible issues. It's only because Dolphin allows for higher internal resolutions that this bug can manifest in a visual manner.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/scoobs-vertexroundingoff.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/scoobs-vertexroundingoff_thumb.png" /></a>
<figcaption>At higher resolutions, there was a subtle break in the pixels in the upper left quadrant...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/scoobs-vertexroundingon.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/scoobs-vertexroundingon_thumb.png" /></a>
<figcaption>But Vertex Rounding completely alleviates it.</figcaption>
</figure>
</div></div>
<p>By the time <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">SpongeBob Squarepants: Battle for Bikini Bottom</a> rolled around, <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> noticed this bug and corrected for it. Not only did they fix the Projection Matrix to be 640x480, they also added a horizontal and vertical 1/512 (half a pixel) offset to both position and texture coordinates. This makes it so things <em>do</em> line up better at higher internal resolutions, except now the textures ends at 513/512 instead of 1.0. This means that the EFB copy wraps around and grabs parts of the very edge of the screen. If we break down how the image is rendering, it's actually pretty easy see how the higher resolutions break things.</p>
<div class="media-block narrow">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrenderingnative.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrenderingnative_thumbbig.jpg"></a>
<figcaption>This is a screenshot of how the game looks about halfway through drawing a frame. You can see the shadow hasn't been covered up yet.</figcaption>
</figure>
</div>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrenderingnative.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrenderingnative_thumb.png" /></a>
<figcaption>At native resolution, everything is flush with the edge of the screen.<br/><sub>Click the thumbnail to see it in full size.</sub></figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrendering3x.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadowrendering3x_thumb.png" /></a>
<figcaption>At higher resolutions, the offsets cause visual problems.<br/><sub>Click the thumbnail to see it in full size.</sub></figcaption>
</figure>
</div></div>
<p>Users who saw this issue nicknamed it the "blue box" issue, as most commonly it'd be duplicating the parts of the skybox. Though Vertex Rounding can <em>fix</em> the position coordinates and thus repair shadow rendering, it also makes the fact it's grabbing from the very edge of the screen much more obvious since the texture coordinates were still offset.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobold-vertexroundingoff.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobold-vertexroundingoff_thumb.jpg" /></a>
<figcaption>Without Vertex Rounding the shadows are broken as expected and the blue box in the upper left will sometimes appear.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobold-vertexroundingon.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobold-vertexroundingon_thumb.jpg" /></a>
<figcaption>Vertex Rounding corrected the shadows, but the blue box issue was much more noticeable.</figcaption>
</figure>
</div></div>
<p>This texture offset made it so there wasn't really anything more Dolphin could do to render things better outside of extremely ugly per-game hacks. Users took things in a different direction then, messing with the game itself rather than trying to adjust the emulator to handle this case. Their tool of choice was the <em>Action Replay</em> code, which allowed them to modify the game directly in memory. Several years ago, users on an issue report for <a href="https://bugs.dolphin-emu.org/issues/9649">this very issue</a> discussed the idea of using action replay codes to improve the situation. Users even posted some codes that partially rectified the situation, with <a href="https://bugs.dolphin-emu.org/users/6405">Disorderly</a> actually posting the exact address that would end up the catalyst to fixing this game.</p>
<p>Unfortunately, these solutions were way ahead of their time. Dolphin lacked the Vertex Rounding hack at that point, and also had rounding errors that made the game render incorrectly even at native resolution. Because they had to dance around multiple issues at once, the codes became extremely complicated and had tons of downsides. This misdirection caused just about everyone to not realize <em>just how close</em> they were even back then.</p>
<p>It wasn't until earlier this year that developers became aware of a solution that could fix this game's rendering issues without breaking graphics when a single line Action Replay code appeared on <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Dolphin's Battle for Bikini Bottom Wiki Page</a>. The key was simply putting everything together. Fixes to Dolphin's internal rounding over the years, plus the Vertex Rounding Hack, and this Action Replay code finally had the game rendering cleanly at higher resolutions.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-newhd.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebob-newhd_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>With this trickery, Bikini Bottom is fine with any Internal Resolution!</figcaption>
</figure>
</div>
<p>However, relying on users to find a code on <a href="https://wiki.dolphin-emu.org/index.php?title=Main_Page">the Wiki</a>, enter it into Dolphin's INIs or action replay menu, enable cheats, and <em>also</em> make sure the Vertex Rounding hack was enabled without any hints or instructions was rather unreasonable. After trying out the code for himself, <strong><a href="https://github.com/JMC47">JMC47</a></strong> wanted to make the user experience seamless. However, the question was if there was a way to make this enhanced experience easy to access without compromising the authentic experience for those looking to play the game at native resolution without hacks.</p>
<p>Vertex Rounding is automatically disabled at native resolution, so that could be made a default setting without concern. While we couldn't enable an Action Replay code by default, since it was just writing a value to memory it could very easily be converted into a game patch. The only thing we had to make sure was that the game patch didn't cause issues at native resolution. In order to do that, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> was brought in to analyze the patch's effects with Dolphin's FifoAnalyzer. In the end, it was deemed harmless and was converted over from an Action Replay code to a game patch that could automatically be applied at boot.</p>
<p>For the sake of completionism, <strong><a href="https://github.com/JMC47">JMC47</a></strong> <em>also</em> adjusted the patch to work with the PAL version of the game, so that no matter which version you play, you'll be able to play at higher resolutions in the latest development builds!</p>
<hr />
<p>That <em>would</em> have been the end of this story, but there was a bit of bitter taste left in everyone's mouth. <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">SpongeBob SquarePants: Battle for Bikini Bottom</a> may have been the most popular game made by <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> and fixing it would have appeased most players, but the other games that they made were still broken. Are those games less important simply because there are fewer people who want to play them?</p>
<p>There was another bigger factor than that. Because those games were less popular than <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Battle for Bikini Bottom</a>, there was no magical code that existed for them to fix the offset. Or so we thought. Surprisingly enough, another of the games, <a href="https://wiki.dolphin-emu.org/index.php?title=The_SpongeBob_SquarePants_Movie">The SpongeBob SquarePants Movie</a> also had a code to help with higher resolutions on the Wiki! Figuring it wouldn't be a big deal, <strong><a href="https://github.com/JMC47">JMC47</a></strong> decided to port the code into a patch as well. However... something was amiss.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobmovienoshadow.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobmovienoshadow_thumb.jpg"></a>
<figcaption>The available code for The SpongeBob SquarePants Movie removed most shadowing effects.</figcaption>
</figure>
</div>
<p>The code for <a href="https://wiki.dolphin-emu.org/index.php?title=The_SpongeBob_SquarePants_Movie">The SpongeBob SquarePants Movie</a> didn't remove the offset from the executable, it outright disabled the problematic EFB copies from ever rendering! While this did work in removing the artifacts, it also removed a ton of special effects from the game. This wasn't a workable game patch that could be enabled by default. Yet, these games seemed so similar that <strong><a href="https://github.com/JMC47">JMC47</a></strong> was convinced that a proper patch was possible. In order to do this, he enlisted the help of <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> once more to look at how the game was rendering with and without the action replay code. Together, they confirmed for certain that this code was a dead-end for actually addressing the core problem. But during this investigation, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> mentioned that one reason why <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Battle for Bikini Bottom</a> likely saw a more detailed code wasn't that it was just more popular, but that it included <em>debug symbols</em> on the disc in the form of an unstripped ELF executable. For those that don't know, <em>debug symbols</em> are extremely useful for reverse engineering, as it'll break up functions and give them names directly in the code. It makes understanding what you're seeing much easier.</p>
<p>The developers left the <em>debug symbols</em> in their earlier game, but would they really leave it again in the sequel...?</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/unstrippedelf.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/unstrippedelf_thumb.png"></a>
<figcaption>Jackpot.</figcaption>
</figure>
</div>
<p>It turns out that <strong>every single <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> game from this era has an unstripped ELF on the disc</strong>. This turned what would have been an annoying reverse engineering project into something that even a novice could handle with enough time and effort. With the guiding hand of <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong>, <strong><a href="https://github.com/JMC47">JMC47</a></strong> learned how to wield <a href="https://ghidra-sre.org/">Ghidra</a>, a software reverse engineering tool, along with plugins developed for it specifically for analyzing GameCube and Wii executables. It was a painfully slow process of figuring out how things worked, but <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> was able to help provide a lead. The offset this time wasn't the same as in <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">Battle for Bikini Bottom</a>; EFB copies were now half the resolution, but otherwise the rendering process was the same as the previous game. <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> was able to derive what the value was in memory and <strong><a href="https://github.com/JMC47">JMC47</a></strong> started patching out every occurrence of the floating point number directly until he found the memory address that fixed the rendering. Once that was done, he made a new <a href="https://wiki.dolphin-emu.org/index.php?title=FifoPlayer">Fifolog</a> for <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> to confirm it was working and ported the code to the game's other regions.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobmovieimproved.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/spongebobmovieimproved_thumb.jpg"></a>
<figcaption>Even Patrick is wondering where all the glitches went.</figcaption>
</figure>
</div>
<p>...That's still not the end of our story, however. <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">SpongeBob Squarepants: Battle for Bikini Bottom</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_SpongeBob_SquarePants_Movie">The SpongeBob SquarePants Movie</a> may have been the two most popular titles with these issues, but <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a> employed this same technique in most of their games. <strong><a href="https://github.com/JMC47">JMC47</a></strong> knew the exact steps on how to find the offset EFB copies and fix the issue thanks to the work done for <a href="https://wiki.dolphin-emu.org/index.php?title=The_SpongeBob_SquarePants_Movie">The SpongeBob SquarePants Movie</a>. While none of their other GameCube titles are nearly as popular, there was no reason outside of laziness not to go through and make the patch work for <em>all of the known games with this issue</em>. There were no base codes to work from this time, but at this point he didn't need them.</p>
<p>Over the next few weeks he collected and went through every known title and revision with the issue and developed patches for each one. So now titles like <a href="https://wiki.dolphin-emu.org/index.php?title=The_Incredibles">The Incredibles</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Incredibles:_Rise_of_the_Underminer">The Incredibles: Rise of the Underminer</a>, and even the various <a href="https://wiki.dolphin-emu.org/index.php?title=2_Games_in_1:_Nickelodeon_SpongeBob_Schwammkopf:_Der_Film_%2B_Nickelodeon_SpongeBob_Schwammkopf:_Schlacht_um_Bikini_Bottom">2 in 1 SpongeBob/Incredibles</a> releases now have patches to make sure they run properly at higher resolutions.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/incredibles-vertexroundingoff.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/incredibles-vertexroundingoff_thumb.jpg" /></a>
<figcaption>The broken shadows locked this game to native resolution.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/incredibles-vertexroundingon.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/incredibles-vertexroundingon_thumb.jpg" /></a>
<figcaption>But now you can play any of the early Heavy Iron Studios' games at higher resolutions!</figcaption>
</figure>
</div></div>
<p>And now all of these games work at higher resolutions, not through any kind of improvement in emulation, but through modifying the games to render in a more friendly way. While Dolphin <em>usually</em> doesn't ship patches or enhancements on by default, we also realize that that a lot of our users enjoy Dolphin's ability to run games at higher resolutions. In this case, we couldn't do much more to emulate the game better, but by changing the game itself, we were able to get things rendering nicely at higher resolution. And remember, having the patches enabled <em>do not</em> compromise the game's rendering at native resolution. Thus, in the latest development builds we've enabled these patches <em>and</em> Vertex Rounding by default.</p>
<p>In the latest development builds, we've also <em>disabled Dual Core</em> by default for these games after <strong><a href="https://github.com/JoeyBallentine">JoeyBallentine</a></strong> and the speedrunning community for <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Battle_for_Bikini_Bottom">SpongeBob Squarepants: Battle for Bikini Bottom</a> notified us of instability issues with the game. Because these games are fairly lightweight and don't require many strenuous features, this shouldn't be a problem for most desktop computers or high-end Android devices. But if you're willing to deal with occasional crashes, you can always re-enable Dual Core for this title in the game properties page.</p>
<p>Over the years, we know that there have been many players disappointed with the many problems that Dolphin had with <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Heavy_Iron_Studios_(Developer)">Heavy Iron Studios</a>' games. Now might be the perfect chance to give these classic games another playthrough. We think you'll like what you see.</p>
<h4 id="50-14812-convert-nan-to-1-when-generating-texture-coordinates-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14812/">5.0-14812 - Convert NaN to 1 When Generating Texture Coordinates</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-14812-convert-nan-to-1-when-generating-texture-coordinates-by-pokechu22" title="Permanent link">¶</a></h4>
<p>When they're not being pestered to help reverse engineer other games, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> has been known to dive into some of the weirdest graphical glitches afflicting Dolphin. This one caught their <em>eye</em> on the issue tracker as it was an issue with literally no lead. <a href="https://wiki.dolphin-emu.org/index.php?title=Shadow_the_Hedgehog">Shadow the Hedgehog</a>, a game that absolutely every single Sonic fan loves, had issues with rendering eyelids, especially during certain cutscenes. Fortunately the tester provided a <a href="https://wiki.dolphin-emu.org/index.php?title=FifoPlayer">Fifolog</a> of the bug, so <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> analyzed the Fifolog and found that the eyelids had a texture coordinate of <strong>NaN</strong> (Not a Number). As this seemed incredibly wrong, they decided to play back the Fifolog using the Hardware Fifoplayer and found something very interesting.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-broken_thumb.png"/></a>
<figcaption>The Fifolog rendered as expected in Dolphin.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-console.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-console_thumb.jpg"/></a>
<figcaption>But on console, the Fifolog rendered correctly, meaning there was some kind of special handling for NaN!</figcaption>
</figure>
</div></div>
<p>It seemed as though real hardware was automatically correcting for NaN in some way. <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> continued poking at the issue on console, eventually determining that the console was interpretting NaN texture coordinates as either "1" or "-1". After a <a href="https://github.com/dolphin-emu/dolphin/pull/9928#issuecomment-893043811">thorough analysis</a> of values to see which was most correct, they added a condition to Dolphin's graphics emulation to convert NaNs to 1 In order to remedy the issue for now.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-fixed.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/shadoweyes-fixed_thumb.png"></a>
<figcaption>With this extra handling, the eyeslids look much closer to console.</figcaption>
</figure>
</div>
<p>There are still some oddities around how the eyelids render in <a href="https://wiki.dolphin-emu.org/index.php?title=Shadow_the_Hedgehog">Shadow the Hedgehog</a>, but this greatly improved the situation for now. Unfortunately, if you're using D3D11 or D3D12 Ubershaders, we can't exactly emulate this behavior. D3D11/12 automatically optimizes out Dolphin's attempts to use isnan to check for NaN values in shaders, no matter how much we try to tell them that we <em>really</em> need to know if this is NaN or not. Because of this, the eyes remain broken on D3D11/12 when using Ubershaders for the time being.</p>
<h4 id="50-14829-powerpc-implement-broken-masking-behavior-on-uncached-writes-by-josjuice-with-help-from-eigenform-delroth-phire-marcan-segher-extrems-and-rylie"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14829/">5.0-14829 - PowerPC: Implement Broken Masking Behavior on Uncached Writes</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> with help from <strong><a href="https://github.com/eigenform">eigenform</a></strong>, <strong><a href="https://github.com/delroth">delroth</a></strong>, <strong><a href="https://github.com/phire">phire</a></strong>, <strong><a href="https://github.com/marcan">marcan</a></strong>, <strong><a href="https://github.com/segher">segher</a></strong>, <strong><a href="https://github.com/Extrems">Extrems</a></strong>, and <strong><a href="https://www.youtube.com/channel/UCWYUUzuybieMseJy3KyCA7g">Rylie</a></strong><a class="headerlink" href="#50-14829-powerpc-implement-broken-masking-behavior-on-uncached-writes-by-josjuice-with-help-from-eigenform-delroth-phire-marcan-segher-extrems-and-rylie" title="Permanent link">¶</a></h4>
<p>It's hard to find a bigger All-Star cast of GameCube/Wii emulator developers and reverse engineers for one change. What brought them together wasn't some massive bug in Dolphin or some problem affecting hundreds upon hundreds of games. What brought them together was a strange hardware bug, and figuring out how to test it and eventually emulate it. This hardware bug has actually been known for some time, but it was ignored as there was no use case for it in any retail game... until now.</p>
<p>It's well known at this point that the N64 Zelda games are incredibly broken. With Arbitrary Code Execution (ACE), players literally write some code into memory and have the game execute it to let them go straight to the credits. Thanks to this, speedruns in the N64 version of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Ocarina of Time</a> have fallen to <em>under ten minutes</em>. Unfortunately, so far ACE isn't possible on the Virtual Console versions of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Ocarina of Time</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a>, which has left players searching for alternatives and new ideas.</p>
<p>One exciting development, originally discovered by <a href="https://github.com/MrCheeze">MrCheeze</a>, is known as <strong>LightNode SRM</strong>. This is a more powerful method of Stale Reference Manipulation (more commonly known as Use-After-Free or UAF as a software vulnerability) that actually works <em>better</em> on the Virtual Console releases, and it's pretty fast to do. It works in both <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Ocarina of Time</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a> and is now used in the fastest route in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">OoT</a> Any%!</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/g8IOuVOL-oU" allowfullscreen></iframe></div>
<figcaption>The new glitch working on console.</figcaption>
</figure>
</div>
<p>So what exactly is LightNode SRM and why does it work better on the Virtual Console versions of these games? Let's first focus on the glitch itself. The core component to triggering the glitch is to find a way to get Link to carry an "actor" (game entity) that has been unloaded. One of the easiest methods to do this is to change rooms while in the grab delay state while using a classic <a href="https://www.zeldaspeedruns.com/oot/tech/superslide">superslide</a>.</p>
<p>Once Link is carrying <em>nothing</em>, that's when the fun begins. He's actually writing three words and two halfwords into parts of memory that used to belong to the actor but are now being reused for other stuff. Even if you performed this glitch on most actors, you'd still only be constrained to overwriting parts of the actor heap, which contains things like the enemy and item data. These are useful enough to mess with, but a way to escape the actor heap would break things <em>way open</em>. That's where LightNode SRM comes into play!</p>
<p>LightNode SRM is named literally because it relies on the lights in the game. The way the game handles lighting sources that load/unload dynamically is with a <a href="https://en.wikipedia.org/wiki/Doubly_linked_list">doubly-linked list</a> of all such sources currently loaded. One of the examples of this are those torch lights throughout the game.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/LNSRM_Angle3.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/LNSRM_Angle3_thumb.jpg"></a>
<figcaption>During LightNode SRM, the fire from the LightNode you "grab" is missing!</figcaption>
</figure>
</div>
<p>The key to this is that every time an actor with a dynamic lighting source unloads, the associated LightNode is removed from the linked list:</p>
<p><br/></p>
<pre><code>node->prev->next = node->next;
node->next->prev = node->prev;
</code></pre>
<p><br/></p>
<p>The pointer to the light node (<code>node</code> in the code snippet) is stored in the actor instance data, so it can be overwritten by doing SRM and changed to point to a region of memory that speedrunners control. This means that <code>node->prev</code> and <code>node->next</code> can be anything they want and point to whatever they wish to modify, even if it's outside of the actor heap!</p>
<p>In essence, this gives the speedrunners the ability to do arbitrary RAM writes in both games! Because <code>node</code> is manipulated into pointing to Link's respawn coordinates, the write address and the written value are ultimately controlled by Link's position. On the Nintendo 64 hardware, what you can do with this is a bit more limited than on the PowerPC consoles simply due to how the CPU behaves in a few key situations. In <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Ocarina of Time</a>, this doesn't end up mattering as much because the filename is aligned and is close enough to access from the linked list. By getting the LightNode pointer to read the filename, you can setup a payload with the name of your file.</p>
<p>Things are a bit different in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a>, the filename too far away in memory thanks to its use of the <a href="https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expansion_Pak">N64 Expansion RAM</a> meaning things are a bit more complicated. Here the GameCube/Wii's ability to do unaligned writes come into an even bigger role. This gives players much greater control over what values they can write into memory, and allows them to realistically control writing floating point values into RAM. This made the GameCube and Virtual Console versions of these games able to do things not possible on N64 hardware. Since the Virtual Console versions are faster and more stable than the GC N64 emulators, speedrunners continued to focus on them.</p>
<p>The first LightNode SRM route came into fruition in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a> with an Any% route that didn't quite take any World Records but still showed the potential of this new technique. Not too long afterwards, LightNode SRM would make the news as it allowed for the first sub <em>7</em> minute run of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">any release of Ocarina of Time</a>! This route only works on GameCube/Wii, due to <em>another</em> CPU behavior that causes a phenomenon speedrunners call DoubleWord Write (DWW) and QuadWord Write (QWW). We'll get into this a bit later as the reason for this is a bit complicated.</p>
<p>In terms of speedrunning, these techniques open up a ton of new options, especially for non-Any% runs. Arbitrary Code Execution is <em>so powerful</em> that it is banned in many categories in order to keep definitions simple and keep the routes interesting. Once you're able to execute your own code, you can do anything. Note that the ban on ACE <em>includes</em> using LightNode SRM to overwrite code, but because it can be used to overwrite data, which is perfectly legal, it has huge implications in tons of different categories.</p>
<p>As with any major glitch, players sought to push it further through emulation. This time, they wouldn't be using an N64 emulator, as the Nintendo Wii's Virtual Console releases were the best suited for the speedruns. Unfortunately, Dolphin wasn't quite up to the task as shown in the video above. While all of the basic steps of the trick worked, the values that were written into RAM by LightNode weren't quite the same on console and Dolphin. The reason why might be a bit surprising: they were relying on a feature that <em>worked</em> in Dolphin but was broken on console.</p>
<p>That's right, this was a trick that relied on accurate emulation of <em>Uncached Writes</em>.</p>
<div class="media-block wider">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/gamecubecpu-bigger2.jpg">
</figure>
</div>
<p>On the Nintendo GameCube and Wii, there is a hardware quirk that causes unaligned uncached writes to misbehave. This hasn't been a major issue for Dolphin as all retail software has stayed away from actually using such writes. There was very little reason to put forth a ton of effort to emulate what was a dead feature on console. However, remember that CPU feature that was mentioned just above that caused DWW and QWW? That <em>was</em> the notoriously broken unaligned uncached writes! Their broken behavior allowed them to write over larger parts of memory than would be otherwise possible. And this was the key; in the credit warp route showed above, they actually wrote over two adjacent entrance records to account for two different credits cutscenes in Termina Field!</p>
<p>Unfortunately, this is where things fell apart for Dolphin. These uncached writes behaved <em>correctly</em> in Dolphin, meaning the broken duplication behaviors were not emulated and the second entrance record was not written. Speedrunners from <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a> approached Dolphin developers with the question: Can you get this working?</p>
<p>With an issue report filed and speedrunners ready to test things, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> started developing a hardware test to figure out exactly what was happening. Unfortunately, things grinded to a halt almost immediately. It seemed as though trying to verify the behavior on console resulted in a sudden <em>crash</em>. No matter what was tried, the uncached writes would freeze the console. More developers were brought in to try to figure out what was going on. The console shouldn't freeze; we knew that because the speedrun already proved that this <em>should</em> at least work. Slowly, more developers caught wind of the problem and soon enough there was an all-star cast of reverse engineers from throughout the years diving into this strange issue. Multiple angles were tested, with some developers trying to reproduce the conditions of the game, and others trying to simplify the test further to see if something was wrong elsewhere in the test.</p>
<p>No matter what happened, the console would stop at the first uncached write.</p>
<p>After a few days of messing with things, <strong><a href="https://github.com/eigenform">eigenform</a></strong> cracked the code. Almost all homebrew is built upon <a href="https://wiibrew.org/wiki/Libogc">libogc</a>, which is a homebrew library for interfacing with the GameCube and Wii hardware. It makes writing, compiling, and testing homebrew a lot easier by providing APIs for interfacing with the hardware and tons of example projects. <strong><a href="https://github.com/eigenform">eigenform</a></strong> decided to write a test that <em>didn't</em> use libogc. While this was a much more difficult way of going about things, it ended up verifying that the problem was in libogc itself. With tons of developers already on-hand, it only took a few minutes to figure out that the supposed freeze was libogc forgetting to clear an interrupt and thus handling the same interrupt over and over again forever. This bug has now been fixed in the latest versions of libogc as a result of this testing.</p>
<p>Once the hardware tests were working, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> was able to test and verify exactly how uncached writes worked on console and implemented their broken behaviors into Dolphin. We asked the speedrunning community to make sure everything was working correctly and they came through, showing off <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask's</a> Virtual Console Any% route working correctly in Dolphin.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/ayyyDKCGXqw" allowfullscreen></iframe></div>
<figcaption>After the changes, Rylie confirmed that the latest route worked in Dolphin!</figcaption>
</figure>
</div>
<p>Without <strong><a href="https://www.youtube.com/channel/UCWYUUzuybieMseJy3KyCA7g">Rylie</a></strong> and the crazy <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Ocarina of Time</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Majora%27s_Mask">Majora's Mask</a> communities, we may not have ever known that uncached writes could be used in a retail title for anything useful...</p>
<p>That isn't to say that <em>nothing used it</em>, in fact, we've known about one particular <em>homebrew</em> that relied on it as a means of security. Closed source versions of the <a href="https://wiki.dolphin-emu.org/index.php?title=Homebrew_Channel">Homebrew Channel</a> have a ton of protections and strange behaviors to ensure it is being run in a responsible manner. One of the features that they relied on was this <em>broken</em> uncached write behavior. We didn't bother messing with it too much as, back in the day, Dolphin was wrong in so many ways that it wasn't even close to getting it to boot. But years of fixes have changed the landscape, and with support for unaligned uncached writes, closed source versions of the Homebrew Channel are finally showing signs of life in Dolphin. In fact, they'll even make it to the menu... albeit with a few <em>quirks</em>.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/thehbc1.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/thehbc1_thumb.png"/></a>
<figcaption>If the protections in old versions of the Homebrew Channel do not run corrrectly, they will not let you pass the scam warning. Though after an hour wait they will still boot into the menu on their own. </figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/thehbc2.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/thehbc2_thumb.jpg"/></a>
<figcaption>However they leave this friendly gesture.</figcaption>
</figure>
</div></div>
<p>Some of our users may be wondering how they've already been running the Homebrew Channel in Dolphin. Well, the latest version of the Homebrew Channel (referred to as the <a href="https://hackmii.com/2016/11/the-open-homebrew-channel/">Open Homebrew Channel</a>) removed all of the protections as a way to help Dolphin run it more easily. As most bad actors preying on the channel had long moved onto more modern consoles, the protections didn't do anything beyond cause headaches for Dolphin, which wasn't their intention. Still, it would be a neat accomplishment to actually defeat all of the trials of the older versions of the Homebrew Channel and get them to boot up without triggering any of the protection routines at all.</p>
<h4 id="50-14844-implement-late-vi-updates-by-techjar-and-phire"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14844/">5.0-14844 - Implement Late VI Updates</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong> and <strong><a href="https://github.com/phire">phire</a></strong><a class="headerlink" href="#50-14844-implement-late-vi-updates-by-techjar-and-phire" title="Permanent link">¶</a></h4>
<p>A lot of Dolphin's work around outputting frames has to do with getting things working with as little latency as possible. While many games make things simple by using the default Video Interface (VI) configuration and allow <a href="https://dolphin-emu.org/blog/2017/11/19/hybridxfb/#immediately-present-xfb">Dolphin to cheat past most XFB emulation</a> and reduce latency <em>beyond</em> what's possible on console, many games do more complex VI configurations. This forces Dolphin to do the right thing and actually emulate the scanout procedure. Even when doing that, Dolphin <em>still</em> cheats a little bit by outputting the XFB copy with the settings it has at the beginning of a field than applying them throughout the process of scanning out the XFB copy. This saves ~16ms of latency, was thought to be <em>globally</em> supported... until <a href="https://wiki.dolphin-emu.org/index.php?title=WWE_Crush_Hour">WWE Crush Hour</a> showed up.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/crushhour-flashing_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Imagine this at 60fps<br/><sub>Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/crushhour-flashing.mp4">HERE</a> for the actual speed version. Seizure warning.</sub></figcaption>
</figure>
</div>
<p>This strange, strange game does a behavior no one has seen in any other retail title: it changes VI settings <em>while</em> a frame is being scanned out to the screen. Dolphin couldn't do anything about it because it had already completed with incorrect VI settings by the time the game had changed them. After four years of an incorrect bisect, ZephyrSurfer rebisected the issue, realizing that the previous bisect to <a href="https://dolphin-emu.org/blog/2017/11/19/hybridxfb/">Hybrid XFB</a> was incorrect. This new bisect took them to <a href="https://dolphin-emu.org/download/dev/7ee6d082131cf40b8a8471ff3ac967e30326f59e/">5.0-146</a> and the latency optimization.</p>
<p>Upon seeing this, <strong><a href="https://github.com/phire">phire</a></strong> notified everyone of this latency hack and explained how to work-around the issue. Essentially, Dolphin just needed to add an option to wait <em>until the end of scanout</em> to actually scanout the frame. This would result in a full frame of extra latency, so they suggested that this be implemented as a separate option just for this game. While they were too busy, the instructions they left were clear enough for <strong><a href="https://github.com/Techjar">Techjar</a></strong> to implement this fix. It's important to note that neither of these implementations are <em>accurate</em>; in order to do things correctly, Dolphin would apply VI configurations <em>during</em> scannout, which would be a lot more difficult without much, if any, benefit.</p>
<h4 id="50-14866-d3d12-fix-gpu-texture-decoding-on-amd-by-k0bin"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14866/">5.0-14866 - D3D12 - Fix GPU Texture Decoding on AMD</a></strong> by <strong><a href="https://github.com/K0bin">K0bin</a></strong><a class="headerlink" href="#50-14866-d3d12-fix-gpu-texture-decoding-on-amd-by-k0bin" title="Permanent link">¶</a></h4>
<p>A new contributor to the project, <strong><a href="https://github.com/K0bin">K0bin</a></strong> noticed a missing memory barrier in Dolphin's D3D12 backend that could be causing issues with GPU Texture Decoding. While NVIDIA's drivers were unaffected (likely due to ignoring state transitions like they do image layout in Vulkan) turning on GPU Texture Decoding on AMD cards would cause serious problems and crashes. This is a one line change that fixes the oversight. </p>
<div class="media-block wide">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/6900xtscreenshot.png"></a>
<figcaption>This is where our 6900 XT fixed screenshot would be, if we had one!</figcaption>
</figure>
</div>
<h4 id="50-14821-50-14833-50-14897-and-50-15019-fix-dcbx-invalidation-performance-without-breaking-everything-this-time-by-admiralcurtiss-and-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14821/">5.0-14821</a></strong>, <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14833/">5.0-14833</a></strong>, <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14897/">5.0-14897</a></strong>, and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-15019/">5.0-15019</a></strong> - <strong>Fix <code>dcbx</code> Invalidation Performance Without Breaking Everything This Time</strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> and <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14821-50-14833-50-14897-and-50-15019-fix-dcbx-invalidation-performance-without-breaking-everything-this-time-by-admiralcurtiss-and-josjuice" title="Permanent link">¶</a></h4>
<p>If you've been following the development builds the last month, you might have noticed a trend with the <code>dcbx</code> (data cache invalidate/flush/zero etc.) changes. Our goal has been to make large invalidations fast <em>and</em> correct, but getting both at the same time has proven to be tricky. At the end of the last Progress Report, <a href="https://dolphin-emu.org/blog/2021/08/01/dolphin-progress-report-june-and-july-2021/#50-14768-jit-perform-bat-lookup-in-dcbfdcbidcbst-instructions-by-josjuice">we thought we had a simple fix to the performance regression regarding various data cache flush/invalidation instructions</a>. Everything seemed to be working fine in both of the broken cases, and developers thought the saga had reached its end. How foolish we were.</p>
<p>After the Progress Report launched, issue reports started rolling in, with the most popular series affected seeming to be the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Mario_%26_Sonic_(Series)">Mario and Sonic at the Olympic Games series</a>. Early analysis revealed that things were going very, very wrong. Dolphin's x86-64 JIT was misbehaving and double translating the address during <code>dcbx</code> and thus jumping to the wrong flag. Masking was also broken in <em>both</em> of Dolphin's JITs, leaving quite a few games broken at the turn of the month.</p>
<p><strong><a href="https://github.com/JosJuice">JosJuice</a></strong> and <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> teamed up to quickly fix the JITs and get things working again as soon as possible. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> focused on fixing the masking behavior in the AArch64 JIT and <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> made some bigger changes to the x86-64 JIT to make sure that Dolphin would always pass the <code>dcbx</code> instructions the correct effective address.</p>
<p>With their quick work, everything was running correctly again within less than two weeks. However, these fixes came at a rather ironic cost. These changes erased the performance gains from the last Progress Report, meaning that <a href="https://wiki.dolphin-emu.org/index.php?title=Arc_Rise_Fantasia">Arc Rise Fantasia</a> and the other games that invalidate large areas of memory at once were yet again having performance problems. In the simplest terms, things weren't in a very good place and there was some work to be done.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/arcrisefantasia.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-august/arcrisefantasia_thumb.jpg"></a>
<figcaption>Loading areas from the world map resulted in heavy FPS drops as the game cleared large chunks of memory.</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> dove back in to see exactly what was so slow and found the smoking gun. <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine's</a> initial boot, one of the worst case scenarios for <code>dcbx</code>, was invoking the page translation code <strong>134 million times</strong>. What's even weirder is that most of what the game is invalidating isn't even mapped to physical memory! Doing all of this as individual calls is just grossly inefficient, so something had to be done to batch things to reduce the overhead. So we took a cue from how <em>idleskipping</em> works. Idleskipping is a feature in Dolphin's JIT that looks for <em>loops</em> of code that are designed to just burn off excess CPU time. Instead of emulating these null operations, we can detect them and <em>skip</em> them, while adjusting the downcount and other things to greatly increase CPU performance.</p>
<p>While <code>dcbx</code> isn't a null operation like idleloops, by detecting a loop of them <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> made it so that instead of doing hundreds of millions of individual calls, Dolphin statically analyzes the situation to batch them into <em>one bigger dcbx</em>, and then adjust the downcount and other things so that this optimization ends up equivalent to the individual calls in terms of what the emulated environment sees. This trick restores performance to where it was before in these games <em>without</em> breaking anything else.</p>
<p>Both the x86-64 JIT and the AArch64 JIT are outfitted with this new optimization, with the latter being implemented by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong>. And <em>now</em> things should be both <em>fast</em> and <em>correct</em>, rather than us constantly bouncing between the two like we have the past couple of months.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-08-01&to=2021-09-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-14790/">5.0-14790</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-15105/">5.0-15105</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: June and July 2021
2021-07-31T22:04:05+00:002021-07-31T22:25:16.115100+00:00JMC47https://dolphin-emu.org/blog/authors/JMC47/https://dolphin-emu.org/blog/2021/08/01/dolphin-progress-report-june-and-july-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/progressreportheader-july2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/progressreportheader-july2021mini.jpg" />
</header>
<p>Emulation is often seen as this suspect gray area of gaming that is tolerated but always on the edge. There's a lot of negativity and questions around the merit and purpose of emulation. In contrast to that narrative, the overwhelmingly positive reaction to some of the features added the last few months, including heartfelt reactions from users, make all of the challenges and struggles so much easier.</p>
<p>As we drift further from the heyday of the GameCube and Wii, we've been seeing a greater impact not only on the past generations of gamers, but the current one. It was heartwarming to see long-time users able to play <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Four_Swords_Adventures">Four Swords Adventures</a> with their kids or friends across the world. The gratitude we received from users finally able to try previously hard-to-access features in their favorite games was so appreciated. We love these games and consoles the same as you, and we want to make sure that they live on.</p>
<p>Sometimes with all the negativity in emulation, it's refreshing to have something that makes both the developers and the users happy. And while we'd love to revel in past accomplishments, there's still so much more work to be done. We graciously thank everyone for their kind words over the past few months, and hope you continue to enjoy using Dolphin Emulator. With that said, it is about time that we get started with the June and July Progress Report.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-14690-integrate-mgba-into-dolphin-for-game-boy-advance-connectivity-features-by-bonta"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14690/">5.0-14690 - Integrate mGBA into Dolphin for Game Boy Advance Connectivity Features</a></strong> by <strong><a href="https://github.com/bonta0">bonta</a></strong><a class="headerlink" href="#50-14690-integrate-mgba-into-dolphin-for-game-boy-advance-connectivity-features-by-bonta" title="Permanent link">¶</a></h4>
<p>If you really want something, sometimes you have to go and make it happen yourself. And that's exactly what <strong><a href="https://github.com/bonta0">bonta</a></strong> did. He wanted to play <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Four_Swords_Adventures">Four Swords Adventures</a> on netplay with friends and was more than willing to put forth the work to make it happen. In the process he integrated <a href="https://mgba.io/">mGBA</a> into Dolphin, worked with <strong><a href="https://github.com/endrift">endrift</a></strong> on protocol bugs, and even <a href="https://dolphin-emu.org/download/dev/6042df71d934b0efa9dcb64f47e77a02a1e3cb96/">fixed issues</a> in <a href="https://dolphin-emu.org/download/dev/master/5.0-14306/">other games</a> to try and make it perfect for everyone. The end result? <strong>Every single Game Boy Advance (GBA) to GameCube connectivity game works in Dolphin</strong>. If you want to learn more about the GBA connectivity feature and its history, <a href="https://dolphin-emu.org/blog/2021/07/21/integrated-gba/">we wrote a huge article on it</a> and even made a <a href="https://youtu.be/bs--wWcFb9o">video demonstration</a>.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/blog/2021/07/21/integrated-gba/">
<img src="https://dolphin-emu.org/m/user/blog/integratedgba/mgbaintegrationheader.jpg"></a>
</figure>
</div>
<p>For a major feature that includes <em>integrating another whole emulator</em>, it has been an incredibly smooth launch. We haven't seen any major regressions, and we only broke the Ubuntu/Android buildbot for a couple of hours. However, after getting a taste of the Integrated GBA, users have been asking for <em>more</em> features regarding it. And we do admit, some aspects were purposefully kept simple in order to try and make sure everything went smoothly with the initial merge. Since then, several major features were added based on feedback from users and some things that we noticed ourselves.</p>
<p>First up, developers grossly underestimated how many people would want to use the e-Reader. Being such a fringe feature, we added support for dragging/dropping e-Reader cards onto the emulator but didn't add any indication that it works into the GUI. After seeing numerous complaints and confusion, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> implemented e-Reader controls into the GUI.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/scanereader.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/scanereader.png"></a>
<figcaption>Here by popular demand, clear GUI options to load e-Reader cards! Yay!</figcaption>
</figure>
</div>
<p>Bigger changes were also added by <strong><a href="https://github.com/bonta0">bonta</a></strong>, who brought forth a slew of new options based on feedback from the initial merge. Two of them have to do with how the GBA is displayed. First of all, we've added the much requested <strong>always on top</strong> option. This makes it so that no matter which window you click, your Integrated GBA will always be visible. Secondly, we've added the ability to remove the Integrated GBA's borders, which can make fitting things onto a single monitor much easier. </p>
<p>Beyond just displaying things, <strong><a href="https://github.com/bonta0">bonta</a></strong> also added interframe blending to the GUI. This is a feature of mGBA used to remove flickering and jumpiness in titles that rely on the ghosting behavior from GBA screens. Because the NES has more vertical resolution than the GBA, the GBA NES emulator in <a href="https://wiki.dolphin-emu.org/index.php?title=Animal_Crossing">Animal Crossing</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Nintendo_Puzzle_Collection">Nintendo Puzzle Collection</a> will render one set of pixels and then another on alternating frames and let the ghosting blend them together.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/nointerframe.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/nointerframe.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>In this short clip, you can see a noticeable jitter when there is no blending.</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/interframe.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/interframe.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>With interframe blending it looks like it does on console... err, handheld.</figcaption>
</figure>
</div>
<p>In addition to all of that, <strong><a href="https://github.com/bonta0">bonta</a></strong>, <strong><a href="https://github.com/leoetlino">leoetlino</a></strong>, and <strong><a href="https://github.com/JMC47">JMC47</a></strong> collaborated to port the <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#50-14306-gameini-patch-crystal-chronicles-race-condition-with-gba-by-bonta">Final Fantasy Crystal Chronicles Connectivity Patch</a> to the Japanese and PAL regions of <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a>. This is particularly important because the Japanese version has features and bugs not present in the other regions, which speedrunners use throughout their runs. Note that the connectivity patch fixes a bug in <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">the ROM that Final Fantasy Crystal Chronicles sends to the GBA</a>. The bug makes reestablishing a connection in levels very difficult when timings are too <em>perfect</em>.</p>
<p>As one final note, please remember that GBA connectivity features are currently handled through the GBA BIOS. As such, using the Integrated GBA requires the user to have a GBA BIOS. Because the GBA BIOS is a copyrighted piece of software, it cannot be included with Dolphin, much like the GameCube IPL and the console DSP-LLE ROM. While a free replacement may be possible, none exist at this time. Thankfully, there are plenty of <a href="https://glazedbelmont.github.io/gbabiosdump/">resources on how to dump a GBA BIOS from various handhelds</a>, or even with a <a href="https://github.com/FIX94/gba-link-cable-dumper">Game Boy Advance, GameCube Link Cable, and a GameCube/Wii</a>! </p>
<h4 id="50-14392-50-14394-and-50-14404-bounding-box-the-saga-continues-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14392/">5.0-14392</a></strong>, <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14394/">5.0-14394</a></strong>, and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14404/">5.0-14404</a></strong> - <strong>Bounding Box: The Saga Continues</strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14392-50-14394-and-50-14404-bounding-box-the-saga-continues-by-techjar" title="Permanent link">¶</a></h4>
<p><em>When we left our heroes last time...</em></p>
<p><strong><a href="https://github.com/Techjar">Techjar</a></strong> removed the extra rounding and the games started working <em>again</em>. And now we know to <em>never touch Bounding Box ever aga-</em></p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken_thumb1.jpg"/></a>
<figcaption>Wait what was that. Zoom, enhance!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken_thumb2.jpg"/></a>
<figcaption>@!#?@! </figcaption>
</figure>
</div></div>
<p><em>And now we rejoin them...</em></p>
<hr>
<p>After barely holding out against the Bounding Box onslaught on the eve of the last Progress Report, developers regrouped and planned a counter-attack at the heart of the Bounding Box menace in the days following. These final battles didn't have the grandeur of the previous battles; Bounding Box had already expended most of its resources and was left with only a fraction of the issues. This time, <strong><a href="https://github.com/Techjar">Techjar</a></strong> would ride alone onto the frontline with almost no resistance. His goal? Make Bounding Box work perfectly on <em>every</em> graphics backend and render correctly at every internal resolution. In the last battle, the D3D11 and D3D12 fronts had already been won, but OpenGL and Vulkan were still up in the air.</p>
<p>So what devious plot had conspired to take down OpenGL? Well, OpenGL has a quirk compared to all of the other APIs in Dolphin: It has a lower left origin. Every other backend uses an upper left origin which makes OpenGL render inverted in comparison. By now, developers know to invert values for OpenGL and <strong><a href="https://github.com/Techjar">Techjar</a></strong> was already doing that, albeit a bit too late. The values were being inverted <em>after</em> the conversion to pixel quads, resulting in some improper rounding. If you remember from last time, Bounding Box rounds to two-by-two groups of pixels called <em>Pixel Quads</em>, and doing this correctly was one of the key fixes that helped improve Bounding Box behavior. So rounding to the Pixel Quads <em>incorrectly</em> was defeating the whole purpose of the change! Fixing this oversight ended the issues in OpenGL.</p>
<p>Vulkan was a bit more difficult to analyze. Through messing with the code and disabling various optimizations, <strong><a href="https://github.com/Techjar">Techjar</a></strong> ascertained that something was wrong with Subgroup Reduction. This is an optimization that helps GPUs parallelize atomic operations. <em>Atomic operations</em> are operations that can't get interrupted by another thread once they have started and ensure sequential consistency when all of the threads finish. This is important, because if multiple warps (essentially threads) are operating on the same pixel at the same time and we're <em>also</em> doing comparisons on said pixel through Shader Storage Buffer Objects (SSBOs), it's very easy to end up with inconsistency and race conditions. Atomic operations ensure the values are correct and updated at the right time.</p>
<p>For those of you that are still following, all of this comes at a cost. Atomic operations have a lot of overhead. Modern GPUs love to work with highly paralellized workloads and this ends up forcing it to complete threads one at a time. Unfortunately, it's also the fastest way to emulate Bounding Box correctly.</p>
<p>That's where Subgroup Reduction comes in. It allows the GPU to do <em>multiple</em> atomic operations across many pixels and only update the values at the end of a particular group's calculations. By being able to run multiple atomic operations at once, this can <em>greatly</em> speed up Bounding Box emulation. The issue was that Dolphin was telling the GPU that a subgroup was finished when helper threads were still running, meaning that incorrect Bounding Box values were being read and written. The fix was to simply was take into account helper threads when reporting that a subgroup was finished. Unfortunately, by fixing all of these quirks we <em>also</em> fixed one of the funniest game issues we've seen in a <em>long</em> time.</p>
<div class="media-block">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/papermariostaircaseglitch.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/papermariostaircaseglitch.png"></a>
<figcaption>The infinite staircase made a cameo in Hooktail Castle.</figcaption>
</figure>
</div>
<p>So now every backend was working, right? This should have been the end, but Bounding Box would not concede without a fight. In the final batch of testing, we found out that the damn punies were broken at higher resolutions again! If you played <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a> in Dolphin back in the old days, these little annoying bugs were the absolute bane of your existence. The fact that they <em>just work</em> in modern builds is something we take for granted considering just how annoying of a problem they once presented. Users were desperate enough to even make custom texture packs <em>specifically</em> to fix the Punies in Dolphin because the glitch was so damaging and there was no work-around!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/puniesbroke.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/puniesbroke_thumb.jpg"></a>
<figcaption>Pain.</figcaption>
</figure>
</div>
<p>The problem was slightly different now: 1x internal resolution actually worked. It was only higher resolutions that had a problem with these changes. While he could have just told people to use lower resolutions, <strong><a href="https://github.com/Techjar">Techjar</a></strong> himself was not happy with this outcome. This saga was started by him; <a href="https://github.com/dolphin-emu/dolphin/pull/7957">his original Bounding Box adjustments</a> were the very ones that broke <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> and sent <strong><a href="https://github.com/JMC47">JMC47</a></strong> on the warpath. He knew that he had to be the one to finally end it.</p>
<p><strong><a href="https://github.com/Techjar">Techjar</a></strong> dug in and found out that increased pixel precision from running in higher resolutions was causing problems. When there are more pixels, Dolphin wasn't getting the same exact <em>center</em> that it was at native resolution. The solution? Simply ignore all of the extra pixels and only use the center pixels.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pixelexample.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pixelexample.png"></a>
<figcaption>At 5x Internal Resolution, only the center pixel within each 5x5 sector is sampled.</figcaption>
</figure>
</div>
<p><em>So now</em> we're fairly confident that this should be the last of the Bounding Box issues. In preparation for the Progress Report, <em>every single bounding box game was tested on every backend at every internal resolution</em>. In fact, during our testing, we even found out that one of the seven titles listed to use Bounding Box doesn't actually use Bounding Box. <a href="https://wiki.dolphin-emu.org/index.php?title=Speed_Challenge:_Jacques_Villeneuve%27s_Racing_Vision">Speed Challenge</a> has been forcing it on in the INI for over a decade, yet it doesn't even touch the Bounding Box registers. The game doesn't actually run in Dolphin, but <strong><a href="https://github.com/JMC47">JMC47</a></strong> was able to hack up a build that could get it in-game so we could test it out.</p>
<div class="media-block">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/speedchallenge.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/speedchallenge_thumb.jpg"></a>
<figcaption>There was no documented way to get in-game in Speed Challenge before JMC47 investigated it.</figcaption>
</figure>
</div>
<p>So now our list of Bounding Box games falls to <em>five</em>. Yes, <em>five</em>. Turns out one of the other Bounding Box games was just an erroneous duplicate of <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Hide_%26_Sneak">Disney's Hide & Sneak</a> in a different region. The other four are <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Magical_Mirror_starring_Mickey_Mouse">Disney's Magical Mirror</a>.</p>
<h4 id="50-14359-aarch64-jit-fix-branch-following-optimization-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14359/">5.0-14359 - AArch64 JIT - Fix Branch Following Optimization</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14359-aarch64-jit-fix-branch-following-optimization-by-josjuice" title="Permanent link">¶</a></h4>
<p>Branch Following is a <em>big</em> JIT optimization that allows Dolphin to make longer code blocks by inlining code from branches. This results in increased CPU performance in most games. Both the x86-64 JIT and the AArch64 JIT have this feature, but users noticed that the AArch64 JIT was having some problems with it. After seeing multiple reports of users forcibly disabling Branch Following, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> started investigating the problem and bought one of the most popular afflicted games: <a href="https://wiki.dolphin-emu.org/index.php?title=Need_for_Speed:_Carbon_(GC)">Need for Speed: Carbon</a>.</p>
<p>The issue ended up being a rather convoluted one to debug. The broken games would set up a case where Dolphin could <em>follow</em> a call, but not the return. With the <a href="https://dolphin-emu.org/blog/2014/09/30/dolphin-progress-report-september-2014/#40-3271-opportunistically-predict-blr-with-ret-by-comex">BLR optimization</a> enabled, Dolphin needs the host link register for the return address. This is normally not a problem, but if register pressure was high enough, it could opt to use the link register for something else. Without the host link register being intact, Dolphin would jump to somewhere invalid and potentially crash. Once <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> knew what was wrong, it was a relatively easy fix to make sure Dolphin locks the link register so that it can't get overwritten when it is still needed.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/nfsbf.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/nfsbf_thumb.jpg"></a>
<figcaption>Need for Speed: Carbon no longer crashes when using Branch Following.</figcaption>
</figure>
</div>
<p>While having Branch Following enabled makes Dolphin's AArch64 JIT faster, how much it affects your device will depend on what the particular game is bottlenecked on. On Dual Core, the device may be completely limited by the GPU thread and not see any benefit whatsoever. In other cases, Branch Following can result in tremendous performance increases. Either way, users no longer have to worry about turning Branch Following off just to make their favorite games run.</p>
<h4 id="50-14427-replace-memcard251-override-with-generic-memcard-sizes-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14427/">5.0-14427 - Replace Memcard251 Override with Generic Memcard sizes</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14427-replace-memcard251-override-with-generic-memcard-sizes-by-techjar" title="Permanent link">¶</a></h4>
<p>When Nintendo launched the GameCube, they might have miscalculated a bit on how much memory games would need for their saves. The original 59-block memory cards were only 4Mbit and could only store a handful of saves. They were also rather slow, which is problematic with how big saves would get with later games on the system. To no one's surprise, Nintendo released bigger, faster offerings with the 251 (16Mbit) and 1019 (64Mbit) block memory cards. These cards gave players much more breathing room and sped up savetimes in games that would write large save files. The only real downside to using them <em>should have been</em> the hard limit of 127 savefiles; as the file system could not handle anything beyond that even if you had empty blocks! Unfortunately, reality doesn't always line up with expectations. </p>
<p>Being that these memory card sizes are so insignificant for modern storage devices, Dolphin's developers thought it would be best for users if the emulator defaulted to using the biggest possible memory card: a 2043-block monster that was only released by third parties such as datel. Unfortunately, due to bugs in <em>numerous</em> games, they won't recognize anything beyond a 251-block memory card as a valid saving device, even on console! To combat this, Dolphin had a hidden setting called <em>Memcard251</em>, that could be put into the INI files to force a 251-block memory card.</p>
<p>This was a rather nifty solution that fixed saving issues in these games without inconveniencing users. It affected the <strong>GCI Folder</strong> feature, too! Instead of having the saves on a separate memory card, they're all stored in one place. The difference is that when the GCI folder is <em>constructed</em> into the memory card at boot, Dolphin simply constructs a smaller one. And it wasn't stupid about how it used the space it had; GCI folders knows to pull in the savefile of <a href="https://wiki.dolphin-emu.org/index.php?title=Pikmin_(GC)">Pikmin</a> when launching <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Melee">Melee</a>, and the savefile from <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> when launching <a href="https://wiki.dolphin-emu.org/index.php?title=Metal_Gear_Solid:_The_Twin_Snakes">Metal Gear Solid: The Twin Snakes</a>.</p>
<p>So you're probably wondering why this change replaces Memcard251 with something else, right? Well, <em>Nintendo themselves</em> decided to throw us a curveball with the Japanese version of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a>. <a href="https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/#bonus-development-diary-the-great-mystery-of-pokemon-box">While trying to solve the infamous adventure mode crash</a>, we ended up seeing a lot of complaints that the Japanese version didn't work, and would get stuck on the main menu with an unreadable error.</p>
<div class="media-block">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pboxerror.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pboxerror_thumb.jpg"></a>
<figcaption>If you can't read Japanese, you might not know why the game was freaking out.</figcaption>
</figure>
</div>
<p>If you're familiar with Japanese, you already know what it's telling us. This game <strong>only works with 59-block memory cards</strong>. Not due to any kind of bug, but due to a rather odd design decision. Our best guess is that because the game came with a 59-block memory card, Nintendo really only wanted you using the game with that card. Unfortunately, this left us in a rather tricky situation. We couldn't just globally change Memcard251 to Memcard59; those memory cards were so small that some of the bugged games would completely fill them up alone. We needed to do some serious changes <em>for this one game</em>.</p>
<p>Rather than hacking something up or putting an exception in the code, <strong><a href="https://github.com/Techjar">Techjar</a></strong> bit the bullet and rewrote the Memcard251 option to support arbitrary sizes that could be set on a per-game basis. So now for this <em>one</em> game, Dolphin has made its memory card size code support arbitrary sizes. Thanks, Nintendo.</p>
<p><em>Note: 5 blocks and one file of each memory card are dedicated to system data, so a 59-block memory card really has 64 total blocks with five you can never access. In addition, more games have been marked to use smaller memory cards to prevent saving issues. This includes <a href="https://wiki.dolphin-emu.org/index.php?title=SSX_Tricky">SSX Tricky</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=SpongeBob_SquarePants:_Creature_from_the_Krusty_Krab_(GC)">SpongeBob SquarePants: Creature from the Krusty Krab</a> both being forced to use 251-block memory cards.</em></p>
<h4 id="50-14447-patch-fix-gladius-ntsc-hang-by-smurf3tte"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14447/">5.0-14447 - Patch: Fix Gladius (NTSC) Hang</a></strong> by <strong><a href="https://github.com/smurf3tte">Smurf3tte</a></strong><a class="headerlink" href="#50-14447-patch-fix-gladius-ntsc-hang-by-smurf3tte" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Gladius">Gladius</a> is an unfortunately difficult game to emulate. One of Dolphin's biggest weaknesses is that both its CPU and GPU timing pipelines aren't close to cycle accurate. And getting <em>better</em> is going to be really difficult, especially without breaking more games or destroying performance. If something like cache hits are emulated, suddenly our CPU pipeline will be far too slow without emulating one of the missing features to make the CPU faster. These timing issues can be seen throughout games with rather minor consequences in most cases.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Gladius">Gladius</a> is a game that simply relies on better CPU/GPU pipeline timings than Dolphin has, and that makes it challenging to emulate. <strong><a href="https://github.com/smurf3tte">Smurf3tte</a></strong> decided to try and figure out exactly what was going wrong and see if there was another way to fix it. Rather than trying to make Dolphin more accurate, <strong><a href="https://github.com/smurf3tte">Smurf3tte</a></strong> opted to try and make <a href="https://wiki.dolphin-emu.org/index.php?title=Gladius">Gladius</a> more tolerant of Dolphin's limitations <em>and succeeded</em>. They patched out the race condition that made <a href="https://wiki.dolphin-emu.org/index.php?title=Gladius">Gladius</a> so difficult to run and left developers with a difficult quandary: Should this game patch be merged and enabled by default?</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/gladius.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/gladius_thumb.jpg"></a>
<figcaption>This strategy RPG has caused developers many headaches over the years.</figcaption>
</figure>
</div>
<p>This isn't the first time a patch was developed to work around a game limitation. However, in the other situations, Dolphin was dealing with behaviors and issues that it will likely never to be able to emulate. <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Casper%27s_Scare_School:_Spooky_Sports_Day">Casper's Scare School: Spooky Sports Day</a> are good examples of this. They all rely on CPU data cache behaviors due to game bugs, and Dolphin can't emulate that without sacrificing so much performance that it wouldn't be worth it fo the average user.</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Gladius">Gladius</a> is different; it isn't really doing anything special. Someday, Dolphin <em>should</em> be accurate enough to emulate it. That's what made considering this patch so much different than the others. In the end, it came down to three key factors:</p>
<ul>
<li>Even with correct emulation, Dual Core would have never run this game.</li>
<li>There's no guarantee Dolphin's timings will ever be good enough to handle this game.</li>
<li><strong><a href="https://github.com/smurf3tte">Smurf3tte</a></strong> reverse engineered the problem so that we now know what needs to be done to emulate it correctly.</li>
</ul>
<p>Since you're reading about this in the Progress Report, it's obvious that developers opted to merge the patch and make the game immediately playable. This patch affects the NTSC version of the game and is enabled by default in the latest development builds. Our hope is that this patch won't be necessary down the line, but even if that day comes it will still be useful as an option for users on weaker machines that need to use Dual Core.</p>
<h4 id="50-14514-dvdinterface-keep-cache-for-an-additional-block-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14514/">5.0-14514 - DVDInterface: Keep Cache for an Additional Block</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14514-dvdinterface-keep-cache-for-an-additional-block-by-josjuice" title="Permanent link">¶</a></h4>
<p>Dolphin's DVD timing model is a point of pride for the project. While it's impossible to be perfect simply due to the fact that there's so much variance even on real consoles, Dolphin's DVD read timings usually fall around where an original Wii would rate. Which makes sense, as a majority of the timing results come from a first generation Wii DVD drive. That's why we found it odd when speedrunners from the Pitfall community reached out to us and told us that they had to use older builds for testing due to DVD timing problems in modern builds. The report was that things weren't just a little off, they were <em>incredibly</em> wrong in <a href="https://wiki.dolphin-emu.org/index.php?title=Pitfall:_The_Lost_Expedition">Pitfall: The Lost Expedition</a> and its <a href="https://wiki.dolphin-emu.org/index.php?title=Pitfall:_The_Big_Adventure">Wii port</a>.</p>
<p>Their bisect brought us to a DVD timing change in <a href="https://dolphin-emu.org/download/dev/master/4.0-9019">4.0-9019</a> that was hardware tested to be correct. One of the dangers of hardware testing is that sometimes you don't test <em>enough</em> and make assumptions to fill in the gaps. Most of the time this is fine, but on console there are tons of weird edge-cases that can crop up. Investigation proved that it indeed was. <a href="https://dolphin-emu.org/download/dev/master/4.0-9019">4.0-9019</a> changed Dolphin so that it now ignored the buffer when seeking backwards. While we knew the DVD drive cached the current block, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> checked the DVD read patterns of <a href="https://wiki.dolphin-emu.org/index.php?title=Pitfall:_The_Lost_Expedition">Pitfall: The Lost Expedition</a> and found out that it was reading one block backwards. Once they knew that was the issue, they tested the behavior on console and indeed discovered that the previously read block was still cached, resulting in Dolphin being much slower than real hardware in this case. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> rectified the issue by letting Dolphin cache the previously read block instead of just the current one.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pitfallloading.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/pitfallloading.png"></a>
<figcaption>Get comfortable on old builds, you'll be waiting here for a while.</figcaption>
</figure>
</div>
<h4 id="50-14768-jit-perform-bat-lookup-in-dcbfdcbidcbst-instructions-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14768/">5.0-14768 - JIT: Perform BAT Lookup in dcbf/dcbi/dcbst Instructions</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14768-jit-perform-bat-lookup-in-dcbfdcbidcbst-instructions-by-josjuice" title="Permanent link">¶</a></h4>
<p>It turns out fixing <a href="https://wiki.dolphin-emu.org/index.php?title=Happy_Feet_(GC)">Happy Feet</a> came at an incredible cost. <a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#jit-improvements-by-josjuice-sintendo-merrymage-and-smurf3tte">Near the beginning of the year</a>, <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> fixed up Dolphin's JIT to correctly translate effective addresses to physical addresses for the dcbx family of instructions.</p>
<p>The original bug goes back to <a href="https://github.com/dolphin-emu/dolphin/pull/2663">2015</a> when an optimization to dcbx was implemented by <strong><a href="https://github.com/degasus">degasus</a></strong>. It was rather simple; since most dcbi/dcbf/dcbst instructions are essentially NOPs in Dolphin, we could inline the checks that were part of the C++ function and skip calling into C++ most of the time. This assumption falls apart in <a href="https://wiki.dolphin-emu.org/index.php?title=Happy_Feet_(GC)">Happy Feet</a> because it uses these instructions with ARAM addresses rather than what games typically use: addresses to MEM1, mapped with the default BAT. Addresses mapped to ARAM are problematic because simple masking can't actually be used to convert effective addresses to physical addresses, so actually determining the real addresses is necessary. Simple enough to fix, right? <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> reverted the broken optimization and restored the behavior to how it once was. Sure, having to call out to C++ code to check the addresses would be slow, but there's no way games would rely on these instructions to the degree it'd matter, right?</p>
<p><a href="https://bugs.dolphin-emu.org/issues/12477">Wrong.</a> <a href="https://bugs.dolphin-emu.org/issues/12463">Very wrong.</a> <a href="https://bugs.dolphin-emu.org/issues/12593">So very wrong.</a></p>
<p>Tons of games from <a href="https://wiki.dolphin-emu.org/index.php?title=Arc_Rise_Fantasia">Arc Rise Fantasia</a> to <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Colosseum">Pokemon Colosseum</a> relied on these instructions enough to see extreme performance losses on loading and transitions between areas. With <a href="https://wiki.dolphin-emu.org/index.php?title=Arc_Rise_Fantasia">Arc Rise Fantasia</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=A_Boy_and_His_Blob">A Boy and his Blob</a> these stutters would frequently occur during regular gameplay making them difficult to enjoy.</p>
<p><strong><a href="https://github.com/JosJuice">JosJuice</a></strong> was pulled away from more interesting projects to address this regression before the next (this) Progress Report. They reintroduced <strong><a href="https://github.com/degasus">degasus</a></strong>'s optimization, but changed it to actually look up the correct addresses without jumping to C++ code. This restores performance in all of those games while still being able to support the rare case of <a href="https://wiki.dolphin-emu.org/index.php?title=Happy_Feet_(GC)">Happy Feet</a>.</p>
<h4 id="50-14599-videocommon-fix-skyward-sword-map-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14599/">5.0-14599 - VideoCommon: Fix Skyward Sword Map</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-14599-videocommon-fix-skyward-sword-map-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Mere days before the release of Skyward Sword HD, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> finally solved the last major emulation mystery in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">Skyward Sword</a> for Wii. In Dolphin, when looking at the many maps, they would appear much flatter and duller than on console. The map never worked perfectly, and its current status goes all the way back to <a href="https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/">a major graphics pipeline rewrite dubbed <strong>tev-fixes-new</strong> in 2014</a>. Since then, nothing has affected it and hadn't been much hope toward fixing it.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssdolphin.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssdolphin_thumb.jpg" /></a>
<figcaption>Dolphin's map is lacking color details and looks flat.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssconsole.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssconsole_thumb.jpg" /></a>
<figcaption>Meanwhile, on console you can see colors shift with the height of the terrain.</figcaption>
</figure>
</div></div>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> figured that the best way to solve what was wrong was to bisect it to the <em>exact commit</em> within tev-fixes-new to figure out what part of the rewrite changed rendering. It wasn't a particularly easy task as many of these commits do not compile or produce broken shaders, meaning <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> had to manually compile and repair these builds in order to actually get an exact bisect. But through this process and studying fifologs, they uncovered how the map was dynamically rendered and figured out exactly why it was broken in Dolphin.</p>
<blockquote>
<p>It turns out that this commit swapped the shifts used for "bump alpha" and the indirect offset; per libogc, the indirect offsets are the high bits and the bump alpha comes from the low bits. (This is further confounded by bump alpha being only 5 bits; in the most common ITF_8 case where bump alpha and the indirect offset are both from the same value, it seems like it does use the top 5 bits, though I haven't hardware tested it). The old code handled it mostly correctly, but because it was trying to implement bit manipulation using floats, it had various rounding issues (and was hard to understand).</p>
</blockquote>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> reimplemented the handling to behave like the old code within Dolphin's integer math shaders. By doing so, they restored color to the maps of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">Skyward Sword</a>.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssfixed.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/ssfixed_thumb.jpg"></a>
<figcaption>Because it's dynamically generated, the map looks fantastic at higher resolutions.</figcaption>
</figure>
</div>
<p>If you care to know more about how the Skyward Sword map renders, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> wrote <a href="https://gist.github.com/Pokechu22/dfebe2758d23faeba48bb7c9fb8557a2">a tremendously detailed examination of how it renders</a> that will satiate even the most curious of minds. For the rest of us, this is one of the final oddities from tev-fixes-new. The other one, ironically enough, was in another Zelda game: <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">The Legend of Zelda: Twilight Princess</a>. Speaking of which...</p>
<h4 id="50-14602-videocommon-fix-texture-scale-masking-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14602/">5.0-14602 - VideoCommon: Fix Texture Scale Masking</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-14602-videocommon-fix-texture-scale-masking-by-pokechu22" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">The Legend of Zelda: Twilight Princess</a> was a poster child of the now infamous tev-fixes-new graphics rewrite. It was one of the games that <em>really</em> showed off just how important integer math was for emulating the GameCube/Wii GPU, and why developers made the decision despite how unpopular it was at the time. There was just so many important scenes in the game marred by graphical glitches that, while the game was playable, it was a very different experience in Dolphin. It was <em>even</em> used in the header for the release article!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/">
<img src="https://dolphin-emu.org/m/user/blog/Tev_Fixes_New/tev_fixes_new-Header.jpg"></a>
</figure>
</div>
<p>While tev-fixes-new was undeniably a net gain, it also caused a few regressions in rendering that we originally missed. <a href="https://bugs.dolphin-emu.org/issues/10346">Reported four years after the initial merge</a>, it turns out that the skin and eyes on certain characters were misbehaving and the culprit was this massive set of changes. The easiest place to see these problems were in Zora's domain, where the Zora people showed very obvious defects.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/tpzora.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/tpzora_thumb.jpg"></a>
<figcaption>Characters have looked a bit wrong ever since tev-fixes-new merged. None more obvious than the Zora.</figcaption>
</figure>
</div>
<p>So what exactly happened that could have eluded our sight for so many years? Well, it turns out this is a bit of a game bug. The game is supplying a texture scale value that is much higher than what it is actually using. However, when tested on the GameCube/Wii hardware, the scale value was being masked to something more reasonable. For example supplying a scale value of 47 is the same as supplying one of 15, resulting in a scale factor of 2<sup>15-17</sup> = 2<sup>-2</sup>. Correcting for this masking behavior fixes various blending issues throughout <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">Twilight Princess</a>.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/tpskinfixed.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/tpskinfixed_thumb.jpg"></a>
<figcaption>Now, we can finally get the accuracy benefits without the downsides.</figcaption>
</figure>
</div>
<p>While <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess">The Legend of Zelda: Twilight Princess</a> may have been home to the most obvious bugs caused by this defect, Dolphin's FifoCI automated testing infrastructure <em>also</em> found that this change affected two other games. Firstly, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">Wind Waker</a> saw some very minor rounding changes on some textures, but <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Sunshine</a> had something more interesting show up.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/smsbubbles.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/smsbubbles_thumb.jpg"></a>
<figcaption>Dolphin's FifoCI infrastructure caught a fix no one even noticed! Left side is the newer build on FifoCI.</figcaption>
</figure>
</div>
<p>That's right, the bubbles in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> are finally rendering correctly! All of these changes have been hardware verified with the hardware fifolog player. While it was left in disrepair for many years, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> revived <strong><a href="https://github.com/neobrain">neobrain's</a></strong>'s old project. One of the interesting things is that we thought the bubbles were fixed all the way back in 2014, because they were <em>even more broken</em> in floating point math.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/Tev_Fixes_New/SuperMarioSunshineBubblesMaster.png"><img src="https://dolphin-emu.org/m/user/blog/Tev_Fixes_New/SuperMarioSunshineBubblesMaster_thumb.jpg" /></a>
<figcaption>Floating Point Math caused all kinds of issues...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/Tev_Fixes_New/SuperMarioSunshineBubblesTevFixes.png"><img src="https://dolphin-emu.org/m/user/blog/Tev_Fixes_New/SuperMarioSunshineBubblesTevFixes_thumb.jpg" /></a>
<figcaption>Early integer math looked more correct, though we now know this was still wrong.</figcaption>
</figure>
</div></div>
<p>Looking through the <a href="https://dolphin-emu.org/blog/2014/03/15/pixel-processing-problems/">Pixel Processing Problems</a> blog post, seeing <em>just how much it fixed</em> is outright stunning. But there's another side of things that re-reading the article will reveal if you're an avid reader of the blog: A lot of those games still had minor problems <em>even in the featured screenshots showing off why tev-fixes-new was important</em>! Still when compared to how Dolphin rendered <em>before</em> tev-fixes-new, it represents an important turning point in development philosophy that shifted where Dolphin was heading. And now with these last two changes from <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> all of the known regressions from tev-fixes-new are fixed, and that chapter of Dolphin can finally be put to rest.</p>
<h4 id="50-14617-wii-remote-reporting-mode-changes-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14617/">5.0-14617 - Wii Remote Reporting Mode Changes</a></strong> by <strong><a href="https://github.com/Billiard">Billiard</a></strong><a class="headerlink" href="#50-14617-wii-remote-reporting-mode-changes-by-billiard" title="Permanent link">¶</a></h4>
<p>Sometimes the best laid plans blow up in your face. For <strong><a href="https://github.com/Billiard">Billiard</a></strong>, this happened a couple of month ago when they tied Wii Remote reporting rate to whether the Wii Remote Speaker was enabled. Dolphin currently has a hack to duplicate Wii Remote Data when using <em>Emulated Bluetooth</em>. This is because we can't enter the 200 Hz Sniff Mode the same way as on a real Wii. Without running at <em>true</em> 200 Hz, audio gets extremely garbled, but Dolphin does its best by duplicating packets in the 100 Hz communication that we can get on standard Bluetooth stacks. If running at 100 Hz, games don't tend to report Wii Remote audio at all.</p>
<p>Unfortunately, a few games do not like this packet duplication whatsoever, including <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_and_the_Secret_Rings">Sonic and the Secret Rings</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Jett_Rocket">Jett Rocket</a>. In the worst case, certain motions would never read. In the best case? They were just harder to control than usual.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/secretrings.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/secretrings_thumb.jpg"></a>
<figcaption>Secret Rings refuses duplicated motion packets, which is why it is renowned as one of the best controlling motion controlled games. Wait, it isn't?</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Billiard">Billiard</a></strong> thought that by tying the duplication to an already existing option, we could easily fix this problem without impacting users. Since we needed the 200 Hz for Wii Remote audio, the idea was to <em>tie</em> the duplication to that setting. It was a good idea in theory and seemed to fix <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_and_the_Secret_Rings">Sonic and the Secret Rings</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Jett_Rocket">Jett Rocket</a>.</p>
<p>Then everything went sideways. Rampant reports of flickering pointers and broken motions in other games flooded the support forums and social media. And this wasn't just shovelware, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> was among the many titles that thought <em>100 Hz reporting</em> was because of <em>bad signal quality</em>. In order to prevent signal quality from impacting gameplay, these games would disable the Wii Remote pointer, ignore motions, or try to disconnect and reconnect the Wii Remote. The only way to fix this would be to enable Wii Remote Audio to get the 200 Hz duplication enabled. For users that had no knowledge of what any of the technical details behind these options, it was a rather confusing solution. Most of them didn't want Wii Remote audio on in the first place because it sounded so bad <em>because</em> of the required duplication.</p>
<p>To rectify this problem, we've now separated packet duplication off into its own hidden setting. The idea is to keep this problem a silent process from the users and enable it on a per-game basis for games that we know are broken with packet duplication. The first two games where we've done this are the aforementioned <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_and_the_Secret_Rings">Sonic and the Secret Rings</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Jett_Rocket">Jett Rocket</a> but there are likely other games out in the wild that need this. If you run into a game where you're using a Real Wii Remote but can't get certain motions to work, try adding the setting <em>RealWiiRemoteRepeatReports = False</em> to the GameINI and let us know if it fixes it.</p>
<p><em>Note: Bluetooth Passthrough is able to successfully enter 200 Hz Sniff mode, and does not suffer from any of these issues.</em></p>
<h4 id="50-14626-dsp-hle-fix-small-ax-hle-issue-by-leoetlino"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14626/">5.0-14626 - DSP-HLE - Fix Small AX HLE Issue</a></strong> by <strong><a href="https://github.com/leoetlino">leoetlino</a></strong><a class="headerlink" href="#50-14626-dsp-hle-fix-small-ax-hle-issue-by-leoetlino" title="Permanent link">¶</a></h4>
<p>Sometimes, the smallest of differences can create the biggest of issues. If you are a fan of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Sims_2:_Castaway">The Sims 2: Castaway</a>, Dolphin might seem like a match made in heaven. With CPU overclocking features, you can make the game run far better than it ever did on console thanks to its dynamic framerate and the various control options can make for a more comfortable playthrough. However, your vacation would go wrong roughly fifteen minutes in, as Dolphin would suddenly crash without warning just before first nightfall.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/thesimscastaway.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/thesimscastaway_thumb.jpg"></a>
<figcaption>Death awaited those willing to venture out under the guise of darkness...</figcaption>
</figure>
</div>
<p>Having seen this issue reported several times, <strong><a href="https://github.com/JMC47">JMC47</a></strong> reluctantly looked into it. Because these crashes had been described as <em>random</em>, that made it a rather annoying issue to reproduce. Spending a long time playing a single game with no idea how to trigger the problem can feel like a waste of time. But it had to be done. Thankfully, this crash wasn't random but was instead on a timer. After about 15 minutes, the game crashed just as the issue reports had described. Upon rerunning the test several times, he found that the crash happened at exactly the same time on the first night, making it fairly easy to predict when it was going to crash for examination. The address that the game spit out pointed to a potential <a href="https://dolphin-emu.org/blog/2017/10/02/dolphin-progress-report-september-2017/#50-5395-and-50-5578-dsp-accelerator-fixes-by-leoetlino">DSP Accelerator issue</a>, so he again roped <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> in to investigate.</p>
<p>One sanity test that <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> requested to be done was to make sure that the DSP-LLE didn't fix the issue. Though most of the DSP Accelerator code is similar between DSP-HLE and DSP-LLE, it would make debugging the issue so much easier if we had a working model we could examine. Shockingly enough, <strong>DSP-LLE did not crash!</strong> This meant the issue was most certainly somewhere in DSP-HLE, but where?</p>
<p>At that point, <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> dumped the same AXWii µcode (microcode) from another game and began reversing how it worked and what it was doing. He then compared data dumps and logs from <a href="https://wiki.dolphin-emu.org/index.php?title=The_Sims_2:_Castaway">The Sims 2: Castaway</a> when running on DSP-HLE and DSP-LLE to try and look for differences. In order to get a leg up in examining the µcode, <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> reached out to <strong><a href="https://github.com/delroth">delroth</a></strong>, the original writer of most of Dolphin's current AX-HLE implementation. Thankfully, <strong><a href="https://github.com/delroth">delroth</a></strong> still had a lot of the debugging information and annotated disassembly from those days and helped <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> get a much clearer image of how the µcodes worked. And with all of this information and debugging, we were able to find a very silly oversight.</p>
<p>There is a field in Parameter Block (PB) Struct called "running" that is set to 0 or 1. DSP-LLE and DSP-HLE implemented this roughly the same, but with a key difference. DSP-LLE was checking if the value was set to 1 while DSP-HLE was checking to see if the value <em>wasn't</em> set to 0. This difference is negligible, as "running" should only ever be set to 0 or 1.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/dspdiagram.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/dspdiagram.png"></a>
<figcaption>The AX µcode does CMPIS to check if the value is 1.</figcaption>
</figure>
</div>
<p>The keyword here is <em>should</em>. For some unknown reason, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Sims_2:_Castaway">The Sims 2: Castaway</a> doesn't always set "running" to 0 or 1. Sometimes it likes to set it to... <em>8</em>. And because 8 is <em>not equal</em> to 0, DSP-HLE was continuing to play audio into invalid memory ranges. Since DSP-LLE was running the real µcode, it handled it correctly. The value of 8 does not equal 1, so it stopped running as it would on console. This was incredibly esay to fix, <strong><a href="https://github.com/leoetlino">leoetlino</a></strong> did need to make sure that the other AX µcode's shared this behavior. Once that was verified, the fix was submitted and merged.</p>
<p>Finally, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Sims_2:_Castaway">The Sims 2: Castaway</a> can be put to rest. But that's not the <em>complete</em> end of this story. One game setting weird numbers to PBs wasn't enough. While looking through DSP-HLE issues to fix, <strong><a href="https://github.com/tilka">flacs</a></strong> discovered that this change also fixes severe audio issues in <a href="https://wiki.dolphin-emu.org/index.php?title=Dinotopia:_The_Sunstone_Odyssey">Dinotopia: The Sunstone Odyssey</a> when using DSP-HLE.</p>
<p><em>Note: is_stream was found to have the same problem and was also fixed. Currently we do not believe this affects any games...</em></p>
<h4 id="50-14712-dsp-hle-re-enable-low-pass-filter-by-flacs-original-fix-by-merrymage"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14712/">5.0-14712 - DSP-HLE - Re-enable Low Pass Filter</a></strong> by <strong><a href="https://github.com/tilka">flacs</a></strong>, original fix by <strong><a href="https://github.com/MerryMage">MerryMage</a></strong><a class="headerlink" href="#50-14712-dsp-hle-re-enable-low-pass-filter-by-flacs-original-fix-by-merrymage" title="Permanent link">¶</a></h4>
<p>This is a rather awkward situation where the original bug was <a href="https://github.com/dolphin-emu/dolphin/pull/5211">actually fixed years ago</a>. While repairing audio in <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Star Wars: Rogue Squadron II</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars: Rogue Squadron III</a> for DSP-HLE, <strong><a href="https://github.com/MerryMage">MerryMage</a></strong> also added support for µcodes <em>without</em> the Low Pass Filter. This is because these games, along with others, used an early revision of the AX µcode that didn't yet support the Low Pass Filter. Back then, Dolphin's support for AX µcode revisions wasn't stellar and in order to account for differences in support, the Low Pass Filter was one of many features completely disabled when using DSP-HLE.</p>
<p>This oversight meant that <em>even though</em> the Low Pass Filter could have been re-enabled with no consequence back in <a href="https://dolphin-emu.org/download/dev/e863604b7ea53c98f3c4ee7bfebea949482d9eae/">5.0-3260</a>, no one did. Once <strong><a href="https://github.com/tilka">flacs</a></strong> realized that all the work was done, all they had to do was make sure the games that didn't support it weren't broken. The entire process took a couple of hours, and now the Low Pass Filter is re-enabled in the latest builds!</p>
<p>For those that aren't audio engineers, a Low Pass Filter cuts off audio above a certain frequency, only letting lower-frequency signals pass. This allows games to create a muffled effect, and is commonly used when underwater. For example, <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Colors">Sonic Colors</a> makes great use of the Low Pass Filter to give parts of stages a unique feel. Without the Low Pass Filter, many of the underwater stages simply sound flat.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/soniccolorsnolpf.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>With no Low Pass Filter, going underwater does nothing.</figcaption>
</figure>
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/soniccolorslpf.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>With a Low Pass Filter, the music and sounds are more immersive.</figcaption>
</figure>
</div></div>
<p>Considering that most games support the Low Pass Filter, this will likely fix missing audio effects throughout a lot of games when using DSP-HLE. We've already confirmed <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Colors">Sonic Colors</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a> as having missing effects restored.</p>
<h4 id="50-14740-dsp-hle-fix-and-re-enable-polyphase-resampling-by-flacs"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14740/">5.0-14740 - DSP-HLE - Fix and Re-enable Polyphase Resampling</a></strong> by <strong><a href="https://github.com/tilka">flacs</a></strong><a class="headerlink" href="#50-14740-dsp-hle-fix-and-re-enable-polyphase-resampling-by-flacs" title="Permanent link">¶</a></h4>
<p>Re-enabling one disabled feature wasn't enough, so <strong><a href="https://github.com/tilka">flacs</a></strong> moved onto another target: Polyphase Resampling. Polyphase Resampling is an efficient resampling algorithm from the early 2000s used to resample audio samples. It's not anything particularly interesting or unique to the GameCube or Wii, but Dolphin didn't bother emulating it when using the DSP-HLE option due to bugs in the HLE implementation. Unlike the Low Pass Filter, this wasn't something that <strong><a href="https://github.com/tilka">flacs</a></strong> could simply enable and have work out of the box. Thankfully, the fix was actually dead simple and amounted to nothing more than a change to a single line.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/polyphasebeforeafter.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/polyphasebeforeafter.png"></a>
<figcaption>One line was breaking everything.</figcaption>
</figure>
</div>
<p>Dolphin was incorrectly handling the maximum/minimum values, truncating them when all it had to do was clamp them. The question then becomes: What exactly does this fix? The one obvious title is <a href="https://wiki.dolphin-emu.org/index.php?title=Snowpack_Park">Snowpack Park</a>, as it was the game that prompted the investigation of Polyphase Resampling. As expected, fixing and re-enabling the feature caused the loud beeps in the game's music to disappear.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/snowpackbroke.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>The loud chirps are immediately noticeable in older builds.</figcaption>
</figure>
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/snowpackfix.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>But they fall into the background after being resampled.</figcaption>
</figure>
</div></div>
<p>Investigating other DSP-HLE issues, testers also found out that Polyphase Resampling was used in music in two <em>somewhat</em> more popular games: <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Colosseum">Pokemon Colosseum</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_XD:_Gale_of_Darkness">Pokemon XD: Gale of Darkness</a>. Users had long been complaining about quavering in the music, but it wasn't nearly as obvious as the defect in <a href="https://wiki.dolphin-emu.org/index.php?title=Snowpack_Park">Snowpack Park</a>. If you want an iconic example of how polyphase resampling affects a game, that is much easier to hear in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Melee">Super Smash Bros. Melee</a>.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/meleenopolyphase.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>This isn't right, but it wasn't widely reported because it doesn't sound too bad.</figcaption>
</figure>
<figure class="col-sm-6">
<audio
controls
src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/meleepolyphase.mp3">
Your browser does not support the
<code>audio</code> element.
</audio>
<figcaption>However, this is how "Super Smash Bros. Melee" should always be announced.</figcaption>
</figure>
</div></div>
<h4 id="50-14764-dsp-hle-add-support-for-dynamic-range-compression-by-flacs"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14764/">5.0-14764 - DSP-HLE - Add Support for Dynamic Range Compression</a></strong> by <strong><a href="https://github.com/tilka">flacs</a></strong><a class="headerlink" href="#50-14764-dsp-hle-add-support-for-dynamic-range-compression-by-flacs" title="Permanent link">¶</a></h4>
<p>With the month winding down into its final days, <strong><a href="https://github.com/tilka">flacs</a></strong> took on another feature missing from DSP-HLE. Dynamic Range Compression is a feature designed to prevent clipping in games if they play a sound too loud. While this worked in DSP-LLE, no one bothered implementing it in DSP-HLE, and it's easy to figure out why. In most games, it's pretty hard to hear much of a differences with the range compressor on or off. How does the compressor work on the GameCube and Wii? What better place to get the information than from the one who wrote support for it!</p>
<blockquote>
<p>The compressor looks at one frame of audio (5 ms on the gamecube, 3 ms on the wii) and if at least one sample would be clipping when converted to the output format, it applies a volume ramp: a short single-frame attack phase, waits for the clipping to end, and then slowly increases the volume again. It might be worth noting that the 0x4e8a8b21 µcode doesn't have a compressor command, so for example melee is literally incapable of triggering the compressor code.</p>
</blockquote>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/compressorgraph.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/compressorgraph.png"></a>
<figcaption>The attack phase is at the start, then the sustain, and then the release follows.</figcaption>
</figure>
</div>
<p>Thankfully, <a href="https://wiki.dolphin-emu.org/index.php?title=Pac-Man_World_Rally">Pac-Man World Rally</a> was known for playing overly loud sound effects and ended up in our sights. It worked as a perfect test case for making sure everything was working.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/withoutcompressor.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/withoutcompressor.png" /></a>
<figcaption>The waveform clearly shows clipping without Dynamic Range Compression.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/withcompressor.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/withcompressor.png" /></a>
<figcaption>With it enabled, the waveform looks much nicer.</figcaption>
</figure>
</div></div>
<p>After implementing it, the game we've seen affected the most is <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Fox:_Assault">Star Fox: Assault</a>, because it will trigger the compressor <em>constantly</em> when enemies are exploding. This was the main difference in audio quality between DSP-HLE and DSP-LLE in the past! Now they sound virtually identical.</p>
<h4 id="50-14511-macos-real-wii-remote-renovations-by-oatmealdome"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14511/">5.0-14511 - macOS: Real Wii Remote Renovations</a></strong> by <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong><a class="headerlink" href="#50-14511-macos-real-wii-remote-renovations-by-oatmealdome" title="Permanent link">¶</a></h4>
<p>With an emulator as big as Dolphin, sometimes features fall into disrepair over time. With Real Wii Remotes on macOS, that definitely seemed to be the case. Doing even basic things like turning on <em>Continuous Scanning</em> or trying to shut down the emulator with a Real Wii Remote connected could cause the emulator to crash. In order to fix these problems, we needed someone familar with the macOS side of things to take a look. Enter <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong>, who has <em>tons</em> of experience working with Apple products and Dolphin.</p>
<p>It may not seem like much, but the attention they gave Real Wii Remotes for macOS fixed the major crashes and made things useable again. This isn't going to put the macOS experience on parity with the other operating systems due to the numerous limitations that Apple inflicts upon us, but it's definitely a step in the right direction, especially for those looking to try out the <a href="https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-apple-dolphin-on-macos-m1/">interesting M1 hardware</a> with Wii games that play best with Wii Remotes!</p>
<h3 id="infrastructure-updates"><strong>Infrastructure Updates!</strong><a class="headerlink" href="#infrastructure-updates" title="Permanent link">¶</a></h3>
<p>In addition to all of the changes to the website, we saw some key changes and updates to Dolphin's infrastructure that should make things a little bit nicer for both us at the blog and those using the emulator. One of the most <em>immediately</em> visible things is that linking to Dolphin's blog will now generate proper previews and make for much more appealing links!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/preview.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-july/preview.png"></a>
<figcaption>Yes, even developers use dark mode.</figcaption>
</figure>
</div>
<p>On the more useful side of things, <strong><a href="https://github.com/OatmealDome">OatmealDome</a></strong> has helped out with making the macOS auto updater a little less tempermental. There have been several phases to this, so you may need to manually update to get out of broken builds. <em>Hopefully</em>, the macOS updater should be working for the forseeable future and it shouldn't be necessary to manually update again once you have.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-06-06&to=2021-08-01&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-13344/">5.0-14344</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-14790/">5.0-14790</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin MEGA Progress Report: April and May 2021
2021-06-06T06:05:58+00:002021-07-31T03:27:24.891270+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2021/06/06/dolphin-progress-report-april-and-may-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/progressreportheader-may2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/progressreportheader-may2021mini.jpg" />
</header>
<p>After finishing up the <a href="https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-apple-dolphin-on-macos-m1/">macOS M1 article</a> the blog staff took a little break. Then they saw the date.</p>
<div class="media-block narrower">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/ohshi-.jpg">
<figcaption>Oh shi-</figcaption>
</figure>
</div>
<p>Upon looking at the actual changelog, however, something became readily apparent: this wasn't going to be just a Progress Report; this was going to be a MEGA Progress Report. The long rumored time era of <em>developers merging everything at once</em> had finally come to pass. We have graphical fixes for <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a>, crash fixes for <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars: Rogue Squadron III</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Xenoblade_Chronicles">Xenoblade Chronicles</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">The Legend of Zelda: Skyward Sword</a> (AArch64), and new features that make playing games more pleasant! And about AArch64, there are a litany of optimizations and fixes that will change things across most of the library.</p>
<p>And we could go on: Bounding Box, Interpreter, GBA to GCN connectivity, GPU Syncing, Mouse Locking, and <em>still more</em>! There's even a lengthy dev diary at the end for good measure explaining how the great mystery of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a>'s was finally solved. The only way to do it justice is to do it right. So buckle up and get ready for the April and May <strong>MEGA</strong> Progress Report.</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-14295-apple-m1-support-for-macos-by-skyler"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14295/">5.0-14295 - Apple M1 Support for MacOS</a></strong> by <strong><a href="https://github.com/skylersaleh">Skyler</a></strong><a class="headerlink" href="#50-14295-apple-m1-support-for-macos-by-skyler" title="Permanent link">¶</a></h4>
<p>This change was big enough for it to get its own article. <a href="https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-apple-dolphin-on-macos-m1/">Check it out if you haven't!</a></p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/blog/2021/05/24/temptation-of-the-apple-dolphin-on-macos-m1/">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/m1headermini-social_thumb.jpg"></a>
</figure>
</div>
<p>Long story short: Dolphin has been ported to run natively on M1 hardware by taking advantage of our AArch64 JIT. The M1 has proven to be a rather powerful device that can outrun like-class x86 devices, and has proven that ARM and x86-64 computers can netplay together in some games! But there was one lingering question from the article: is the M1 that special? Because of Android's (<a href="#50-14007-driverdetails-fix-broken-vector-bitwise-and-on-mali-drivers-by-sspacelynx">well earned</a>) reputation, many of the improvements to Dolphin's AArch64 JIT have flown under the radar. It's hard to see performance improvements vividly on phones and tablets with weak processors, aggressive governors, and obnoxious driver bugs getting in the way. So in order to right that wrong, we've brought in the best Windows on ARM device: The Surface Pro X!</p>
<p><em>Note: We have the Surface Pro X 2019 available for testing. Technically, the Surface Pro X 2020 is the "best" Windows on ARM device, however that machine uses the exact same chip (8cx) just with a slight overclock. In single-core benchmarks it performs roughly 9% faster than the 2019 version, so just add 9% to these results for a rough estimate of how the 2020 model would perform.</em></p>
<p><br/>
<script>
addChart(
{"chart":{"type":"column","polar":false},"title":{"text":"macOS M1 - Rosetta vs Native Support"},"subtitle":{"text":"Computer: MacBook Air M1 (7 core GPU)"},"tooltip":{"headerFormat":"<span style=\"font-size:10px\">{point.key}</span><table>","pointFormat":"<tr><td style=\"color:{series.color};padding:0\">{series.name}: </td><td style=\"padding:0\"><b>{point.y:.1f} vps</b></td></tr>","footerFormat":"</table>","shared":true,"useHTML":true},"plotOptions":{"column":{"pointPadding":0.2,"borderWidth":0},"series":{"animation":false,"dataLabels":{"enabled":true}}},"series":[{"name":"Rosetta","turboThreshold":0,"_colorIndex":0,"marker":{"enabled":false},"colorByPoint":false},{"name":"Native","turboThreshold":0,"_colorIndex":1},{"name":"Intel MacBook Pro 2019, Core i7-8559U @ 4.5ghz","turboThreshold":0,"_colorIndex":2},{"name":"Surface Pro X 2019","turboThreshold":0,"_colorIndex":3}],"data":{"csv":"\"Category\";\"Rosetta\";\"Native\";\"Intel MacBook Pro 2018, Core i7-8559U @ 4.5GHz\";\"Surface Pro X 2019 (D3D12)\"\n\"Super Smash Bros. Melee - FoD\";79;120;71;76\n\"Super Smash Bros. Brawl - New Pork City\";72;111;74;66\n\"Metroid Prime 3 - Elysia (Single Core)\";37;50;25;27\n\"Skyward Sword - Skyloft\";61;80;30;51\n\"Star Wars Rogue Squadron II - Hoth\";49;39;16;19","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"Frames Per Second (VPS)"},"labels":{}},"colors":["#ff3100","#006eff","#808080","#ffe400","#ffe400"],"legend":{"floating":false,"verticalAlign":"top"},"credits":{"enabled":false},"lang":{},"exporting":{},"xAxis":{"title":{},"labels":{}}})
</script>
<br/></p>
<p>So how does it perform? Pretty damn well. The Surface Pro X trades blows with our high end 2018 Intel MacBook Pro, which is something we never expected we'd say of an ARM device just two years ago. However the 8cx in the Surface Pro X just doesn't have the raw power of Apple Silicon, usually getting around half the performance of the M1. Still, If you're looking to run Dolphin on an AArch64 device and prefer Windows, you'll find that the Surface Pro X is a very capable little emulation machine. As a bonus, the Pro X uses D3D12 (though <em>only</em> D3D12) which supports features like geometry shaders that are missing in MoltenVK, meaning that games like <a href="https://wiki.dolphin-emu.org/index.php?title=Mega_Man_Network_Transmission">Mega Man Network Transmission</a> will render correctly.</p>
<p>Either way, it is an exciting time to be in computing and emulation. Thanks to the considerable improvements in recent ARM devices, we're now finally able to see the AArch64 JIT chew through games like we always hoped that it would. And on that note, let's just say that our AArch64 JIT has been getting <em>much</em> better at its job recently.</p>
<h4 id="50-14066-jitarm64-greatly-improve-rounding-and-conversion-accuracy-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14066/">5.0-14066 - JitArm64: Greatly Improve Rounding and Conversion Accuracy</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14066-jitarm64-greatly-improve-rounding-and-conversion-accuracy-by-josjuice" title="Permanent link">¶</a></h4>
<p>Now that we have high-performance AArch64 devices, expectations for our AArch64 JIT have been raised. While users still tend to first prioritize performance, there's been increased pressure on the AArch64 JIT to give the same level of accuracy as desktop builds. To that effort, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has taken up the project of bringing the AArch64 JIT to parity with the x86-64 JIT and this change is a huge step toward closing the gap in compatibility.</p>
<p>You see, the PowerPC CPU in the GameCube and Wii allows software to configure the rounding mode used for floating point calculations, and whether denormals (very very small numbers) should be flushed (rounded to zero) automatically. Our AArch64 JIT just straight up ignored this feature while our x86-64 JIT respected it, so <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> decided to implement it. However, this revealed another issue. Sometimes the JIT needs to be able to roundtrip (reverse) a singles to doubles floating point conversion - a floating point number started in single precision (32-bit), was previously converted to double precision (64-bit), and now needs to be converted back to single precision. Our AArch64 JIT was doing this very simply by just emitting an instruction that converts between the two precision levels. However, now that AArch64 was respecting that games can choose to round very small numbers to zero, this instruction could no longer reverse the precision change of the denormals. That data was now zero.</p>
<p>So <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> borrowed the x86-64 JIT's solution to this problem and had the AArch64 JIT perform the floating point precision conversion manually with a bunch of integer operations. Not only does this fix the problems introduced by respecting a game's rounding mode and denormal settings, it also made our floating point rounding more accurate than it has ever been before on AArch64. Difficult rounding quirks like the <a href="https://dolphin-emu.org/blog/2018/07/06/dolphin-progress-report-june-2018/#50-8009-jit64-fix-and-enable-accurate-double2single-conversion-by-jmc47-degasus-and-phire">slowly rising platforms in Super Mario 64</a> are now working properly in our AArch64 JIT with this change!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mario64platform-low.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mario64platform-low_thumb.jpg"/></a>
<figcaption>Will the platform slowly rise over time as it should?</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mario64platform-high.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mario64platform-high_thumb.jpg"/></a>
<figcaption>It does! This quirk is now properly emulated in AArch64! Painfully observed over the course of five hours on a Pixel 3.</figcaption>
</figure>
</div></div>
<p>As for the initial fix of respecting rounding mode and denormal flushing, it fixes many crashing, hanging, and physics bugs only present in the AArch64 JIT.</p>
<ul>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Unleashed">Sonic Unleashed</a></strong> - Fixes the hang upon loading stage 2.</li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Colors">Sonic Colors</a></strong> - Fixes various out of bounds issues, particularly when using <em>spike</em> form.</li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Skyward_Sword">The Legend of Zelda: Skyward Sword</a></strong> - Fixes a crash after the third Imprisoned fight.</li>
<li><strong><a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand Year Door</a></strong> - Fixes punies disappearing during Chapter 2.</li>
</ul>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SonicColorsSpike.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SonicColorsSpike_thumb.jpg"></a>
<figcaption>This was the last thing users saw... BEFORE THE VOID CLAIMED THEM.</figcaption>
</figure>
</div>
<p>This does come with a small performance penalty, but they were necessary for compatibility purposes. Rather than trying to implement this without a performance hit, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> knew that there was much more performance to be gained elsewhere that wouldn't cost accuracy.</p>
<h4 id="50-14128-jitarm64-implement-fprf-updates-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14128/">5.0-14128 - JitArm64: Implement FPRF Updates</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14128-jitarm64-implement-fprf-updates-by-josjuice" title="Permanent link">¶</a></h4>
<p>Floating Point Result Flag (<code>fprf</code>) is a feature of the GameCube that lets games check a flag to see information on the previous floating point result. With this functionality, a game has access to whether the float was negative, positive, positive infinity, negative infinity, etc. Very few games rely on this behavior, so the feature wasn't actually implemented in the AArch64 JIT. Any title that did use it would have to fall back to interpreter on many floating point instructions for a rather hefty performance penalty.</p>
<p>Implementing this in AArch64 increases expected CPU performance in many Sega developed games, including <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball">Super Monkey Ball</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball_2">Super Monkey Ball 2</a>.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SuperMonkeyBallTouch.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SuperMonkeyBallTouch_thumb.jpg"></a>
<figcaption>Bring a controller, though. Super Monkey Ball 2 on a touchscreen is something we'd wish on no one...</figcaption>
</figure>
</div>
<p>Because of the way <code>fprf</code> works, getting solid performance numbers that look pretty on a graph isn't really all that easy. In <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a>, Android devices were already GPU limited before this optimization and don't gain performance. Even on the M1 the performance difference was only recorded in races where the framerate would vary wildly and randomly with 29 AI cars. However, testers did report that the game had less lag overall throughout a Grand Prix.</p>
<h4 id="50-14233-jitarm64-implement-floating-reciprocal-estimate-single-fres-and-floating-reciprocal-square-root-estimate-frsqrte-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14233/">5.0-14233 - JitArm64 - Implement Floating Reciprocal Estimate Single (fres) and Floating Reciprocal Square Root Estimate (frsqrte)</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14233-jitarm64-implement-floating-reciprocal-estimate-single-fres-and-floating-reciprocal-square-root-estimate-frsqrte-by-josjuice" title="Permanent link">¶</a></h4>
<p>Not content with just making changes that affect a few games, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> decided to implement some of the more difficult instructions in AArch64. Floating Reciprocal Estimate Single (<code>fres</code>) and Floating Reciprocal Square Root Estimate (<code>frsqrte</code>) are common instructions used in popular games and sometimes are relied on for physics calculations. If you used Dolphin a decade ago, you probably ran into bugs in games such as <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a> thanks to our shoddy implementations back then. These instructions are <em>everywhere</em>! In AArch64, rather than creating crude implementations of these instructions, they simply weren't implemented at all and fell back to Interpreter.</p>
<p>Implementing <code>fres</code> and <code>frsqrte</code> improves CPU performance across most games.</p>
<h4 id="50-14239-jitarm64-fix-floating-multiply-fmul-rounding-errors-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14239/">5.0-14239 - JitArm64: Fix Floating Multiply (fmul) Rounding Errors</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14239-jitarm64-fix-floating-multiply-fmul-rounding-errors-by-josjuice" title="Permanent link">¶</a></h4>
<p>Perhaps more excitingly, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> also fixed up another common instruction used in physics called Floating Multiply (<code>fmul</code>). This instruction was implemented <em>inaccurately</em> in the AArch64 JIT, meaning that results weren't quite right. Unfortunately, this instruction is <em>also</em> used in game physics all over the place. A few popular examples we know about are <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart: Double Dash!!</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball">Super Monkey Ball</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball_2">Super Monkey Ball 2</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Donkey_Kong_Country_Returns">Donkey Kong Country Returns</a>.</p>
<p>We know that these games were affected by the rounding differences because they all feature some kind of "input replay" system that allows them to save inputs and replay them back later. Because these replays are saved to a memory card or shipped with the game, we can see the replays on both Dolphin and console! This essentially allows for <em>hardware verification</em> of physics! Beyond just breaking replays, <code>fmul</code> errors could give you headaches when trying to play games too. If you played <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> online via the backup servers, these inaccuracies would result in excessive rubberbanding. It also meant you couldn't race against the Staff Ghosts in any of these games and in some rare cases, would make it so well known console strategies wouldn't work. And we're sure there are many more errors caused by bad <code>fmul</code> emulation in other games that we will never be able to verify because they don't have replays.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/june-2014/AnguishedSourHuia.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/june-2014/AnguishedSourHuia.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Physics errors can cause all kinds of problems in Mario Kart Wii.</figcaption>
</figure>
</div>
<p>And with that, we're finally done with the AArch64 changes...</p>
<h4 id="50-14254-interpreter-fix-floating-convert-to-integer-word-fctiwx-rounding-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14254/">5.0-14254 - Interpreter: Fix Floating Convert to Integer Word (fctiwx) Rounding</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14254-interpreter-fix-floating-convert-to-integer-word-fctiwx-rounding-by-josjuice" title="Permanent link">¶</a></h4>
<p>Or are we?! So technically this is a fix to Dolphin's interpreter... <strong>but</strong> since the AArch64 JIT doesn't implement this instruction, it uses the interpreter fallback for this instruction!</p>
<p>The main reason this went unnoticed is that this is a rather rare instruction. Floating Convert to Integer Word (<code>fctiwx</code>) converts a floating point number to an integer number. This is normally a simple task... except that we have to emulate the behavior of the <strong>PowerPC</strong> version of this instruction. Thankfully, Dolphin already implemented this instruction to an accurate enough degree during the sweeping revolution of x86-64 JIT fixes that brought about the era of replay verification in Dolphin. Everything is fine, right?</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/eEbmrwnYaXs" allowfullscreen></iframe></div>
<figcaption>We were so blissfully unaware of our mistake.</figcaption>
</figure>
</div>
<p>But there was a bit of an oversight in our grand success. While all of the games that we tested were working in the x86-64 JIT, the only game we tested every CPU backend in was <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> due to easy access to ghosts. Remember how we mentioned that <code>fctiwx</code> was rare? Well, <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart_Wii">Mario Kart Wii</a> doesn't use that instruction so it was never tested on the interpreter whatsoever!</p>
<p>Fast forward <em>7</em> years. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> is going through all of the AArch64 JIT deficiencies and trying to get it to parity with the x86-64 JIT. One of the last known issues is that the physics in <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a> do not sync up in certain replays. So we dug up the original replays used in the ancient video for verification. While it still synced up fine on the x86-64 JIT, no matter what <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> did they could not get it to sync up on the AArch64 JIT. Even falling back every single instruction to interpreter wasn't enough.</p>
<p>Upon reviewing the old testing data, testers realized that they never actually tested <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a>'s replays in the interpreter. In order to make things right that once went wrong, the test was at long last run under the interpreter.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/interpretedzero.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/interpretedzero_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Oh yeah, that's wrong.</figcaption>
</figure>
</div>
<p>Mystery solved - it wasn't a JIT bug, but an <em>interpreter</em> bug that was hidden by the x86-64 JIT implementation of <code>fctiwx</code>. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> dug into the issue over the course of several days and slowly figured out why it was broken. The x86-64 and PowerPC <em>actually</em> behaved similarly enough with the <code>fctiwx</code> instruction to not need serious adjustments, but the interpreter needed a custom algorithm to try to get an exact replication of what happens regardless of architecture. Unfortunately, the custom code had flaws that caused incorrect rounding that could bleed over into game behavior differences. After numerous failed attempts, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> finally found the flaw and fixed the interpreter implementation. Now you can finally verify your replays on your favorite AArch64 devices or, if you're insane, you can use the pure interpreter and waste half of your day.</p>
<p>As for <code>fctiwx</code> on the AArch64 JIT, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> hasn't implemented this instruction yet as it would be rather complex. The AArch64 architecture has not one but <em>five</em> different versions of <code>fctiwx</code> depending on the rounding mode needed. Our interpreter can handle this instruction on ARM for now.</p>
<h4 id="50-13988-gameini-add-ability-to-disable-icache-per-game-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13988/">5.0-13988 - GameINI: Add Ability to Disable icache Per-Game</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-13988-gameini-add-ability-to-disable-icache-per-game-by-pokechu22" title="Permanent link">¶</a></h4>
<p>Okay, now we're <em>really</em> done talking about the JITs. I promise. This change has <em>almost</em> nothing to do with them other than the fact that Dolphin doesn't target emulating the CPU pipeline perfectly. <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/">We've gone into detail about this in the past</a>, but emulating GameCube/Wii processor cache behaviors is a huge performance problem that we're not sure can be handled fast enough to keep games playable. On top of that, the number of unknowns with it means there would need to be tons of hardware testing and likely refactoring of how Dolphin works. Unless an ingenious solution were devised, it's not likely Dolphin's JITs will ever get more than rudimentary icache emulation at a reasonable speed. There's a reason pure interpreter is so slow, and more accurate icache emulation is part of it.</p>
<p>Our current way of handling the rare cases where icache/dcache matter is by either patching the game, or massaging things into working well enough to avoid user-facing bugs. To help with the cause, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> added support to disable Dolphin's icache emulation on a per-game basis. This isn't really a performance measure as it doesn't affect performance, but it does affect the behavior of several games. Turning off the JIT version of Dolphin's icache emulation fixes hangs in several games.</p>
<ul>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Scooby-Doo!_Mystery_Mayhem">Scooby-Doo! Mystery Mayhem</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Scooby-Doo!_Unmasked">Scooby-Doo! Unmasked</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Ed,_Edd_n_Eddy:_The_Mis-Edventures">Ed, Edd, and Eddy: The MisEdventures</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Indiana_Jones_and_the_Staff_of_Kings">Indiana Jones and the Staff of Kings</a> (in <a href="https://dolphin-emu.org/download/dev/master/5.0-14143/">revision 5.0-14143</a> by <strong><a href="https://github.com/PatrickFerry">PatrickFerry</a></strong>)</li>
</ul>
<p>If you believe you have a game suffering from icache issues, you can disable icache emulation in any title with the new <em>DisableICache</em> option. Simply go into the game properties page, that goes under the [Core] section of a Game INI. However, this disables icache emulation <em>entirely</em>, no interpreter fallback or anything, so any game that requires icache emulation will just fail. For example, the GameCube Main Menu. As such, we've disabled booting the above <em>GameCube</em> titles from the GameCube Main Menu.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/ScoobyINI.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/ScoobyINI.png"></a>
<figcaption>The top box is the default INI showing this game needs this feature and has enabled it. The bottom box would be how you can enable it in games that do not have it enabled by default.</figcaption>
</figure>
</div>
<h4 id="50-14007-driverdetails-fix-broken-vector-bitwise-and-on-mali-drivers-by-sspacelynx"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14007/">5.0-14007 - DriverDetails: Fix broken vector bitwise AND on Mali drivers</a></strong> by <strong><a href="https://github.com/sspacelynx">sspacelynx</a></strong><a class="headerlink" href="#50-14007-driverdetails-fix-broken-vector-bitwise-and-on-mali-drivers-by-sspacelynx" title="Permanent link">¶</a></h4>
<p>The Mali driver is a mystery to mankind. They do things in ways that mere mortals cannot and should not comprehend. Thankfully, newcomer to the Progress Report <strong><a href="https://github.com/sspacelynx">sspacelynx</a></strong> may actually be a lynx from space that is privy to such foreign concepts.</p>
<p>Dropping the grandeur for a moment, the Mali drivers have slowly been improving, but still have a lot of serious problems. Though this doesn't affect Dolphin in <em>most</em> games, probably the most damning thing they've done is implement <code>glCopyImageSubData</code>... <strong>on the CPU.</strong> That should give you an idea of the kinds of challenges that we're up against when trying to get good performance on Android.</p>
<p>Ignoring the many performance challenges, there are also major bugs with Mali's GLSL shader compiler. While we're not quite sure on the details to why and how, it doesn't seem to be able to handle bitwise AND operations between two integer vectors when just one of them is a non-constant. Once <strong><a href="https://github.com/sspacelynx">sspacelynx</a></strong> knew what was wrong, it wasn't all that hard to fix. The commendable part was them doing all the debugging required to actually narrow it down. And for their efforts, they've fixed <em>a ton of graphical errors on Mali.</em></p>
<div class="media-block full-width">
<div class="row">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug1.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug1_thumb.jpg"></a>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug2.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug2_thumb.jpg"></a>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug3.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-bug3_thumb.jpg"></a>
</figure>
</div>
<p style="text-align: center;">This is the kind of stuff Mali users have come to expect.</p>
</div>
<p><br/>
<div class="media-block full-width">
<div class="row">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine1.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine1_thumb.jpg"></a>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine2.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine2_thumb.jpg"></a>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine3.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mali-fine3_thumb.jpg"></a>
</figure>
</div>
<p style="text-align: center;">But this next Play Store update, they're in for a welcome surprise.</p>
</div></p>
<h4 id="50-14203-android-fix-controller-inputs-not-saving-properly-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14203/">5.0-14203 - Android: Fix Controller Inputs Not Saving Properly</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-14203-android-fix-controller-inputs-not-saving-properly-by-josjuice" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:15%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>Dolphin on Android sometimes has to jump through loops in order to work properly. One of the rather problematic things is that configurations are split up in really odd and annoying ways. For the past couple of months, there have been reports that Dolphin wouldn't save controller configurations <em>unless</em> the user added it to the per-game INI. This issue confused and confounded <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> for quite some time until the behavior was finally reproduced by <strong><a href="https://github.com/JMC47">JMC47</a></strong>.</p>
<p>To reproduce the bug, one had to have mapped a controller or another device, and then try to map something else over it. Dolphin would say that it overwrote the settings but in reality it didn't. Because controller settings are stored in two different places on Android, <strong>the GUI settings would show that everything configured fine</strong>. Unfortunately, the actual settings that the emulator reads from wasn't getting updated. A bisect revealed a rather curious cause - Settings.SECTION_INI_ANDROID and Settings.SECTION_BINDINGS both have the value "Android". Because they shared the same value, Dolphin thought that Settings.SECTION_BINDINGS was a part of the <a href="https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/#the-android-user-experience-overhaul">new-to-android</a> <a href="https://dolphin-emu.org/blog/2017/07/01/dolphin-progress-report-june-2017/#50-4171-videoconfig-port-to-layered-configuration-system-by-merrymage">layered config system</a> when it hasn't actually been ported over yet. As such, it was unable to overwrite the old values.</p>
<p><strong><a href="https://github.com/JosJuice">JosJuice</a></strong> quickly fixed the issue, and now users will be able to configure controllers and save their configuration correctly in the latest Play Store release!</p>
<h4 id="50-14201-android-adjust-touchscreen-opacity-by-mayimilae"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14201/">5.0-14201 - Android: Adjust Touchscreen Opacity</a></strong> by <strong><a href="https://github.com/MayImilae">MayImilae</a></strong><a class="headerlink" href="#50-14201-android-adjust-touchscreen-opacity-by-mayimilae" title="Permanent link">¶</a></h4>
<p>If you don't use controllers on Android, you may have noticed that Dolphin's touch controls look a little bit nicer now. <strong><a href="https://github.com/MayImilae">MayImilae</a></strong> noticed that <a href="https://dolphin-emu.org/download/dev/master/5.0-13545">5.0-13545</a> added opacity controls, giving the user more freedom toward configuring the touch interface. However, when she originally designed the onscreen buttons, Dolphin on Android had no feature to actually <em>adjust</em> the opacity. She had to choose a default that would look nice in most cases and made the opacity a sensible 50%. However, <a href="https://dolphin-emu.org/download/dev/master/5.0-13545">5.0-13545</a> <em>also</em> set opacity to 50%, meaning that the base images were at 50% opacity and then Dolphin was making them even more transparent on top of that. This made the buttons harder to see by default.</p>
<p>In order to fix things, <strong><a href="https://github.com/MayImilae">MayImilae</a></strong> went back and optimized the buttons to make them friendlier to opacity changes, with a much higher base opacity. She also adjusted the default opacity to match the how the buttons looked prior to the unintentional regression.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-old.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-old_thumb.jpg"/></a>
<figcaption>After the touchscreen button opacity adjustments were merged, they were rather faint by default.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-new.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-new_thumb.jpg"/></a>
<figcaption>These changes and the new default setting makes them much easier to see.</figcaption>
</figure>
</div></div>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-adjusted.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/onscreenbuttons-adjusted_thumb.jpg"></a>
<figcaption>Now users can fully enjoy the freedom to configure the touchscreen buttons however they like!</figcaption>
</figure>
</div>
<h4 id="50-14019-fifo-runsync-with-the-gpu-on-command-processor-register-access-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14019/">5.0-14019 - Fifo: Run/Sync with the GPU on Command Processor Register Access</a></strong> by <strong><a href="https://github.com/Stenzek">Stenzek</a></strong><a class="headerlink" href="#50-14019-fifo-runsync-with-the-gpu-on-command-processor-register-access-by-stenzek" title="Permanent link">¶</a></h4>
<p>This particular change has been frozen in carbonite for <strong>two years</strong>. Way back then, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> found a way to fix up Dolphin enough to run <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars Rogue Squadron III: Rebel Strike</a> without crashing. Now you may remember that the game was working for the Dolphin 5.0 release, but shortly afterwards Dolphin's GPU timings got slightly better and the game stopped working. <strong><a href="https://github.com/Stenzek">Stenzek</a></strong>'s solution to fix the regression was simple and made sense. Only problem? It required <em>more</em> GPU syncing. He wasn't comfortable merging it because of the potential for performance regressions and sought to find another solution.</p>
<p>He never found one, so the change gathered dust and fell into disrepair as the emulator evolved without it. Yet, for those close to the project, there was a hole in our heart. <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron III</a> hadn't been able to run in development builds since <a href="https://dolphin-emu.org/download/dev/master/5.0-583/">5.0-583</a> and that was just unacceptable.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/RS3.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/RS3.png"></a>
<figcaption>There's always a bigger bug.</figcaption>
</figure>
</div>
<p>While <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> wasn't willing to merge such a risky change, <strong><a href="https://github.com/JMC47">JMC47</a></strong> asked <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> to rebase the change so it could be tested on modern builds. There wasn't much optimism to get it merged, but <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> figured it was harmless and rebased it, not realizing that the shroud of the dark side had fallen.</p>
<p>Unfrozen into the modern era, the pull request was tested by a litany of players looking for performance regressions and accuracy benefits, and they found <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron III</a> to be quite operational when they arrived. Not only did it still make <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rebel Strike</a> run without crashes, it also eliminated random crashes in <a href="https://wiki.dolphin-emu.org/index.php?title=Xenoblade_Chronicles">Xenoblade Chronicles</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Fox_Adventures">Star Fox Adventures</a> during extended play sessions. It even fixed the notoriously crashy targeting computer in <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Star Wars Rogue Squadron II: Rogue Leader</a>. What kind of mystical energy field was behind this change that it could fix so much?</p>
<p>To understand how this makes things more accurate, you also have to understand how Dolphin runs the CPU and GPU in Single Core and SyncGPU modes. Before <a href="https://dolphin-emu.org/download/dev/master/5.0-583/">5.0-583</a>, Dolphin's Single Core mode had an infinitely fast emulated GPU. It would instantly finish all of its tasks. This was nice for keeping things in sync, but caused problems when games would expect things to take time. There are some games that will push out as many frames as the GPU can, so having an infinitely fast GPU in Single Core wasn't workable. That's not saying our GPU timings are good (they're not) but they're better than nothing.</p>
<p>The problem is that <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rebel Strike</a> was working <em>because</em> of this behavior. By not letting the GPU fall behind or take time, we were working around deficiencies in Dolphin's emulation. Once the timings were in place, <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron III</a> no longer ran. Now the GPU took time to run and the timings changed what did what when. This made it possible for Dolphin to give stale information to the emulated CPU because it was reading the registers that the GPU hadn't yet run far enough to update. <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rebel Strike</a> would then think that the GPU had locked up. It would either then try to reset the GPU or just crash with no backup plan. Maclunkey!</p>
<p>To address this, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong>'s change added an extra <em>Sync/Run</em> point when Command Processor registers were accessed. This means that if the CPU goes to access those registers, Dolphin stops the CPU thread and runs the GPU thread until it catches up. Once it has, Dolphin then swaps back over the CPU thread and it reads the now fresh registers and continues onward. But as users know, more syncing is slower than less syncing, hence <strong><a href="https://github.com/Stenzek">Stenzek</a></strong>'s hesitation.</p>
<p>Once this change was in the hands of testers, one of the first things they did was perform performance testing. The early numbers looked extremely discouraging, with a <strong>7%</strong> decrease observed in very basic tests. However, when moving the testing onto real games, the performance differences weren't as bleak. For lightweight areas of games such as the main menu of <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a> the performance hit had already dropped to 2%. Fears were that this performance hit would be global, but further testing revealed a more interesting outcome. Most games weren't actually affected at all, and if they were the performance differences would only be noticed in places like menus where performance was already incredibly high. <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> still wasn't willing to merge the change, but <strong><a href="https://github.com/JMC47">JMC47</a></strong> absolutely was.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/EvilPlan.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/EvilPlan.png"></a>
<figcaption>Stenzek: Merging this? But my lord, is that... legal? <br/>JMC47: I WILL MAKE IT LEGAL.</figcaption>
</figure>
</div>
<p>Before everyone gets their blasters out, there's one major note we left out about this entire change. <strong>It does not affect Dual Core</strong>! We treat Dual Core very differently than Single Core; for Single Core we try to make things as stable as possible. Dual Core on the other hand we <em>try</em> to make work as well as possible without sacrificing performance. As such, this change was not implemented at all in Dual Core due to worries over the potential performance hit. We're also well aware that our Android users would rather kiss a wookie than sacrifice even a minute percentage of performance. Still, we did performance tests on Android using Single Core to see if it made a difference. Turns out the shoddy drivers become the bottleneck <em>far</em> before anything in this change could make a difference.</p>
<p>There were plans to put up a Single Core performance graph in this section, but it honestly would be pointless. Most games would be identical, with the occasional "470 FPS before" vs "465 FPS after" in a homebrew test making the rest of the graph hard to see. So instead, here's a screenshot of <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars: Rogue Squadron III</a> looking badass in the latest development builds.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/roguesquadron3badass.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/roguesquadron3badass.jpg"></a>
<figcaption>Textures that best most PS3 games, on the GameCube? Factor 5 merely needed to invent a form of <em>texture streaming</em> to make it happen.</figcaption>
</figure>
</div>
<p>Despite the risks, the decision ended up being all too easy. Users that use Single Core <em>expect</em> stability. Dual Core, on the other hand, is for performance and works well enough in a majority of the games. The real kicker is that the dreaded performance regressions that caused the two year long delay ended up being basically nothing in real situations. If only we had given ourselves to the Dark Side a little sooner.</p>
<h4 id="50-14092-implement-efb-peeks-for-compressed-z16-formats-by-phire"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14092/">5.0-14092 - Implement EFB Peeks for Compressed z16 Formats</a></strong> by <strong><a href="https://github.com/phire">phire</a></strong><a class="headerlink" href="#50-14092-implement-efb-peeks-for-compressed-z16-formats-by-phire" title="Permanent link">¶</a></h4>
<p>Another mystery from years past finally tackled. Once <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Star Wars Rogue Squadron III: Rebel Strike</a> was working again, <strong><a href="https://github.com/phire">phire</a></strong> decided that they wanted to finally end an annoying bug. The problem was that during the various cinematic cutscenes, Dolphin was unable to emulate the occlusion tests that the game was doing to determine when to stop drawing the glow around engines.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-broken.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-broken_thumb.jpg"/></a>
<figcaption>Dolphin had no idea how to tell if the engines were blocked or visible during cutscenes.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-broken2.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-broken2_thumb.jpg"/></a>
<figcaption>This is especially apparent when the Xwing is fully occluded by the door.</figcaption>
</figure>
</div></div>
<p>The reason was simple, <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">Rogue Squadron III</a> uses the compressed z16 format during cutscenes in order to use the GameCube's 3x multi-sample anti-aliasing. Dolphin doesn't emulate this whatsoever, as it would just make things look worse with Dolphin's already powerful enhancements. However, by not emulating it, it also means that the game wasn't getting the expected values when it was reading the screen. While we still don't emulate 16-bit depth, <strong><a href="https://github.com/phire">phire</a></strong> improved Dolphin so that it would do the proper conversions for EFB peeks in order to fix the engine glow occlusion.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-working.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rebelstrikepeek-working_thumb.jpg"></a>
<figcaption>And now things finally work correctly. We'd show the other image working too but... it's just a door.</figcaption>
</figure>
</div>
<h4 id="50-14068-jit-optimize-block-link-queries-by-using-hash-tables-by-leoetlino"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14068/">5.0-14068 - Jit: Optimize block link queries by using hash tables</a></strong> by <strong><a href="https://github.com/Leoetlino">Leoetlino</a></strong><a class="headerlink" href="#50-14068-jit-optimize-block-link-queries-by-using-hash-tables-by-leoetlino" title="Permanent link">¶</a></h4>
<p>Sometimes just randomly checking out a game can lead to rather amusing realizations. <strong><a href="https://github.com/JMC47">JMC47</a></strong> had accidentally started up <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_X">F-Zero X</a> instead of <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_GX">F-Zero GX</a> while searching for performance regressions in <a href="https://dolphin-emu.org/download/dev/master/5.0-14019/">5.0-14019</a> while it was still just a pull request. Rather than closing the game and opening the correct one, he decided to roll with it. N64 Virtual Console games are interesting workloads for Dolphin and are always worth testing. His day was ruined when a massive <em>seven second freeze</em> halted his testing.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/fzeroxjitdestroy-broken.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/fzeroxjitdestroy-broken_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>The delay was so long, you might think the game had crashed!</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Leoetlino">Leoetlino</a></strong> just happened to be present in the wrong place at the wrong time and was roped into debugging the issue. <strong><a href="https://github.com/JMC47">JMC47</a></strong> was tasked with bisecting the issue while <strong><a href="https://github.com/Leoetlino">Leoetlino</a></strong> put together a flame graph of what functions were being called during the freeze.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/jitbranchingheatmap.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/jitbranchingheatmap.png"></a>
<figcaption>In this CPU time (horizontal axis) graph, we want lots of tall and thin bars. The long horizontal red bar shows that <code>std::Rb_tree_increment</code> was doing something very bad.</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/JMC47">JMC47</a></strong>'s bisect came up strange, with <em>two</em> at fault builds both related to JIT Branching. That, combined with the heatmap made it obvious why Dolphin was freezing. <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_X">F-Zero X</a> was invalidating a ton of code during the transitions. This caused Dolphin to destroy <strong>20,000</strong> blocks at once. This is problematic because these blocks were tracked with <code>std::multimap</code>. For those that don't know, <code>std::multimap</code> is typically implemented with a <a href="https://en.wikipedia.org/wiki/Red%E2%80%93black_tree">red-black tree structure</a>, which means that every time Dolphin had to destroy a block, it would have to traverse the tree, find the block, and destroy it. It would do this over and over again... 20,000 times.</p>
<p>Realizing how ridiculously inefficient this was, <strong><a href="https://github.com/Leoetlino">Leoetlino</a></strong> swapped Dolphin over to use <code>std::unordered_map</code>. Instead of a tree, this was a kind of hash table that didn't require traversing through each value to get to the next one. While it couldn't completely remove the slowdown, it was able to restore Dolphin to pre-regression performance.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/fzeroxjitdestroy-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/fzeroxjitdestroy-working_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>While there is still a delay, it's no where near as bad.</figcaption>
</figure>
</div>
<p>Even outside of <a href="https://wiki.dolphin-emu.org/index.php?title=F-Zero_X">F-Zero X</a> this is a slight CPU performance gain across the board as JIT blocks get destroyed when games invalidate code. This also makes JIT Cache Clears faster in the cases where games <em>still</em> generate so much code that it overflows.</p>
<p><em>Note: For those wondering why we used <code>std::unordered_map/set</code> when much faster hash table implementations are available, we actually tried <a href="https://abseil.io/blog/20180927-swisstables">Swiss tables</a> but the performance improvement still wasn't enough to eliminate the stutters entirely.</em></p>
<h4 id="50-14041-scissor-offset-fix-for-super-mario-galaxy-roar-effects-by-ezio1900"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14041/">5.0-14041 - Scissor Offset Fix for Super Mario Galaxy Roar Effects</a></strong> by <strong><a href="https://github.com/ezio1900">ezio1900</a></strong><a class="headerlink" href="#50-14041-scissor-offset-fix-for-super-mario-galaxy-roar-effects-by-ezio1900" title="Permanent link">¶</a></h4>
<p>The moment this pull request was originally submitted, it drew immediate sighs. <em>Dolphin couldn't be screwing up something that simple, could it...?</em></p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> uses a unique zoom blur effect during roars in specific scenes. It's simply a bit of extra flavor and you probably wouldn't realize something was missing if you never played on console. However, developers were acutely aware of it, and wanted to find a way to emulate this bugbear once and for all.</p>
<p><strong><a href="https://github.com/ezio1900">ezio1900</a></strong> stepped up and dove into the world of <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> with the mission of solving the mysterious missing roar effects. Using the power of RenderDoc, they took a close look at what the game was doing when the distortion effect was supposed to show up.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-renderdoc.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-renderdoc_thumb.jpg"></a>
<figcaption>RenderDoc allows you to record and examine how things render in incredible detail.</figcaption>
</figure>
</div>
<p>It was long thought that the roar had to be quite the convoluted effect. After all, no one else had been able to fix it over many many years of Dolphin development. But the sad truth was that the problem was caused by a stupid assumption in Dolphin that no one noticed. For some reason, Dolphin assumed that <code>ScissorOffset</code> couldn't be negative and even <em>hardcoded</em> <code>ScissorOffset</code> in the Software Renderer! <strong><a href="https://github.com/ezio1900">ezio1900</a></strong>'s debugging in RenderDoc undoubtedly proved <code>ScissorOffset</code> shouldn't be hardcoded and could <em>definitely</em> be negative. By implementing <code>ScissorOffset</code> correctly in both hardware and software backends, the bosses in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a> finally let loose their true ferocity!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-broken_thumb.jpg"/></a>
<figcaption>What a cute piranha plant.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/rawr-working_thumb.jpg"/></a>
<figcaption>Oh no, a scary monster!</figcaption>
</figure>
</div></div>
<h4 id="50-14120-fix-out-of-bounds-texture-coordinate-behavior-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14120/">5.0-14120 - Fix Out of Bounds Texture Coordinate Behavior</a></strong> by <strong><a href="https://github.com/pokechu22">pokechu22</a></strong><a class="headerlink" href="#50-14120-fix-out-of-bounds-texture-coordinate-behavior-by-pokechu22" title="Permanent link">¶</a></h4>
<p>And now we go from the last mainline Mario game on the Wii to the first <em>Mario</em> game on the GameCube. <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a> is a well beloved launch title for the GameCube and helped bring players into the era of <em>Next Generation</em> graphics. It's also home to one of the oldest known graphical bugs in Dolphin: The Portrait Blur Effect.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever2-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever2-broken_thumb.jpg" /></a>
<figcaption>It almost looks as though Mario was sitting behind an open window.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever2-console.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever2-console_thumb.jpg" /></a>
<figcaption>On console, it's much more clear he's behind something.</figcaption>
</figure>
</div></div>
<p>As all mysteries must eventually be solved, <strong><a href="https://github.com/Tilka">flacs</a></strong> dove in to see what was wrong. That part was actually easy - they found out that <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a> was relying on an undefined behavior with <code>setnumtexgens</code> in order to render the effect. <code>setnumtexgens</code> sets the number of texture coordinates, but it's awkward to handle because the number can come up multiple times during the pipeline and can change. This awkwardness is probably the reason why developers didn't realize they were using more texture coordinates than it actually set, which doesn't have any kind of documented behavior. Without hardware testing, <strong><a href="https://github.com/Tilka">flacs</a></strong> was able to get the blur rendering, but wasn't confident that the fix was correct and left it for someone else to pick up later.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/twoyearslater.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/twoyearslater_thumb.jpg"></a>
</figure>
</div>
<p>Fresh off hardware testing several other issues, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> took on the role of actually figuring out what was going on with the painting in <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a>. The base effect is actually a simple blur achieved with indirect textures. This is not unlike how other blurs and offsets are done in games like <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a>. The developers used a 128x128 texture generated from EFB copies that shows Mario, and another 64x64 texture that contains random grayscale noise. They also separated the texture coordinates for both of them and used texture scale to create a blur effect.</p>
<p>One problem: like we said above, developers forgot to set the number of tex gens to two, so only texture coordinate zero is actually valid. That's why the <em>blur</em> was never rendered in Dolphin. More surprisingly, the <em>originally intended</em> effect is never shown on console either! Players have instead been seeing a different kind of blur effect created by this undefined behavior. In all likelihood, this bug went unnoticed by developers because the effect they achieved looked pretty good and they simply didn't realize that anything was wrong. While implementing the undefined behavior in Dolphin, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> <em>also fixed</em> Nintendo's bug so that we could see what could have been.</p>
<div class="media-block full-width">
<div class="row">
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-broken_thumb.jpg"></a>
<figcaption>Dolphin didn't emulate the effect at all, resulting in a clear painting.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-working_thumb.jpg"></a>
<figcaption>Dolphin now emulates the effect correctly.</figcaption>
</figure>
<figure class="col-sm-4">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-bugless.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/luigibestdayever-bugless_thumb.jpg"></a>
<figcaption>Here's how the effect looks with the game bug patched out.</figcaption>
</figure>
</div>
</div>
<p>With that, another mystery meets its timely end.</p>
<p><strong>Bonus Undefined Behavior</strong></p>
<p>Okay, so hardware testing is supposed to make things <em>more</em> accurate without the risk for regressions. But at this point, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> might actually be cursed. Every time they <a href="https://gist.github.com/Pokechu22/f617a6b9486f0b53cc9343b926999a33">hardware verify a behavior</a> they seem to just discover more problems. This one was simple, right? There was <em>no</em> way it could happen again.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/viewtifulblur.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/viewtifulblur_thumb.jpg"></a>
<figcaption>Whelp.</figcaption>
</figure>
</div>
<p>Right after the fix for <a href="https://wiki.dolphin-emu.org/index.php?title=Luigi%27s_Mansion">Luigi's Mansion</a> was merged, reports came in that blur effects in <a href="https://wiki.dolphin-emu.org/index.php?title=Viewtiful_Joe">Viewtiful Joe</a> were now broken and offset. <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> was pressed back into action and found <em>another</em> undefined behavior used in <a href="https://wiki.dolphin-emu.org/index.php?title=Viewtiful_Joe">Viewtiful Joe</a>. That isn't to say <strong><a href="https://github.com/pokechu22">pokechu22</a></strong>'s hardware testing and implementation of the undefined behavior was incorrect. It just had unintended consequences elsewhere with emulation.</p>
<p>After some investigation, <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> discovered that blur effect is created by rendering an EFB copy, making it transparent, and then drawing it over the screen three times with slightly different offsets. One problem. During the draw, developers turned off the functionality for indirect textures and then proceeded to attempt to use indirect textures. This is rather problematic, as <em>this</em> undefined behavior seems to rely on the order in which pixels are drawn. This is not possible to emulate on Dolphin's hardware backends due to how modern rendering works. Thankfully, the main component of the blur did not use this bug, and <strong><a href="https://github.com/pokechu22">pokechu22</a></strong> was able to restore the behavior to how it was before by using an offset of zero in this case.</p>
<h4 id="50-14122-update-texturecache-logic-for-finding-oversized-xfbs-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14122/">5.0-14122 - Update TextureCache Logic for Finding Oversized XFBs</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-14122-update-texturecache-logic-for-finding-oversized-xfbs-by-iwubcode" title="Permanent link">¶</a></h4>
<p>This is a rather annoying concept to understand but thankfully has a very simple effect for users. <a href="https://dolphin-emu.org/download/dev/master/5.0-10000/">5.0-10000</a> may be an oddly satisfying revision number, but it was also home to a host of regressions. It was causing Dolphin's TextureCache to not recognize identical textures in some cases, making it throw out the "texture" copy and fall back to the RAM copy. This resulted in some pretty awkward issues and made some games unplayable unless you were willing to lock yourself down to <em>Store XFB Copies to Texture and RAM</em> and 1x Native Internal Resolution.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/arcadialambo.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/arcadialambo_thumb.jpg"></a>
<figcaption>Skies of Arcadia the way it was never meant to look...</figcaption>
</figure>
</div>
<p><a href="https://dolphin-emu.org/download/dev/master/5.0-10000/">5.0-10000</a> updated the code so that now the XFB's stride was passed down from VideoInterface (VI). Unfortunately, this added an assumption that XFB copies would be contiguous, which isn't true for oversized XFB copies. Because they don't have a stride that matches block width * bytes per block, they take up multiple rows of memory. This means they can't be hashed in a contiguous chunk. <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> quickly fixed the assumption so that Dolphin could check hashes on non-contiguous XFB copies.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/TurtlesBroken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/TurtlesBroken.png" /></a>
<figcaption>With the bug, you were locked to 1x Internal Resolution or this.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/TurtlesFixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/TurtlesFixed_thumb.jpg" /></a>
<figcaption>Now things are back to normal.</figcaption>
</figure>
</div></div>
<h4 id="50-14257-bounding-box-account-for-pixel-quads-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14257/">5.0-14257 - Bounding Box: Account for Pixel Quads</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14257-bounding-box-account-for-pixel-quads-by-techjar" title="Permanent link">¶</a></h4>
<p>This change can also be called <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14257/">5.0-14257 - Developers Learn Not to F!#* with Bounding Box Part 1</a></strong> with the other parts coming up next. It started out so innocently, with a simple issue report claiming that <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> was crashing randomly during a certain stage. Usually reports like this in less common games are simply a setting issue or <em>Dual Core being Dual Core</em>. So, <strong><a href="https://github.com/JMC47">JMC47</a></strong> leapt into action assuming this would be a fairly conventional bug. While he <em>had</em> <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a>, he hadn't really played it outside of making sure it ran in Dolphin. With his patented setting to fix 99% of the crashes in Dolphin (Dual Core disabled) he ran the game using the savefile the user provided expecting nothing bad to happen.</p>
<p>It crashed.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SpiderManCrash.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SpiderManCrash_thumb.jpg"></a>
<figcaption>This segment of the game loved to freeze or crash the entire emulator.</figcaption>
</figure>
</div>
<p>A game crashing on Single Core is like the <em>Bat Signal</em> to developers that something is actually wrong. But <strong><a href="https://github.com/JMC47">JMC47</a></strong> wasn't convinced that this was a legitimate bug yet. He tried using interpreter, software renderer, and even wondered if the savefile itself had put the game into an illegal state. The only way to confirm that was to transfer the savefile to his console and test it from there. It wouldn't be the first time something like that has happened: <a href="https://wiki.dolphin-emu.org/index.php?title=Tales_of_Symphonia">Tales of Symphonia</a> has a <a href="https://bugs.dolphin-emu.org/issues/9760">game crashing bug with the Pink Pearl Ring Quest</a> if you do things in an order the game doesn't expect.</p>
<p>The results on console weren't quite as interesting. The game didn't crash on repeated playthroughs, even as he tried to replicate the crash conditions perfectly. In fact, without having to deal with the rampant crashing, <strong><a href="https://github.com/JMC47">JMC47</a></strong> started playing deeper into the level, learning the game mechanics, and got up to the mission boss! After confirming the game definitely doesn't crash on console, he returned to Dolphin and tried again there. <strong>The game didn't crash</strong>. He was able to play through the entire level multiple times and die on the boss. He guessed that some setting he had changed must have fixed it and he didn't notice before moving over to test on console. However, even returning everything to their original settings didn't affect the situation.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/OnTheLoose.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/OnTheLoose_thumb.jpg"></a>
<figcaption>Pictured: JMC47 reporting to developers that a wild bug was on the loose.</figcaption>
</figure>
</div>
<p>With no crash, it became harder to figure out what was going on. So, he kept playing the game until he got to the mission boss in Dolphin and even defeated the boss this time around. Thinking that maybe he would never be able to solve this bug, he set down the controller to let the cutscene play out... and the game crashed. Relief and anger hit all at once, but at least there was a guaranteed crash that could be investigated. But what had caused the earlier crashes to disappear?</p>
<p>It turns out it wasn't a setting or anything in Dolphin, it was the player. By getting better at the game, <strong><a href="https://github.com/JMC47">JMC47</a></strong> spent less time in each zone of the city. He had inadverently been playing well enough that the crash didn't have a chance to manifest. By pure happenstance, he left the game running at the start of the mission and it eventually crashed on its own when he turned the camera. Considering <em>that</em> was much easier than playing through the level each time, that became the new test case for the crash. A bisect was in order.</p>
<p>About six hours after the original bug report, he had found a culprit. <a href="https://dolphin-emu.org/download/dev/master/5.0-9892/">5.0-9892</a>, a Bounding Box change. It has been assumed for many years that <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> has been using Bounding Box in order to achieve the stylish multiview comicbook styled cutscenes that it features prominently throughout the game. Bounding Box was forced to <em>On</em> for this title, so <strong><a href="https://github.com/Techjar">Techjar</a></strong> was brought in to look at the issue and reluctantly dug out old hardware tests to check. In a simple test, he found out that Dolphin was off by one when calculating Bounding Box bounds.</p>
<p><br></p>
<pre><code>Console: 240, 293, 134, 165
Dolphin: 241, 293, 135, 164
</code></pre>
<p><br></p>
<p>No one could quite figure out why Dolphin's numbers were incorrect until <strong>Extrems</strong> pointed out that Bounding Box is not calculated by pixels, but <em>pixel quads</em>. Dolphin's numbers were <strong>too precise</strong>. Once <strong><a href="https://github.com/Techjar">Techjar</a></strong> was aware of this quirk, he adjusted Dolphin to take into account pixel quads and the numbers started to behave correctly. From there, all that was left to do was verify things in <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a>.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/AwikRq7qmQs" allowfullscreen></iframe></div>
<figcaption></figcaption>
</figure>
</div>
<h4 id="normally-our-story-would-end-here-but"><em>Normally our story would end here... but...</em><a class="headerlink" href="#normally-our-story-would-end-here-but" title="Permanent link">¶</a></h4>
<h4 id="50-14316-bounding-box-account-for-pixel-quads-better-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14316/">5.0-14316 - Bounding Box: Account for Pixel Quads... Better</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14316-bounding-box-account-for-pixel-quads-better-by-techjar" title="Permanent link">¶</a></h4>
<p>The world of <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> was at peace. But a new horror reemerged from the depths of the <em>fixed bug reports</em> to ravage an innocent user once more. Not even days after the <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> fix was merged, <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a> began having save corruption issues in Chapter 5.</p>
<p>This is a very scary issue and one we had to take seriously. In the traincar, there's a reflection effect that, if emulated incorrectly, can <em>corrupt game data leaving you unable to save properly</em>. The last time we ran into this bug was with <a href="https://dolphin-emu.org/blog/2017/09/02/dolphin-progress-report-july-and-august/#50-5097-remove-fractional-internal-resolutions-by-josjuice">fractional Internal Resolutions</a>. The fact that this bug was so damaging and dangerous led us to eventually remove the feature. We couldn't risk an enhancement causing people to lose their saves.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PaperMarioTraincar.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PaperMarioTraincar_thumb.jpg"></a>
<figcaption>These reflections are pretty cool, but don't you dare emulate them wrong.</figcaption>
</figure>
</div>
<p>This user had their savedata corrupted, but thankfully if you have a hex editor, you can fix the GameID and repair the file. We did that, hoping that it was unrelated to the recent adjustment to Bounding Box. Unfortunately, they went back through the area and it corrupted <em>again.</em> Eventually, a bisect confirmed out fears: <a href="https://dolphin-emu.org/download/dev/master/5.0-14257/">5.0-14257 - Bounding Box: Account for Pixel Quads</a> was at fault. But that was hardware verified to be the correct behavior... what exactly were we doing wrong?</p>
<p>It turns out that it was correct... almost all of the time. The Pixel Quad behavior is true when the game is reading back Bounding Box values, but it isn't <em>correct</em> to round the <em>default values</em>. <strong><a href="https://github.com/Techjar">Techjar</a></strong> was rounding the values directly, meaning that <em>even the default values were getting rounded</em>, which was enough to cause the game to go out of bounds and create a chain reaction that puts the game into a state where it can no longer save properly. In order to fix this, <strong><a href="https://github.com/Techjar">Techjar</a></strong> moved the rounding into the shader code so that only the <em>result</em> is rounded, rather than the actual values. This time around, we carefully tested <em>every trouble spot</em> to make sure there wouldn't be another regression before finally merging it.</p>
<p>At this point, Dolphin's Hardware Bounding Box emulation is tested to work in every retail Bounding Box game and the latest round of fixes should make Dolphin more resistant to small imperfections.</p>
<h4 id="50-14326-bounding-box-add-fallback-for-when-bounding-box-is-unsupported-or-disabled-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14326/">5.0-14326 - Bounding Box: Add Fallback For When Bounding Box is Unsupported or Disabled</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14326-bounding-box-add-fallback-for-when-bounding-box-is-unsupported-or-disabled-by-techjar" title="Permanent link">¶</a></h4>
<p>After investigating <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a>, <strong><a href="https://github.com/Techjar">Techjar</a></strong> discovered that at the start of every draw call, a SDK related function appeared to be writing in default values to the Bounding Box registers. These values made a lot more sense to use than simply zeroing everything out when Bounding Box was disabled, so he hard coded the registers to match these new values. Surprisingly, it made it so that <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> would run without crashing even if Bounding Box wasn't supported or was disabled.</p>
<p>Realizing the value of this, he cleaned up the implementation to use the default values as they were provided instead of hardcoding them. As a side-effect, this allowed testers to run through <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> without Bounding Box to see what kind of visual differences would crop up! Unfortunately, they didn't really find anything. The stylized cutscenes looked the same, all of the major effects looked to be working. The only thing that made them sure that Bounding Box was even being used was that performance was a bit higher when Bounding Box was disabled. Everything pointed to that maybe the game was writing to the Bounding Box registers without actually using them.</p>
<p>Then, <strong><a href="https://github.com/JMC47">JMC47</a></strong> noticed some flickering in the distance as he mashed Bounding Box on and off in the level that was crashing the game.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp-broken.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp-broken_thumb.jpg"/></a>
<figcaption>Without Bounding Box, something clearly seems to be missing...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp-working.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp-working_thumb.jpg"/></a>
<figcaption>It's missing almost the whole footprint!</figcaption>
</figure>
</div></div>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/spiderstomp_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>In motion, we can clearly see it is more than just a texture.</figcaption>
</figure>
</div>
<p>It turns out that the game was using Bounding Box to do some kind of occlusion effect! It paints a 3D decals onto floors or walls, and then uses Bounding Box to <em>remove</em> the original geometry that would be covering it up. With this, they are able to dynamically punch craters into the ground or walls wherever they want! Seeing this cleared up <em>literally all the mysteries</em> about why the game was crashing and lined up with all of the listed test cases on the Dolphin Wiki.</p>
<p>Do note that games that rely on Bounding Box calculations may still hang even with this improved fallback. Also please don't expect this to make <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Paper_Mario_(Series)">Paper Mario</a> games work without Bounding Box; they rely on Bounding Box for game logic so they <em>will</em> hang during certain scenes with it disabled.</p>
<h4 id="50-14311-d3d11opengl-cache-bounding-box-reads-between-registers-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14311/">5.0-14311 - D3D11/OpenGL - Cache Bounding Box Reads Between Registers</a></strong> by <strong><a href="https://github.com/Stenzek">Stenzek</a></strong><a class="headerlink" href="#50-14311-d3d11opengl-cache-bounding-box-reads-between-registers-by-stenzek" title="Permanent link">¶</a></h4>
<p>While making Bounding Box more accurate is nice, what if we could make it <em>much</em> faster. That's what <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> did when he implemented a missing optimization in the OpenGL and D3D11 backends. The way Bounding Box works is that uses its four registers to draw a <em>rectangle</em> over the screen. Previously, Dolphin was reading one, stalling the GPU to sync, reading the next one, stalling the GPU... etc. Having one point of a rectangle isn't very useful, so it's <em>very</em> unlikely a game would read only one value and then immediately use it.</p>
<p>Noticing this long ago, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> added a caching mechanism into the D3D12 and Vulkan backends that makes Dolphin do multiple reads at once as long as the GPU doesn't do any draw calls between them. This way, if the game is reading all four Bounding Box registers without drawing, Dolphin only stalls the GPU once instead of four times. By now implementing this change in OpenGL and D3D11, these backends see up to a <strong>massive 30% performance boost</strong> in Bounding Box limited scenarios.</p>
<script>
addChart(
{"chart":{"type":"column","polar":false},"title":{"text":"Bounding Box Caching Performance Test"},"subtitle":{"text":"On AMD and NVIDIA GPUs"},"tooltip":{"headerFormat":"<span style=\"font-size:10px\">{point.key}</span><table>","pointFormat":"<tr><td style=\"color:{series.color};padding:0\">{series.name}: </td><td style=\"padding:0\"><b>{point.y:.1f} vps</b></td></tr>","footerFormat":"</table>","shared":true,"useHTML":true},"plotOptions":{"column":{"pointPadding":0.2,"borderWidth":0},"series":{"animation":false,"dataLabels":{"enabled":true}}},"series":[{"name":"OpenGL Before","turboThreshold":0,"_colorIndex":0,"marker":{"enabled":false},"colorByPoint":false},{"name":"D3D11 Before","turboThreshold":0,"_colorIndex":1},{"name":"OpenGL After","turboThreshold":0,"_colorIndex":2},{"name":"D3D11 After","turboThreshold":0,"_colorIndex":3}],"data":{"csv":"\"Category\";\"OpenGL No Cache\";\"D3D11 No Cache\";\"OpenGL Caching\";\"D3D11 Caching\"\n\"Paper Mario: The Thousand-Year Door (AMD)\";0;60;0;90\n\"Ultimate Spider-Man (NVIDIA)\";92;90;104;98\n\"Super Paper Mario (NVIDIA)\";72;61;110;104","googleSpreadsheetKey":false,"googleSpreadsheetWorksheet":false},"yAxis":{"title":{"text":"Frames Per Second (VPS)"},"labels":{}},"colors":["#333333","#808080","#006eff","#ff3100"],"legend":{"floating":false,"verticalAlign":"top"},"credits":{"enabled":false},"lang":{},"exporting":{},"xAxis":{"title":{},"labels":{}}})
</script>
<p><br/></p>
<p>Note that <a href="https://wiki.dolphin-emu.org/index.php?title=Ultimate_Spider-Man">Ultimate Spider-Man</a> is also a <em>Full MMU</em> title, so the performance gains are limited by other bottlenecks. These improvements are most noteworthy during <em>Store EFB Copies to Texture and RAM</em> effects in these titles and do not affect other areas as much. This is not really an issue as the effects this change <em>does</em> optimize were among the most demanding moments in the game.</p>
<p>You also might have noticed the missing OpenGL data with AMD graphics cards. Well, that's intentional. <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> investigated a long reported crash with Bounding Box operations on OpenGL with AMD GPUs and determined it was a driver bug and came up with a workaround. Speaking of that...</p>
<h4 id="50-14330-opengl-work-around-windows-amd-driver-bounding-box-issue-by-pokechu22-and-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14330/">5.0-14330 - OpenGL: Work-Around Windows AMD Driver Bounding Box Issue</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> and <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-14330-opengl-work-around-windows-amd-driver-bounding-box-issue-by-pokechu22-and-techjar" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:25%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/radeonlogo.png">
</div>
<p>This has been an annoying thorn in our side for quite some time. AMD's Windows drivers would crash in Bounding Box titles. All the attention on Bounding Box led to some investigation on the issue from <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> and a WIP implementation of a proposed fix from <strong><a href="https://github.com/Techjar">Techjar</a></strong>. That fix was then iterated upon by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> into what became the finalized version of the work-around.</p>
<p>We've actually known about this bug for quite some time. For some unknown reason AMD drivers on Windows only write to the first field of a <a href="https://www.khronos.org/opengl/wiki/Shader_Storage_Buffer_Object">Shader Storage Buffer Object (SSBO)</a> binding in a shader when using <a href="https://www.techopedia.com/definition/3466/atomic-operation">atomics</a>. Our Bounding Box implementation uses four field SSBOs, one for each point of the bounding box rectangle, so this bug made it so only the first Bounding Box coordinate was updated. With three out of four coordinates as garbage, Bounding Box operations would crash.</p>
<p>This was easy enough to hack around, but due to AMD's OpenGL performance being rather slow on Windows, we were reluctant to add a hack just for them. After all, most AMD users would be using D3D11, D3D12, or Vulkan for superior performance, right? Well, it turned out that a lot of AMD users do stick with our default backend, OpenGL, and we've seen a lot of reports about broken Bounding Box. In order to make things simpler for our users and reduce the strain on our support staff, we decided that a small hack would be more than worth the maintenance cost.</p>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> made it so that Dolphin would use an <code>int4</code> instead of an array, which bypasses the issue. Unfortunately, <code>int4</code> with atomics is not supported under Metal/MoltenVK, so both methods have to be maintained. Even if the fix is a little messy, it'd make things easier on support staff and simpler on users instead of having to be told to avoid a backend. With all of this, we could test some of the issues we were having with OpenGL on a non-NVIDIA card.</p>
<h4 id="50-14318-opengl-force-memory-barrier-when-reading-back-bounding-box-values-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14318/">5.0-14318 - OpenGL - Force Memory Barrier When Reading Back Bounding Box Values</a></strong> by <strong><a href="https://github.com/Stenzek">Stenzek</a></strong><a class="headerlink" href="#50-14318-opengl-force-memory-barrier-when-reading-back-bounding-box-values-by-stenzek" title="Permanent link">¶</a></h4>
<p>And now it all comes together with one <em>final</em> Bounding Box change. Remember <a href="#50-14316-bounding-box-account-for-pixel-quads-better-by-techjar">that crash</a> in <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a>? Well, because we weren't able to access that area while testing <a href="#50-14311-d3d11opengl-cache-bounding-box-reads-between-registers-by-stenzek">Bounding Box Caching</a>, we didn't realize that <strong><a href="https://github.com/Stenzek">Stenzek</a></strong>'s optimization <em>broke</em> OpenGL Bounding Box in the <em>room right after the crash</em>.</p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/papermario-broken.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/papermario-broken_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>OpenGL wasn't working quite right.</figcaption>
</figure>
</div>
<p><strong>Except maybe not!</strong> Though it wasn't merged yet, <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> used the workaround above to confirm that Bounding Box on OpenGL was working fine... on AMD. It turns out that <em>only</em> NVIDIA was affected by this regression, which neither <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> nor <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> were using at the time. <strong><a href="https://github.com/Techjar">Techjar</a></strong> started grabbing the Bounding Box values off of his NVIDIA GPU while <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> switched over to test on a NVIDIA graphics card.</p>
<p>After investigating, it turns out that on NVIDIA, the OpenGL code path Dolphin is using to write Bounding Box values to memory buffers is not <a href="https://en.wikipedia.org/wiki/Memory_coherence">coherent</a>. This is an extremely complex topic, but to put simply, coherency means that when two different pieces of hardware read a memory region associated with a bit of data, both devices will read the same value regardless of where the data actually came from. In the case of Bounding Box, the CPU and GPU need to share and edit the Bounding Box values across system memory and vram, and they both need to see the same values for it to work correctly. However, because on NVIDIA Dolphin is writing Bounding Box values in an incoherent manner, the CPU could be using old data. There's our bug. Why didn't these issues appear before the optimization? <span style="white-space: nowrap;">┐(´-`)┌</span> </p>
<p>AMD cards are using a different code path so they aren't affected by this regression.</p>
<p>We could rebuild this OpenGL code path to be coherent, but it would have some potential performance implications. Fortunately, OpenGL already has a solution to this. According to OpenGL spec, a <em>memory barrier</em> can be used to make this codepath coherent. So Stenzek did exactly that. </p>
<div class="media-block narrower">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/papermario-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/papermario-working_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>The memory barrier allowed us to keep the performance boost while fixing the bug.</figcaption>
</figure>
</div>
<p>After tampering with Bounding Box emulation for far too long, <em>everything was finally working again</em> with higher performance and compatibility to boot! Now there won't be any more regressions. <em><a href="https://bugs.dolphin-emu.org/issues/12531">...Ah damn.</a></em></p>
<h4 id="50-14339-bounding-box-please-just-work-now-by-techjar-and-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14339/">5.0-14339 - Bounding Box: Please just work now</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong> and <strong><a href="https://github.com/Stenzek">Stenzek</a></strong><a class="headerlink" href="#50-14339-bounding-box-please-just-work-now-by-techjar-and-stenzek" title="Permanent link">¶</a></h4>
<p>The date is June 5th, 2021. The Progress Report is being buttoned up and readied for launch. Only one problem: <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a> are still both broken despite Bounding Box emulation having become more accurate than ever. In fact, Dolphin's software renderer now works in 100% of Bounding Box games without issues. Yet, D3D11, D3D12, Vulkan, and OpenGL all fail at critical junctures to the point where both games are now unplayable. The culprit? The <strong>hardware verified <a href="#50-14257-bounding-box-account-for-pixel-quads-by-techjar">Pixel Quad behavior</a></strong>.</p>
<p>Both of the broken games had the same symptom. <a href="https://wiki.dolphin-emu.org/index.php?title=Paper_Mario:_The_Thousand-Year_Door">Paper Mario: The Thousand-Year Door</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a> do a special effect at points where they will uncover parts of the screen through Bounding Box tests. The games are <em>very</em> particular about the Bounding Box values when testing this, and getting them wrong can result in the game hanging because it will be waiting for the effect to finish... forever.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pleasework-software.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pleasework-software_thumb.jpg" /></a>
<figcaption>In Software the effect appears and the game can continue.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pleasework-hardware.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pleasework-hardware_thumb.jpg" /></a>
<figcaption>Oh come on.</figcaption>
</figure>
</div></div>
<p>So, what's going on? We were able to narrow down the issue relatively fast since the Software Renderer wasn't affected. Bounding Box Register 1 was rounding differently in some cases.</p>
<p><br/></p>
<pre><code>Software Before: 608
Software After: 607
Hardware Before: 608
Hardware After: 609
</code></pre>
<p><br/></p>
<p>The true value was actually 607.5, but Bounding Box uses integers so it must be rounded to an integer. Originally it rounded to 608, which is technically off by one but it was <em>close enough</em>. But now it is rounding to 609 because of the way Bounding Box is calculated in pixel quads. There's one tiny issue with this: Coordinate 609 is outside of the render area, causing the game to fall into an undefined state and freeze. The real kicker was that the Software Renderer handled things essentially the same, so no one had any clue why there were rounding differences at all. Thankfully, <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> came in with the information we needed to push us in the right direction.</p>
<p><br/>
<blockquote style="max-width: 75%; margin: auto;">When used in a shader, <code>SV_Position</code> describes the pixel location. Available in all shaders to get the pixel center with a 0.5 offset.</blockquote><br/></p>
<p><br/>Essentially, we were rounding the pixel center in a case where the pixel center was already 0.5, throwing off all rounding thereafter. Even though the previous changes <em>increased accuracy</em> in other areas, because of a flaw somewhere else these improvements broke everything. <strong><a href="https://github.com/Techjar">Techjar</a></strong> removed the extra rounding and the games started working <em>again</em>. And now we know to <em>never touch Bounding Box ever aga-</em></p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken_thumb1.jpg"/></a>
<figcaption>Wait what was that. Zoom, enhance!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/mickey-broken_thumb2.jpg"/></a>
<figcaption>@!#?@! </figcaption>
</figure>
</div></div>
<p>Well, we aren't done with Bounding Box quite yet. Thankfully the issue above appears to be limited to Vulkan and OpenGL, and possibly a result of driver bugs. At this point, all of the <em>crashes and hangs</em> that we know of are fixed, including some in <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Magical_Mirror_starring_Mickey_Mouse">Disney's Magical Mirror</a> (pictured above) and <a href="https://wiki.dolphin-emu.org/index.php?title=Disney%27s_Hide_%26_Sneak">Disney's Hide & Sneak</a>. It's the lesser of two evils to deal with some visual bugs while we do more investigation into Bounding Box to try to get things perfect. But that's all the Bounding Box coverage we're going to have in this Progress Report. Seriously, if something else breaks between now and publishing it's going into the next Report.</p>
<h4 id="50-14304-windows-implement-mouse-lock-by-filoppi"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14304/">5.0-14304 - Windows: Implement Mouse Lock</a></strong> by <strong><a href="https://github.com/Filoppi">Filoppi</a></strong><a class="headerlink" href="#50-14304-windows-implement-mouse-lock-by-filoppi" title="Permanent link">¶</a></h4>
<p>Mouse lock has been one of the most requested features for Dolphin. Users often use their mouse in order to control the pointer in Wii games, which means that if you're not running Dolphin in full screen or have multiple monitors, it's very easy for you to lose track of your mouse and click off the window. All the while, the game keeps on playing while you're not in control!</p>
<p><strong><a href="https://github.com/Filoppi">Filoppi</a></strong> has been doing a lot of work to Dolphin's input backend in order to clean things up and bring in new, exciting features. Mouse lock is one of them. The one thing to remember is that this is an implementation for <em>Windows</em>. Because mouse locking has to be extremely precise with its timings as to not let the cursor leak out, each operating system will need its own implementation. For now, the option can <em>only</em> be enabled on the Windows version of Dolphin.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/LockMouse.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/LockMouse_thumb.png"></a>
<figcaption>A long awaited feature finally arrives.</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Filoppi">Filoppi</a></strong> also implemented a dedicated hotkey to unlock the mouse cursor at will, but using window swapping hotkeys like <em>ALT-TAB</em> will work as well.</p>
<h4 id="50-14272-serial-interface-fix-norep-and-comerr-by-endrift-and-bonta"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14272/">5.0-14272 - Serial Interface: Fix NOREP and COMERR</a></strong> by <strong><a href="https://github.com/endrift">endrift</a></strong> and <strong><a href="https://github.com/Bonta0">Bonta</a></strong><a class="headerlink" href="#50-14272-serial-interface-fix-norep-and-comerr-by-endrift-and-bonta" title="Permanent link">¶</a></h4>
<p>Sometimes in the darkest recesses of Dolphin, you find some of the most troubling behaviors. <strong><a href="https://github.com/endrift">endrift</a></strong> was investigating connectivity issues between mGBA and Dolphin, and stumbled upon a rather odd behavior. On console, when there is a timeout over Serial Interface (SI) the SI hardware will send <code>NOREP</code> (no reply) to the SDK's error handler. The SDK error handler will then write <code>NO_RESPONSE</code> into the SI Buffer, which the game will read and then cancel the connection. Dolphin however was bypassing this error handling entirely, so when the SI Hardware was supposed to send <code>NOREP</code>, Dolphin simply wrote <code>NO_RESPONSE</code> into the SI buffer instead. This is fine, as long as the game doesn't pay attention to what's going on. And apparently <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Four_Swords_Adventures">Four Swords+</a> does.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SaveScreen.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/SaveScreen_thumb.jpg"></a>
<figcaption>The game would freeze here, thankfully after saving.</figcaption>
</figure>
</div>
<p>Now Dolphin properly follows all the steps, sending <code>NOREP</code> to the error handler instead of bypassing it. With that, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Four_Swords_Adventures">Four Swords+</a> works correctly.</p>
<p><strong><a href="https://github.com/Bonta0">Bonta</a></strong> further hardware tested another issue with the response <em>communication error</em> (<code>comerr</code>) where Dolphin was also misbehaving. Because both of these changes were touching similar code, they were rolled into one pull request. With both of these issues fixed, <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Four_Swords_Adventures">Four Swords+ Navi Trackers Mode</a> no longer hang in cases where they are trying to reset the GBA emulator.</p>
<h4 id="50-14306-gameini-patch-crystal-chronicles-race-condition-with-gba-by-bonta"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14306/">5.0-14306 - GameINI: Patch Crystal Chronicles Race Condition with GBA</a></strong> by <strong><a href="https://github.com/Bonta0">Bonta</a></strong><a class="headerlink" href="#50-14306-gameini-patch-crystal-chronicles-race-condition-with-gba-by-bonta" title="Permanent link">¶</a></h4>
<p>One of the most annoying parts of playing <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a> is the incessant <em>waiting for connection</em> it does between every single map change. This happened on real hardware as well, but not to the same mindnumbingly long degree. Usually it'd be two - three seconds of waiting on a GameCube, but up to <em>two minutes</em> in Dolphin.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/Waiting.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/Waiting_thumb.png"></a>
<figcaption>This could go on forever...</figcaption>
</figure>
</div>
<p>Dolphin and mGBA both seemed to be doing everything reasonably. So in order to try to solve this issue, <strong><a href="https://github.com/Bonta0">Bonta</a></strong> wrote a litany of hardware tests to try and figure out the exact timing. What they discovered is that the waiting was seemingly random, usually two to three seconds but sometimes up to <em>ten seconds</em> of the game struggling to connect over and over. Things were finally starting to make sense. There wasn't anything wrong with the emulators, but the game itself. </p>
<p>Looking deeper, <strong><a href="https://github.com/Bonta0">Bonta</a></strong> found a rather nasty race condition. During the handshake process while the games connect, <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a> could try to send data to the GBA. That data would be pushed into a queue, and when the connection <em>was</em> established, the transfers wouldn't resume and the game would time out. After ten frames, it would then try the process all over again. It would continue to do this until the timings worked out that it did not send data during the connection process.</p>
<p>This happens on real hardware too, it's just that Dolphin was much more likely to lose the race repeatedly due to timing differences. In order to fix this game bug, <strong><a href="https://github.com/Bonta0">Bonta</a></strong> went to the unprecedented step to patch the <strong>GBA ROM</strong> within <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a> that is sent to the attached GBA. Even funnier? This patch can be used to reduce waiting times on a real console. Because this race condition is extremely annoying and impacts the playability fo the main play mode of the game, it has been enabled by default. Connecting <a href="https://wiki.dolphin-emu.org/index.php?title=Final_Fantasy_Crystal_Chronicles">Final Fantasy Crystal Chronicles</a> to any GBA emulator is now painless.</p>
<p><br/></p>
<h3 id="bonus-development-diary-the-great-mystery-of-pokemon-box"><strong>Bonus Development Diary - The Great Mystery of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a></strong><a class="headerlink" href="#bonus-development-diary-the-great-mystery-of-pokemon-box" title="Permanent link">¶</a></h3>
<h4 id="50-14002-mmu-fix-sdr-updates-being-silently-dropped-in-some-cases-by-leoetlino"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-14002/">5.0-14002 - MMU: Fix SDR Updates Being Silently Dropped in Some Cases</a></strong> by <strong><a href="https://github.com/leoetlino">leoetlino</a></strong><a class="headerlink" href="#50-14002-mmu-fix-sdr-updates-being-silently-dropped-in-some-cases-by-leoetlino" title="Permanent link">¶</a></h4>
<p>With all of the attention toward GBA <-> GCN communication in recent months, users have gone through many older issues to see if they've been fixed. However, one particular issue still remained a mystery. Within <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> is an <em>Adventure Mode</em> that lets you play your copy of Pokemon Ruby and Sapphire on your GameCube <em>without</em> a Game Boy Player. How does it do it? Well, emulation. It's also home to a rather obscure Dolphin bug.</p>
<p>Rather than copying a full GBA game from the Game Boy Advance over the GameCube – Game Boy Advance link cable, which would take several minutes, <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> <em>actually</em> comes preloaded with a GBA emulator and every version of Ruby and Sapphire for a particular region and loads it directly from the disc. When you save in the emulated copy, it updates the savefile on your cartridge. What's special is that this emulator can generate <strong>legitimate</strong> pokemon with certain IV patterns not possible on a real GBA. These Pokemon are valid and can be traded all the way up to Pokemon Sword and Shield, so being able to run Adventure Mode is of real value to Pokemaniacs.</p>
<p>The problem is accessibility. This feature does not work in <a href="https://github.com/FIX94/Nintendont/issues/224">Nintendont</a>, Freeloader, or any other method of making your Wii region free. However, it <em>did</em> work in Dolphin ever since GBA <-> GCN support was added with VBA-M. This comes with a caveat - it only worked for the NTSC version of the game. The PAL and JP versions of the game would crash... if you had <em>Full MMU</em> enabled. More curiously, if you had <em>Full MMU</em> disabled, it would load the GBA emulator with no game. This was notable because <em>it's the same failure state as the backup loaders</em>. While this issue has been known for some time, copies of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> routinely go for over <strong>$1,500</strong> on eBay, so we couldn't look into it due to the extreme cost of getting multiple versions of this exceedingly rare game. But thankfully, an enthusiast with both the PAL and JP versions of the game showed up to provide testing and debug data.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxNTSC.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxNTSC_thumb.jpg" /></a>
<figcaption>The NTSC version of the game works fine...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxJP.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxJP_thumb.jpg" /></a>
<figcaption>However, JP and PAL crash or load no GBA ROM depending on your MMU setting.</figcaption>
</figure>
</div></div>
<p>On top of the cooperation from <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> enthusiasts, this wouldn't have been possible without efforts from <strong><a href="https://github.com/endrift">endrift</a></strong> and <strong><a href="https://github.com/Bonta0">Bonta</a></strong> for fixing up GBA <-> GCN to the point where we could consistently debug the issue. After years of waiting, work could finally begin.</p>
<p>Over the course of several days, developers broke down exactly what the game was doing by comparing the various versions. Our initial thought was that it had to do with shoddy GBA <-> GCN connectivity, but the connection procedure worked fine on all versions of the game!</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxStorageMode.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxStorageMode_thumb.jpg"></a>
<figcaption>Connecting GBAs for trading worked, leaving adventure mode as the only broken feature.</figcaption>
</figure>
</div>
<p>With at <em>least</em> part of the game working, we thought that maybe this was something simple. That thought quickly went out the window when we checked what <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> JP was doing. The internal GBA emulator was <strong>attempting</strong> to load a GBA rom from <code>0x90000000</code>. Now, that may sound wrong to you if you've been around this blog before. The GameCube's base memory is usually mapped at <code>0x80000000</code>, and there is 24MB of memory. This means a game typically will have access to <code>0x8000000</code> to <code>0x81FFFFFF</code>. How exactly would it find anything in <code>0x90000000</code>? Well, on the JP and PAL versions of the game, it wasn't. So, we checked on the NTSC version of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> and...</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxMemoryNTSC.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxMemoryNTSC.png" /></a>
<figcaption>The ROM is there on the NTSC version of the game!</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxMemoryJP.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonBoxMemoryJP.png" /></a>
<figcaption>However, JP and PAL have nothing.</figcaption>
</figure>
</div></div>
<p>The first shoe had dropped. All three versions of the game were doing the exact same thing. The only difference was that it actually worked in the NTSC version. We wondered if they had maybe fixed a bug between releases, but that didn't exactly seem feasible since PAL was released last and NTSC was the middle release. What could be going wrong?</p>
<p>Looking into the process of how the game was mapping the ROM to <code>0x90000000</code> was the key. What we observed on the NTSC version of the game was that it would load the ROM into main memory while <strong>faking</strong> the connection animation with the GBA. Then, after the correct ROM is loaded, it would create a page table that mapped 8 or 16MB of memory at <code>0x90000000</code> to the beginning of the ROM depending on the version of the game. Once this is done, the game will say it successfully connected to the GBA and it's ready to go. If everything worked as expected, their GBA emulator will initialize and load the ROM from <code>0x90000000</code>. However, on the JP and PAL versions of the game, it never mapped the memory! We thought that maybe the fact that the JP GBA roms were 8MB was a potential reason for the difference in behavior, but it turned out the ROMs on the PAL version were 16MB, just like the NTSC version. Dolphin seemingly forgetting to map a page table seemed impossible, but that was the reality we were facing with no explanation why.</p>
<p><strong><a href="https://github.com/booto">booto</a></strong> and <strong><a href="https://github.com//leoetlino">leoetlino</a></strong> came together in order to finally break this issue open. <strong><a href="https://github.com/booto">booto</a></strong> is one of the foremost experts on the GameCube <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/">Memory Management Unit</a> and was a part of Dolphin's original implementation of the MMU. <strong><a href="https://github.com//leoetlino">leoetlino</a></strong> is an expert with IOS and <a href="https://restoration.zora.re/">reverse engineering games</a>, and was brought in originally because we didn't know why Wii backup loaders couldn't boot the game. He quickly re-discovered the <code>0x90000000</code> behavior and theorized that backup loaders were likely broken because they were running the game in Wii mode with MEM2 mapped at the same address, but continued analyzing the game regardless.</p>
<p>Eventually he found the code that mapped the <code>0x90000000</code> region in the NTSC and JP versions of the game. The initialization code was almost exactly the same in both versions of the game, so it seemed likely to be an issue with Dolphin's MMU emulation. With <strong><a href="https://github.com/booto">booto</a></strong> helping to explain some of the more treacherous parts of the MMU, they eventually stumbled upon a rather foreboding line in the <em>PowerPC Microprocessor Family: The Programming Environments</em> manual (also known as 6xx_pem.pdf).</p>
<p><br/>
<blockquote style="max-width: 75%; margin: auto;">The HTABORG field must have the same number of lower-order bits equal to 0 as the HTABMASK field has lower-order bits equal to 1.</blockquote><br/></p>
<p><br/>To understand what this means, what you need to know is that page tables are configured with a 32-bit register called <code>SDR1</code> (Storage Description Register 1) which contains two fields: <code>HTABORG</code> (Real address of Page Table Origin) and <code>HTABMASK</code> (Encoded size of Page Table). The former is the upper 16 bits of the base address of the page table and the latter determines the table size. The reason for this <em>requirement</em> is that it's simply more efficient based on how the actual hardware works.</p>
<p>On the JP version of <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> the page table is found at <code>0xbf0000</code> and the mask is set to <code>0x1</code>. Since <code>HTABMASK</code> has exactly one trailing one and <code>HTABORG</code> = <code>0xbf</code> = <code>0b10111111</code> has no trailing zeros, there's a mismatch. The game was creating a misaligned page table... and Dolphin was ignoring it entirely.</p>
<div class="media-block">
<figure>
<pre class="text-left"><code><b>if (htaborg & htabmask)</b>
<b> return;</b>
PowerPC::ppcState.pagetable_base = htaborg << 16;
PowerPC::ppcState.pagetable_hashmask = ((htabmask << 10) | 0x3ff);
</code></pre>
<figcaption>Dolphin dropped invalid <code>SDR1</code> updates silently.</figcaption>
</figure>
</div>
<p>According to the manual, Dolphin was following the rules correctly. The game was clearly violating the alignment requirement. But <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> worked on console, so does that mean the manual was incorrect?</p>
<p>Looking at the actual processor diagram itself told us that what the game was doing <em>would</em> actually work despite the "you <em>must</em> do this" wording. Because real hardware calculates page table entry addresses by doing a bitwise <code>OR</code> rather than an addition, the second half of the page table is aliased to the first half and things would still work even though half of the table is essentially wasted.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pagetables.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/pagetables.png"></a>
<figcaption>A diagram in 6xx_pem.pdf showing how Page Table Entries (PTE) addresses are generated.</figcaption>
</figure>
</div>
<p>This also matched what we were seeing in the game's very own page table initialization code, which also performs an <code>OR</code>:</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PTEaddressdiagram.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PTEaddressdiagram.png"></a>
<figcaption>The PTE being generated in code.</figcaption>
</figure>
</div>
<p>However, Dolphin was throwing out the whole thing, meaning the ROM was never mapped and the emulator couldn't load it. We removed the excessively strict check to match what was actually happening on console and...</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonLoaded.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-may/PokemonLoaded_thumb.jpg"></a>
<figcaption>It works!</figcaption>
</figure>
</div>
<p>"<em>But wait, couldn't the hardware be masking <code>HTABORG</code> to fix the alignment?</em>" That is actually a very reasonable question considering this is how some <a href="https://dolphin-emu.org/blog/2017/10/02/dolphin-progress-report-september-2017/#50-5395-and-50-5578-dsp-accelerator-fixes-by-leoetlino">DSP</a> and VI registers behave.</p>
<p>In this case, however, we are certain that there is no implicit masking. If <code>HTABORG</code> were masked, then the JP version would be trying to write page table entries not to <code>0xbf0000</code>, but to <code>0xbe0000</code>. That would cause the <code>0x10000</code> byte region preceding the page table buffer to be completely clobbered. Theoretically, the game could have just managed to survive a buffer overflow; that wouldn't be the first time <a href="https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/#50-13242-final-fantasy-crystal-chronicles-mogmail-crash-fix-by-smurf3tte">a game corrupted its own memory and still ran properly on console by a stroke of luck</a>.</p>
<p>In practice, when we changed Dolphin to mask <code>HTABORG</code>, <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a> instantly crashed because some important file structures had been overwritten. Since the game works on console, we know that real hardware cannot possibly be masking the <code>HTABORG</code> value.</p>
<p>That left one last mystery: why was the NTSC version of the game working? The same faulty code existed there, too! Well, everything just so happened to line up correctly. The page table buffer is heap allocated and it happens to be located at <code>0xbc0000</code> on the US version. While <code>HTABMASK</code> is always set to 1 in all versions of the game, <code>HTABORG</code> is equal to <code>0xbc</code> (an even number) in the US build so the alignment check would pass and the ROM would be mapped correctly.</p>
<p>With everything finally understood about <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Box:_Ruby_%26_Sapphire">Pokemon Box</a>, the fix was merged and now all three versions of the game work in <em>Adventure Mode</em>.</p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-04-01&to=2021-06-05&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-13965/">5.0-13956</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-14344/">5.0-14344</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: February and March 2021
2021-04-05T08:59:51+00:002021-04-05T10:34:22.692008+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2021/04/05/dolphin-progress-report-february-and-march-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/progressreportheader-Mar2021.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/progressreportheader-Mar2021mini.jpg" />
</header>
<p>Sometimes the introductions to the Progress Reports are the hardest part to write. The Dolphin Blog has been running for many years, and we've gone through hundreds of changes that affect thousands of titles. We've gone into detail on all kinds of games, from top sellers on the consoles to obscure titles that most of us wouldn't have known existed if not for some random bug report. Despite all of these exciting changes, despite seemingly seeing it all over the years, we still see things that amaze us. The GameCube and Wii library still have a few tricks up their sleeves and developers continue to come up with crazy new optimizations and features that keep pushing Dolphin forward.</p>
<p>It's hard to express how happy we are to not only be writing these articles, but still have interesting things to write about. In fact, we were working on a feature article spotlighting some new features, but things were unfortunately delayed. As such, this month's Progress Report is a little hurried. What exactly got delayed? Well, we'll have more on that later this month. For now... please enjoy this slightly belated Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes"><strong>Notable Changes</strong><a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-13288-make-free-look-a-proper-controller-move-to-separate-ui-and-50-13958-expand-free-look-input-bindings-support-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13288/">5.0-13288 - Make Free Look a Proper Controller, Move to Separate UI</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13958/">5.0-13958 - Expand Free Look Input Bindings Support</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-13288-make-free-look-a-proper-controller-move-to-separate-ui-and-50-13958-expand-free-look-input-bindings-support-by-iwubcode" title="Permanent link">¶</a></h4>
<p><strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has continued their ongoing mission to expand the capabilities of Free Look. This Report we have two changes that combine to allow unprecedented flexibility with how users manipulate the Free Look camera! First up is <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13288/">5.0-13288</a></strong>. This change centralizes the Free Look options and provides a dedicated device for controlling Free Look. This makes it easier than ever to configure and utilize Free Look in whatever way you wish.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome1_thumb.png"/></a>
<figcaption>Free Look has moved! Now it is in a dedicated spot in the menu bar.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome2.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome2_thumb.png"/></a>
<figcaption>Here you'll find all the Free Look settings.</figcaption>
</figure>
</div></div>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome3.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-newhome3_thumb.png"></a>
<figcaption>Now you can configure a dedicated device for Free Look, and set all of your bindings in one place!</figcaption>
</figure>
</div>
<p>The next change makes things even more interesting. Thanks to previous hotkey improvements, it has been possible to map several of Free Looks buttons to a controller or other device. However, Free Look camera rotation was stubbornly still exclusive to the mouse, with no ability remap it whatsoever. Not anymore! With <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13958/">5.0-13958</a></strong>, all Free Look controls can be configured, including rotation! With this new flexibility, you can control Free Look with any device you want, in any way you want. Want to control Free Look entirely with a controller? You can! Want to control Free Look with a fancy 3D control device? You can do that too! This also opens Free Look to situations where it just was not accessible before, such as laptops without dedicated mouse buttons.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-rotation.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-rotation_thumb.png"></a>
<figcaption>Now everything can be mapped!</figcaption>
</figure>
</div>
<p>Thanks to the <a href="https://dolphin-emu.org/blog/2019/11/07/dolphin-progress-report-october-2019/#50-11083-support-for-motion-controllers-like-the-dualshock-4-by-rlnilsen">Motion Input system</a>, you can even control the Free Look camera with your controller's gyros if you want! It is not practical and kind of awkward to use, but still, <em>you can</em>. </p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/gyroadventures.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/gyroadventures_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Controlling Free Look with a gyro is definitely impractical, but it's definitely fun.</figcaption>
</figure>
</div>
<p>If you want to use a gyro to control the camera, we recommend configuring it so a button needs to be pressed for the gyro to be active. You can just borrow the syntax from the default mouse and keyboard controls to make it easy. <a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/freelook-gyroconfig.png">Here is an example config from our testing.</a></p>
<h4 id="50-13618-working-gameids-for-elfdol-files-by-cbartondock"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13618/">5.0-13618 - Working GameIDs for elf/dol files</a></strong> by <strong><a href="https://github.com/cbartondock">cbartondock</a></strong><a class="headerlink" href="#50-13618-working-gameids-for-elfdol-files-by-cbartondock" title="Permanent link">¶</a></h4>
<p>In order to access Dolphin's per-game configuration settings, a title needs to have a GameID. Thankfully, <em>most</em> released games on the Nintendo GameCube and Wii have a unique GameID. There are some rather annoying exceptions, but these cases don't come into play for typical users.</p>
<p>However, simple executable files designed for the console (.elf and .dol) don't have such infrastructure. Almost all homebrew and mods are these executable files, so it has been difficult for them to get the settings they need in Dolphin. This made things harder on both users and homebrew/mod developers who want to support Dolphin.</p>
<p>In order to make things easier, <strong><a href="https://github.com/cbartondock">cbartondock</a></strong> has added an automated way to generate IDs for homebrew based on the name of the executable. For instance, if you want to have custom settings for "tetrisNtsc.dol" you can just right click it in the gamelist and go to the editor tab and add settings. This way you can use non-default settings that might be advantageous to the homebrew without having to adjust your global settings every time you run it.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/HomebrewID.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/HomebrewID.png"></a>
<figcaption>Manage your homebrew's settings directly in the GUI.</figcaption>
</figure>
</div>
<p>Note that this does not work for titles that need to be booted by "The Homebrew Channel" as homebrew booted by the homebrew channel will inherit the Homebrew Channel's GameID. This is only for homebrew booted directly from Dolphin.</p>
<h4 id="50-13673-50-13687-and-50-13936-ios-file-system-and-launch-timing-enhancements-by-leoetlino"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13673/">5.0-13673</a></strong>, <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13687/">5.0-13687</a></strong>, and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13936/">5.0-13936</a></strong> - <strong>IOS File System and Launch Timing Enhancements</strong> by <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong><a class="headerlink" href="#50-13673-50-13687-and-50-13936-ios-file-system-and-launch-timing-enhancements-by-leoetlino" title="Permanent link">¶</a></h4>
<p>This batch of changes makes things slower. Now wait! Before you take up pitchforks, we must note that this doesn't affect <em>raw performance</em>. Rather, these changes deal with NAND and launch timings, particularly for Wii titles. The problem that actually spurred these changes is rather interesting. Namely the <a href="https://bugs.dolphin-emu.org/issues/11346">"You will need the Classic Controller"</a> text in <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">The Legend of Zelda: Ocarina of Time (VC)</a> faded out far too fast. This made it so Dolphin could not be used for randomizer races, since it saved roughly ten seconds on every single reset.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/OoTFast.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/OoTFast_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Resetting was lightning fast in old builds of Dolphin.</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/OoTWorking.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/OoTWorking_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Spoiler: This isn't console but instead the latest builds. Read on to find out how it was fixed.</figcaption>
</figure>
</div>
<p>What could be causing this, we wondered? Could it be more CPU timing issues, like the crashes that once plagued Virtual Console titles in Dolphin? Could it be a bug in Dolphin's CPU emulation causing a timer not to work? After several years of the issue remaining on the backburner, we got the lead we needed from <strong>flagrama</strong>. They were poking at the issue separate from us and noted that cIOSes that modified older IOSes <strong>actually caused the text to fade out faster</strong>. We spent some time looking at the issue and eventually <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong> found the problem: we were simply loading the game too fast from the NAND. But Dolphin has File System timings, right? Yes, except the timings weren't implemented for when a game accessed the NAND through Eticket-Service (ES). But simply fixing that wasn't enough, Dolphin also only had a <em>single</em> timing model, when in reality <strong>flagrama</strong>'s testing made it obvious that Nintendo optimized things in later IOSes!</p>
<p>In order to implement the correct timings for <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">The Legend of Zelda: Ocarina of Time (VC)</a>, we needed to make sure that each IOS had the correct timing model applied for it. In order to do this, <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong> wrote a suite of tests for timing different NAND reads from different IOSes. Using these models, he implemented proper file system timings for older IOS versions into Dolphin. As well, because Dolphin was <em>still</em> slightly faster when booting, he also implemented boot timings from ES_Launch. With all of these together, <strong>flagrama</strong> confirmed that Dolphin's reset timings now matched that of a real Wii!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/IOSTime.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/IOSTime.png"></a>
<figcaption>It turns out that Nintendo optimized NAND read speeds in later IOSes.</figcaption>
</figure>
</div>
<p>So, if you've noticed that your favorite N64 Virtual Console game loads slower now in Dolphin, you know to blame the Ocarina of Time Randomizer community and <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong>. However, all of this work <em>actually</em> resulted in a huge mystery being solved! An obscure WiiWare title called <a href="https://wiki.dolphin-emu.org/index.php?title=Around_the_World">Around the World</a> was <a href="https://bugs.dolphin-emu.org/issues/12145">hopelessly broken with absolutely no leads whatsoever.</a> After this was merged, we were shocked when someone unexpectedly reported that the game was working. We were even more surprised to see that <em>these</em> changes were the result of the game's behavior changing. Because of the nature of the glitches, no one would have guessed that <em>loadtimes</em> were the cause of <strong>this:</strong></p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AtWBroken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AtWBroken_thumb.jpg"/></a>
<figcaption>The splash screen for the game appears incorrectly in older builds.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AtWFixed.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AtWFixed_thumb.jpg"/></a>
<figcaption>With emulated ES file timings, the game behaves correctly for some reason.</figcaption>
</figure>
</div></div>
<p>Now that NAND timings are here, WiiWare and Virtual Console titles <em>might</em> load a little bit more slowly, but the benefits far outweigh the downsides. Dolphin now perfectly matches console timings in key situations, bringing greater accuracy on anything that relies on file system timings.</p>
<h4 id="50-13717-software-renderer-implement-line-widthpoint-size-by-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13717/">5.0-13717 - Software Renderer - Implement Line-Width/Point-Size</a></strong> by <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-13717-software-renderer-implement-line-widthpoint-size-by-pokechu22" title="Permanent link">¶</a></h4>
<p>While Dolphin's Software Renderer may not get the use of its other renderers, it is still used as an important reference for what things <em>should</em> look like; at least when it works. In this case, the software renderer is <em>borrowing</em> from the hardware backends as it was a bit left behind when Dolphin's hardware backends got proper Line-Width and Point-Size emulation. This fixes a few issues in the software renderer, including one that may be a bit surprising to most users!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/vcsoftware-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/vcsoftware-broken.png" /></a>
<figcaption>A long time ago, this was actually the most accurate rendering Dolphin had of NES VC games.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/vcsoftware-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/vcsoftware-working.png" /></a>
<figcaption>But now Software Renderer must settle for just standing alongside its Hardware brethren.</figcaption>
</figure>
</div></div>
<p>There are also multiple graphical issues fixed throughout a variety of titles that use Line-Width/Point-Size, including but not limited to <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Star Wars Rogue Squadron II</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">III</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Mega_Man_Network_Transmission">Mega Man Network Transmission</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Melee">Super Smash Bros. Melee</a>.</p>
<h4 id="50-13944-add-gpu-syncing-options-to-android-gui-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13944/">5.0-13944 - Add GPU Syncing Options to Android GUI</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-13944-add-gpu-syncing-options-to-android-gui-by-josjuice" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:15%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>Android devices are at the edge of being useable for a lot of games. We've seen it again and again, with users hacking up builds, enabling unsafe settings, and doing <em>everything</em> they can to get that extra ounce of performance in order to get their favorite game to be playable. <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has been working on the AArch64 JIT for several months, fixing games and adding several optimizations. However, these optimizations are small and and don't make a huge difference all at once. In their search for performance, we've noticed users going to third party builds and even closed source builds violating Dolphin's GPLv2+ License. In many cases, these builds promised huge performance gains and tons of optimizations without really explaining how or why. After doing some investigation, we found one thing in particular across almost all of these builds right in the configuration file - they disabled all of Dolphin's GPU syncing features.</p>
<p>This isn't some massive change to the codebase or anything special, this is just a debug feature that was in the configuration files for debugging issues with Sync on Idle Skipping. We've known that custom builds were using this setting and some users were even digging through the configuration files in official builds to turn it on there for quite some time. We were hoping that we could avoid this setting being used widespread, but that point has long passed. In order to make things easier on our users, we've decided to add the setting directly in the GUI to make it easily accessible.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AndroidSyncing.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/AndroidSyncing_thumb.png"></a>
<figcaption>GPU Syncing Options can be found in the advanced menu.</figcaption>
</figure>
</div>
<p>This wasn't exactly what we had hoped would happen. The reason why is that Syncing on Idle Skipping is an incredibly important behavior that allows Dolphin to maintain high performance in Dualcore while maintaining some semblance of stability. Even with this syncing, games can still crash and lagspikes can cause problems. This is why many users with powerful computers will enable SyncGPU, a more stringent Dualcore syncing mode, or simply turn on Single Core mode to make things more stable.</p>
<p>Without syncing, you can get all kinds of crazy behaviors that will vary depending on the power of your hardware and the game that's being played. This also can result in behaviors beneficial to someone just looking to play the game at all costs. Less syncing <em>is</em> more performance, and the fact that the GPU and CPU threads run separately mean that a game could drop to incredibly low framerates while still running "full speed". On the other side of things, some games may instantly hang due to operations happening in the wrong order or at the wrong times.</p>
<p>For example, <a href="https://wiki.dolphin-emu.org/index.php?title=Fire_Emblem:_Path_of_Radiance">Fire Emblem: Path of Radiance</a> is a game where we cannot detect the idle loop and thus Dualcore runs without any syncing. The game is rather stable on desktops despite this because it's fairly lightweight and will usually run full speed on reasonable devices. You could easily play through the whole game without running into any issues at all on a Core i5-3570K with a decent graphics card. Bring it onto an Android device that can't maintain full speed, and the game will do all kinds of weird things that you would have never or very rarely seen on the desktop machine. Transitions can randomly crash, polygons flicker and explode on lag spikes, and the game in general doesn't seem quite <em>right</em>. You can simulate this by running something intensive in the background on a modern computer to cause all kind of crazy behaviors that wouldn't happen normally.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/FEcrashed.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/FEcrashed_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Without syncing, host machine lag can affect the game in fascinating ways.</figcaption>
</figure>
</div>
<p>In the end, it comes down to what you consider playable. If you're willing to live with the potential crashes, less syncing is going to be a performance boost and it can be a significant one in some games. That's why you'll be able to find GPU syncing options in the latest versions of Dolphin.</p>
<p>It defaults to "On Idle Skipping" as it always has, but also has the new options of <em>Never</em> and <em>Always</em>. <em>Never</em> is the situation described above and <em>Always</em> is the SyncGPU option that has been available in desktop builds for years. SyncGPU is a more stringent (and slower) GPU syncing option that can be used to make games that crash in dualcore more stable. If you do enable <em>Never</em> for the performance boost, just be sure to save in game often!</p>
<h4 id="50-13963-add-epsilon-hack-for-depth-clipping-in-sonic-titles-by-blaahaj"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13963/">5.0-13963 - Add Epsilon Hack for Depth Clipping in Sonic Titles</a></strong> by <strong><a href="https://github.com/blaahaj">blaahaj</a></strong><a class="headerlink" href="#50-13963-add-epsilon-hack-for-depth-clipping-in-sonic-titles-by-blaahaj" title="Permanent link">¶</a></h4>
<p>This is <em>another</em> hack added mostly for our Android users. However, <em>this one</em> is very small and easy to manage and brings big benefits in the games it affects. Many of Sega's Sonic titles are very particular about the depth of their in-game GUIs, and if they're even off by the slightest bit, they'll disappear. Dolphin used to struggle with this quite a bit, but it's been mostly put to rest <a href="https://dolphin-emu.org/blog/2015/01/01/dolphin-progress-report-december-2014/#40-4451-add-projection-matrix-epsilon-adjustment-to-emulate-gamecube-clipping-by-kayru">since 2014</a>. Unfortunately, the extensions we use in OpenGL on desktop to make this adjustment work don't exist in GLES or aren't supported by any of the driver manufacturers. While Vulkan on Android <em>does</em> support our current solution, Dolphin's GLES backend is competitive or even faster than Vulkan in many games. For this reason, <strong><a href="https://github.com/blaahaj">blaahaj</a></strong> re-added the epsilon hack to the codepath used by Adreno and Mali GLES drivers to restore the missing GUIs.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/SonicColorsBroken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/SonicColorsBroken_thumb.jpg"/></a>
<figcaption>While this looks pretty, it doesn't actually give the user much direction.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/SonicColorsWorking.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/SonicColorsWorking_thumb.jpg"/></a>
<figcaption>That's because the 2D graphics and interface was completely missing!</figcaption>
</figure>
</div></div>
<p>Unlike the solution used on desktop, this epsilon hack may result in some minor flickering in some situations. The benefits outweigh the issues, as this fixes missing GUIs in <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Adventure_DX:_Director%27s_Cut">Sonic Adventure DX</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Unleashed">Sonic Unleashed</a>, and <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_Colors">Sonic Colors</a>. This also fixes black screen issues in <a href="https://wiki.dolphin-emu.org/index.php?title=Sonic_and_the_Black_Knight">Sonic and the Black Knight</a>.</p>
<h3 id="dev-diary-fifo-analyzer-improvements"><strong>Dev Diary - Fifo Analyzer Improvements</strong><a class="headerlink" href="#dev-diary-fifo-analyzer-improvements" title="Permanent link">¶</a></h3>
<p>After merging the <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> <a href="https://dolphin-emu.org/blog/2020/12/10/dolphin-progress-report-october-2020/#50-13081-fix-super-mario-sunshine-debug-cubes-by-stenzek-and-pokechu22">Debug Cube fix</a> that was hardware verified to be correct, we quickly ran into a slew of regressions in other titles. While most of these early reports pointed to track packs made by fans for Mario Kart Wii, one particular regression occurred directly in a retail title: <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Monkey_Ball">Super Monkey Ball</a>. From there, we started to see missing graphics in other retail games <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_Jam:_Maximum_Destruction">Monster Jam: Maximum Destruction</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Fire_Emblem:_Path_of_Radiance">Fire Emblem: Path of Radiance</a>. Another fix for the debug cubes was <em>definitely</em> broken.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/monkeyballreflection-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/monkeyballreflection-working_thumb.jpg" /></a>
<figcaption>It turns out this reflection shares a lot in common with the Debug Cubes...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/monkeyballreflection-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/monkeyballreflection-broken_thumb.jpg" /></a>
<figcaption>And by making the Debug Cubes invisible, we also made the reflection disappear!</figcaption>
</figure>
</div></div>
<p><strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> dug into the regressions trying to find out what could be causing the differences. Unfortunately, Dolphin wasn't especially up to the task. One of the key features in Dolphin that track down graphical issues is the FIFO Player and Analyzer. It allows developers and users to record GPU commands and play them back while inspecting each of the commands to see exactly how the game is rendering. That isn't to say things are perfect. The FIFO analyzer wasn't documenting commands very well, making it hard for <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong> to see what the games were doing. Rather than poke around in the dark, they started fixing up the FIFO analyzer!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/fifoanalyzerimprovements.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2021-march/fifoanalyzerimprovements.png"></a>
<figcaption>By making tools smarter, it's easier to see how games render.</figcaption>
</figure>
</div>
<p>Even with these improvements to Dolphin's FIFO analyzer, the bug so far remains a mystery and we're left with a couple of options. It would be easy enough to revert the <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> Debug Cube fix. <a href="https://dolphin-emu.org/download/dev/master/4.0-8450/">Again</a>. However, there are <em>less</em> regressions this time around so we are leaving things as they are for now to see if a fix can be found. And, if this becomes some kind of blocking issue down the line, there is a known hack that could be used to force <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> to render correctly without breaking the other games.</p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2021-02-01&to=2021-03-31&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-13605/">5.0-13605</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-13963/">5.0-13963</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: December 2020 and January 2021
2021-02-11T05:02:46+00:002022-09-10T06:47:45.241437+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2021/02/11/dolphin-progress-report-december-2020-and-january-2021/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/progressreportheader-Dec2020.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/progressreportheader-Dec2020mini.jpg" />
</header>
<p>Welcome to the Dolphin Progress Report for December 2020 and January 2021! Things ended up running a little behind for this report due to some technical details that we needed to hammer out for a few of these entries. We on the blog team are familiar with the emulator, however there are a lot of technical details that are simply beyond our expertise. Going from things like the AArch64 JIT to GUI changes to IOS updates to game patches that go into low-level hardware behavior is enough to make anyone's head spin! More often than not, we rely on core developers and the authors of a specific change to help us understand what a pull request does so that we can express its purpose accurately here on the blog. </p>
<p>With Progress Reports coming at a <em>mostly</em> bimonthly schedule at this point, this means that sometimes authors have moved onto different things or aren't available to talk. As a blog about emulation, getting these details correct about the various changes and how the emulator works is one of our highest priorities. So, with that out of the way, we hope you enjoy this <em>belated</em> Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes">Notable Changes<a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-13152-add-fallback-region-option-by-flagrama"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13152/">5.0-13152 - Add Fallback Region Option</a></strong> by <strong><a href="https://github.com/flagrama">flagrama</a></strong><a class="headerlink" href="#50-13152-add-fallback-region-option-by-flagrama" title="Permanent link">¶</a></h4>
<p>Handling game regions is something that users shouldn't have to think about most of the time. After all, games have to report their region to the console, so the task should be simple for the emulator, right? It may come as a surprise that Dolphin has had a lot of complications with properly detecting game regions and even has fallbacks for when it cannot detect a region. For many years, Dolphin used the <a href="https://wiki.dolphin-emu.org/index.php?title=GameIDs">GameID</a> of a title to detect the region. It's actually very simple! Look at <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a>. Dolphin used to detect the NTSC, PAL and NTSC-J by the 4th letter in its GameID: GZL<strong>E</strong>01, GZL<strong>P</strong>01, and GZL<strong>J</strong>01. While this system worked for many years, exceptions started popping up and causing issues. For instance, <a href="https://wiki.dolphin-emu.org/index.php?title=Michael_Jackson:_The_Experience">Michael Jackson: The Experience - Walmart Edition</a> uses an annoying X in the GameID for NTSC and a comparable version uses Y in NTSC-J! As more and more exceptions piled up, we were forced to find a better solution.</p>
<p>Turns out that all disc releases for the GameCube and Wii games have a region code on the disc. Additionally, all Wii titles, including discs, channels, WiiWare, <em>and</em> Virtual Console include a region code in their TMD. By moving to a more accurate system, Dolphin's days of misidentifying regions is a thing of the past. That isn't to say it's <em>impossible</em> for complications to come up.</p>
<p>Some Wii <em>Channels</em>, such as the Mii Channel, <em>don't</em> have a unique region code. That's because certain Wii Channels are actually multi-regional! The same channel is designed to work on any region Wii, which means that it uses a multi-region code. In this case, Dolphin can't rely on a region code. There's also the case of homebrew, which doesn't have a set way of expressing a region. For these cases and any other exceptions, Dolphin had instituted a simple backup. It would just check for what region of the Wii Menu was installed to the currently selected NAND and use that. When there was no Wii Menu installed to the current Wii NAND, it would fallback to PAL for Wii titles and NTSC for GameCube titles. Why? The answer was <a href="https://github.com/dolphin-emu/dolphin/pull/2622/files#diff-6444f2b6020682322bcf590eed60eaf5cd0179c07ab419599e0e208540957596">right in the code</a>!</p>
<pre style="word-break: break-word; margin: 2em 0;"><code>// TODO: Right now GC homebrew boots in NTSC and Wii homebrew in PAL.
// This is intentional so that Wii homebrew can boot in both 50Hz and 60Hz, without forcing all GC homebrew to 50Hz.
// In the future, it probably makes sense to add a Region setting for homebrew somewhere in the emulator config.
</code></pre>
<p>We prominently mentioned the <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">Legend of Zelda: Ocarina of Time</a> randomizers when talking about Dolphin's JIT behaviors and making the games more playable. While their <em>GameID</em> seems to imply it's for NTSC consoles, they actually use the same region free flag that multi-region channels use. This is likely to make things easier when running the WADs on real consoles. This would trigger Dolphin's fallback code, sometimes causing the randomizers to run at the incorrect framerate when no Wii Menu was installed or the PAL Wii Menu was installed with PAL60 disabled.</p>
<p>In order to reduce confusion and have more sane control over cases like these, <strong><a href="https://github.com/flagrama">flagrama</a></strong> has added a region fallback option to the configuration menu. This allows users to customize the region that Dolphin chooses when no region can be detected for a particular game, homebrew, or channel. We've also changed the default from PAL to NTSC in order to simplify things for a majority of our users.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/Fallback-region.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/Fallback-region_thumb.png"></a>
<figcaption>The controls for this feature can be found in Config > General.</figcaption>
</figure>
</div>
<h4 id="50-13386-use-storage-access-framework-scoped-storage-for-the-gamelist-on-android-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13386/">5.0-13386 - Use Storage Access Framework Scoped Storage for the Gamelist on Android</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-13386-use-storage-access-framework-scoped-storage-for-the-gamelist-on-android-by-josjuice" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:15%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>This change brings support for the Storage Access Framework and Scoped Storage to Dolphin's gamelist. The idea behind Storage Access Framework and Scoped Storage is solid - basically, the user has to grant an application access to the user's files. The Storage Access Framework has existed since Android 5, however it's been optional and we've chosen not to use it due to its various shortcomings. Unfortunately, come November, Dolphin will be forced to use the Storage Access Framework and that means that there are going to be some changes.</p>
<p>If things were as they should be, we'd be silently moving over to the Storage Access Framework API and users wouldn't even be reading about this. Unfortunately, it isn't that simple. On top of being hard to implement, especially for a C++ application like Dolphin, the Storage Access Framework API is extremely slow. Its shortcomings <a href="https://www.xda-developers.com/android-q-storage-access-framework-scoped-storage/">aren't just apparent to us, either</a>. Slow performance in file access is extremely frustrating, but that is at least limited to first <em>opening</em> a file. Gamelist loading times have been increased by more than <em>tenfold</em> in our testing, but this does not actually affect emulation performance.</p>
<p>Eventually we will have to bring everything in Dolphin Android over to Storage Access Framework API, and there are situations where its limitations <em>matter</em>. Some features look like they're going to have to be dropped altogether or modified to be a part of Dolphin's core files. This includes things like customizing paths for the Wii NAND. This is unfortunate because many of our users like to take advantage of multiple NANDs due to the Wii's strict space limitations that emulation cannot easily bypass. Currently, we're planning on using a single preset Wii NAND directory to bypass the need for Scoped Storage. While this means no performance issues, it does mean Android users will be locked to using a single Wii NAND. It also will have to use a device's internal storage. No more taking advantage of that pesky external SD card! ...not that many phones come with those today anyway.</p>
<p>For our Android TV users, the news is <a href="https://commonsware.com/blog/2017/12/27/storage-access-framework-missing-action.html"><em>even better</em></a>. While the <em>file</em> picker works on some devices, the <em>folder</em> picker that most apps do not use is completely busted across everything. Dolphin uses the folder picker in order to select game directories. Because it's completely broken, Android TV devices running Android 11 <em>cannot</em> use Dolphin's gamelist functionality whatsoever. For older versions of Android on Android TV devices, Dolphin will continue to use the old version of the folder picker. For devices like the Shield TV that still run a maximum of Android 9, Dolphin's gamelist will continue to work normally unless they update to Android 11. At that point, it would be out of our hands.</p>
<p>Since Dolphin is currently targeting the Android 10 SDK, we have been able to slowly implement support for Storage Access Framework without being forced to use it in problematic areas. That loophole disappears come November 2021, meaning that things will change <strong>for Android 11 users</strong> at that time. However, in order to continue to updating Dolphin on Android, we are forced to conform to the Storage Access Framework API. While these losses are frustrating, we're thankful that the core emulation experience won't need to be compromised. On the bright side, using Storage Access Framework bypasses a bug affecting devices running Android 11 that was causing the gamelist not to work for directories on the SD card.</p>
<p><em>Edit: When this article was originally posted, the only Android 11 devices reporting the SD card issue were Samsung devices. As such, we surmised that the bug was with Samsung devices. As more devices have released or upgraded to Android 11 since then, we now know that it was an issue with Android 11 in general.</em></p>
<h4 id="50-13440-make-wii-save-import-behave-more-like-sd-import-by-admiralcurtiss-and-50-13562-android-add-wii-save-import-functionality-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13440/">5.0-13440 - Make Wii Save Import Behave More like SD Import</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13562/">5.0-13562 - Android: Add Wii Save Import Functionality</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-13440-make-wii-save-import-behave-more-like-sd-import-by-admiralcurtiss-and-50-13562-android-add-wii-save-import-functionality-by-josjuice" title="Permanent link">¶</a></h4>
<p>Dolphin's Wii Save Import feature saw some nice improvements this month. <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> has simplified Dolphin's Wii Save import to work more like it does on the Wii when importing from SD card. This should remove some of the seemingly random failures when importing Wii saves. Do note that before you import a Wii save file, you still must have run the game <em>at least once</em>. This is just due to how the Wii filesystem works.</p>
<p>Adding to these improvements, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has added the ability to import Wii save files into the Android GUI! This means it should pretty easy to transfer Wii saves over to your mobile device to play on the go. Exporting them <em>back</em> to PC is another story, but that'll be added at a later date.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/androidimportwiisave.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/androidimportwiisave_thumb.jpg"></a>
</figure>
</div>
<h4 id="jit-improvements-by-josjuice-sintendo-merrymage-and-smurf3tte"><strong>JIT Improvements</strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong>, <strong><a href="https://github.com/Sintendo">Sintendo</a></strong>, <strong><a href="https://github.com/MerryMage">MerryMage</a></strong>, and <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong><a class="headerlink" href="#jit-improvements-by-josjuice-sintendo-merrymage-and-smurf3tte" title="Permanent link">¶</a></h4>
<p>We've had so many JIT improvements over the past two months that it's actually crazy. While most of them are very small, we feel it's important to highlight everyone's effort and showcase a few fixes that we thought stuck out.</p>
<p><strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has been working feverishly on the AArch64 JIT used on ARM devices, such as most phones and tablets. Most of these changes are incredibly small optimizations and additions that <em>slightly</em> improve performance. There are some bigger fixes on the way still, but a few of them have already managed to land. <a href="https://dolphin-emu.org/download/dev/4705af59c6f2f925b3f8e9fc682a9821a28a2b07/">5.0-13309</a> adds missing support for updating the Performance Monitor to Interpreters and the AArch64 JIT. Though <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> was merely trying to make performance testing easier, it turned out at least one game relies on the cycle count updating. As such, <a href="https://wiki.dolphin-emu.org/index.php?title=Harry_Potter_and_the_Prisoner_of_Azkaban">Harry Potter and the Prisoner of Azkaban</a> now functions across all of Dolphin's CPU backends.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/harrypotter.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/harrypotter_thumb.jpg"></a>
<figcaption>This game pushes the GameCube hard, so make sure your hardware is up to snuff!</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/Sintendo">Sintendo</a></strong> and <strong><a href="https://github.com/MerryMage">MerryMage</a></strong> have also submitted <strong>multiple</strong> small performance optimizations across both JITs. They may not be much alone, but they add up and give small boosts in various situations.</p>
<p><a href="https://dolphin-emu.org/download/dev/b1fdd14ed1863505061f961a2776be034bce69ca/">5.0-13553</a> by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> found a bug in an optimization for the <code>dcbf</code>/<code>dcbi</code>/<code>dcbst</code> instructions that caused an address mismatch in games that rely on Dolphin's MMU Speedhack or full MMU emulation. This fixes a crash in <a href="https://wiki.dolphin-emu.org/index.php?title=Happy_Feet_(GC)">Happy Feet</a> for Nintendo GameCube. The Wii version doesn't rely on MMU features and thus wasn't affected by the bug.</p>
<h4 id="50-13447-ios-wd-and-ncd-fixes-by-leoetlino"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13447/">5.0-13447 - IOS: WD and NCD Fixes</a></strong> by <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong><a class="headerlink" href="#50-13447-ios-wd-and-ncd-fixes-by-leoetlino" title="Permanent link">¶</a></h4>
<p>Nintendo DS Connectivity is present in several games across the Wii library. Some games let you connect to a particular DS game in order to get bonus features while others simply let you connect the DS as a controller for another player. Regardless of what the DS is used for, Dolphin pretty much had no support nor testing for the IOS modules that handles broadcasting and connecting to the Nintendo DS.</p>
<p>Enter Ubisoft and the Wii version of <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a>. Despite sharing the name of the 360, PS3, and PC counterparts, the Wii version is its own unique game especially crafted for Nintendo's console! This prequel to the original Playstation games features motion controlled vehicle combat and a draw distance that would make the original games blush. For all of its flaws, the game itself isn't really bad; it's a cute little throwback side game in the series with a neat comic book art style. But for emulator developers there's a huge red flag. Remember how we said it was a Ubisoft game? Much like how seeing <em>Factor 5</em> at startup means that the game is going to push the hardware as hard as possible, Ubisoft developed games have their own reputation. Namely, their games usually do <em>something</em> that causes them to be a pain in the ass to emulate. <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> is no exception to this rule.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/driver.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/driver_thumb.jpg"></a>
<figcaption>Driver: San Francisco is so foggy it may be mistaken for an N64 game.</figcaption>
</figure>
</div>
<p>This game has been troublesome in Dolphin for quite some time. <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> is another Ubisoft game with MetaFortress anti-piracy. It seems like they actually learned from the days of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Smurfs:_Dance_Party">The Smurfs: Dance Party</a> as it no longer proudly proclaims "<a href="https://tcrf.net/File:SmurfsDanceParty-Metaforceresponse.png">MetaFortress RESPONSE!</a>" and is sneakier about crashing the game long after it has detected something amiss. Funny enough, <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a>'s MetaFortress proved wholly ineffective against Dolphin as it uses <em>the exact same trigger</em> as <a href="https://wiki.dolphin-emu.org/index.php?title=The_Adventures_of_Tintin:_The_Game">The Adventures of Tintin: The Game</a>.</p>
<p>This version of MetaFortress uses the same tricks as the older versions with some new checks added on top. What actually tipped us off that it was anti-piracy was that <a href="https://wiki.dolphin-emu.org/index.php?title=The_Adventures_of_Tintin:_The_Game">The Adventures of Tintin</a>'s crash matched complaints online about the game crashing <strong>on console</strong>. Putting two and two together, we were able to determine that the cause of the crash was not a specific Dolphin bug but MetaFortress rearing its ugly head once again. As booting the game from the Wii Menu was a work-around, all we had to do was figure out what differences there were between a gamelist boot and a Wii Menu boot. Being that Dolphin had <em>both</em> options at the ready, it was fairly trivial to fix without ever digging into what MetaFortress was doing.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/wN2WdO4c_jM" allowfullscreen></iframe></div>
<figcaption>We unraveled the mysteries of an older version of MetaFortress back in 2017.</figcaption>
</figure>
</div>
<p>With MetaFortress fixed, we had hoped that <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> would start working. However, nothing changed at all and the game remained broken. It turned out that Dolphin was breaking <em>before</em> MetaFortress even had a chance to shut things down. This meant we had to go on <em>yet another</em> wonderful debugging experience featuring a Ubisoft game. Would it join the ranks of <a href="https://dolphin-emu.org/blog/2017/10/02/dolphin-progress-report-september-2017/#50-5395-and-50-5578-dsp-accelerator-fixes-by-leoetlino">Red Steel</a>, <a href="https://dolphin-emu.org/blog/2017/10/02/dolphin-progress-report-september-2017/#50-5395-and-50-5578-dsp-accelerator-fixes-by-leoetlino">Far Cry: Vengeance</a>, <a href="https://dolphin-emu.org/blog/2019/06/02/dolphin-progress-report-may-2019/#50-10270-and-50-10344-ios-hle-fixes-and-passthrough-upgrades-by-leoetlino">Your Shape</a>, <a href="https://dolphin-emu.org/blog/2020/12/10/dolphin-progress-report-october-2020/#50-12952-ios-hle-abort-pending-operations-on-shutdown-by-sepalani">Just Dance</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=The_Smurfs:_Dance_Party">The Smurfs: Dance Party</a>, and many more? Or would it prove to be even more stubborn, like <a href="https://wiki.dolphin-emu.org/index.php?title=Rayman_Arena">Rayman Arena</a> which is a Ubisoft GameCube title that is still broken for unknown reasons?</p>
<p>In a strange way, <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> was a breath of fresh air. It wasn't doing anything particularly wrong at a glance. In fact, it clearly was logging what was going on through the loading process and that it was getting stuck in an obscure IOS module. This was enough of a push to bring in Ubisoft game expert <em>and</em> IOS expert <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong> to look at the issue. What he was discovered was rather interesting. When you start up the main campaign, <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> uses the obscure WD and NCD IOS modules to broadcast a file called "NTRJ41(00)'DRIVER5". We immediately recognized this as a Nintendo DS GameID and these modules are used to broadcast to the Nintendo DS. But there seemed to be almost no mention of DS connectivity in the game or by Ubisoft, so we booted up the Wii to check ourselves.</p>
<div class="media-block full-width">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/DSconnect.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/DSconnect_thumb.jpg"></a>
<figcaption>In this unadvertised multiplayer mode, the DS player can set up roadblocks while the Wii player drives completes missions.</figcaption>
</figure>
</div>
<p>And so the problem revealed itself. Unlike <em>every other game that broadcasts to DS</em>, <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> doesn't ask or advertise the feature. It just starts broadcasting at the start of every mission and even if there's an error, it ignores it and keeps trying to broadcast no matter what. It seems that Ubisoft had cooked up a far more effective anti-emulator trap that MetaFortress could never live up to: their coding standards. For Dolphin, these modules were low priority because there was almost no value to emulating them right now. However, because of how <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> is coded, Dolphin needed at least remedial support of DS broadcasting in order to run the game.</p>
<p>Through some light reverse engineering, <strong><a href="https://github.com/leoetlino">Leoetlino</a></strong> mapped out the behaviors of the NCD and WD IOS modules responsible for DS broadcasting. He also tested DS broadcasting in games like <a href="https://wiki.dolphin-emu.org/index.php?title=Tales_of_Graces">Tales of Graces</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Castlevania_Judgment">Castlevania Judgment</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Battle_Revolution">Pokemon Battle Revolution</a>, and the hidden DS broadcast features in the <a href="https://wiki.dolphin-emu.org/index.php?title=Mii_Channel">Mii Channel</a>!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/miichannelds.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/miichannelds_thumb.jpg"></a>
<figcaption>Later versions of the Mii channel have DS communication support! Hidden behind a <a href="https://wiki.dolphin-emu.org/index.php?title=Mii_Channel#DS_Connection_Support">secret button combination</a>, this allowed sending Miis to a DSi.</figcaption>
</figure>
</div>
<p>After a few weeks of work and testing and tweaking, things began to work. Games were able to attempt to broadcast and shutdown broadcasting without crashing. After all of these years, <a href="https://wiki.dolphin-emu.org/index.php?title=Driver:_San_Francisco">Driver: San Francisco</a> is finally running correctly!</p>
<p>Does this mean that Dolphin supports DS <-> Wii communication? <strong>Absolutely not</strong>. The foundation is now in place and most games no longer crash when starting DS broadcasts. However, Dolphin does not broadcast any Wi-Fi data, and even if it did there's currently no DS emulator that can even listen for it. In order to get complete DS <-> Wii support in these titles, there's still a very long road ahead and a lot more work to be done. Even this remedial state, we're still running into hangs in certain scenarios, particularly in <a href="https://wiki.dolphin-emu.org/index.php?title=Tales_of_Graces">Tales of Graces</a>. If you're familiar with the original version of <a href="https://wiki.dolphin-emu.org/index.php?title=Tales_of_Graces">Tales of Graces</a>, this shouldn't surprise you at all as it was actually <a href="https://www.ign.com/articles/2010/02/23/tales-of-graces-recalled-in-japan">recalled in Japan.</a></p>
<h4 id="50-13215-enable-certain-compatibility-game-patches-by-default-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13215">5.0-13215 - Enable Certain Compatibility Game Patches by Default</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-13215-enable-certain-compatibility-game-patches-by-default-by-josjuice" title="Permanent link">¶</a></h4>
<p>As Dolphin has gotten more mature, we've learned more about our favorite (and not so favorite) games than we ever could have imagined. At this point, we've discovered dozens of games with bugs and behaviors that Dolphin will likely <em>never</em> emulate. These games are saved by various low level hardware quirks, such as CPU cache shenanigans, that would present such a performance penalty to Dolphin that no one would want to use it even if someone went through the trouble of emulating it.</p>
<p>In order to improve the user experience, we have changed our patch structuring to now <em>enable</em> certain game patches by default in cases where there is zero reason why a user would want them disabled. These games include...</p>
<ul>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2004">MVP Baseball 2004</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2005">2005</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Wallace_%26_Gromit_in_Project_Zoo">Wallace and Gromit in Project Zoo</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Casper%27s_Scare_School:_Spooky_Sports_Day">Casper's Scare School: Spooky Sports Day</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Monster_High:_Ghoul_Spirit">Monster High: Ghoul Spirit</a></li>
<li><a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">3</a></li>
</ul>
<p>...Wait... what were those last two? Could that mean...</p>
<h4 id="50-13452-support-conditional-patches-and-add-patches-for-resident-evil-23-audio-bugs-by-smurf3tte"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13452/">5.0-13452 - Support Conditional Patches and Add Patches for Resident Evil 2/3 Audio Bugs</a></strong> by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong><a class="headerlink" href="#50-13452-support-conditional-patches-and-add-patches-for-resident-evil-23-audio-bugs-by-smurf3tte" title="Permanent link">¶</a></h4>
<p>These two games are among the most requested to be fixed in comment sections and on the forums. <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3: Nemesis</a> are no stranger to Dolphin developers. For years now, the music in <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">3</a> has presented quite the mystery. An old hack, now removed, seemed to be the only answer to strange issues causing the intermittent music.</p>
<p><div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<audio controls src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/RE2Broken.mp3">Your browser does not support the <code>audio</code> element.</audio>
<figcaption>There's quite a lot missing from this sequence.</figcaption>
</figure>
<figure class="col-sm-6">
<audio controls src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/RE2Working.mp3">Your browser does not support the <code>audio</code> element.</audio>
<figcaption>Here is how it is supposed to sound.</figcaption>
</figure>
</div></div></p>
<p>The old savior of these games was the Instant ARAM DMA hack, a heuristic that made Direct Memory Access timings to the Audio RAM <strong>instant</strong> and thus completely bypassed Dolphin's emulation of a GameCube's Audio RAM bus throughput. Since our timings were horrific back then, this little trick would fix a lot of games that had timing related trouble in the early years of Dolphin. It was a dirty, dirty hack - instant timings are <em>extremely inaccurate</em> and this feature caused crashes in some games - but Dolphin's timings were so inaccurate back then that, when combined with a heuristic to only turn it on when needed, it helped more than it hurt. </p>
<p>As Dolphin has matured, timings have improved across the board. Invisibly, the ARAM DMA hack was rendered less and less useful, and even began to become harmful due to false detections. Eventually Dolphin reached a point where every game that originally needed it worked without it! Except for <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">3</a>. This put us into an unenviable situation. With decent timing emulation the Instant ARMA DMA hack became a dead weight, with the heuristic erroneously activating and needlessly exposing users to problems. In hopes of solving what was actually wrong with <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">3</a> we removed the hack despite it breaking these two games. We hoped that this would lead to someone solving what was wrong and the games would soon be fixed.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/oneeternitylater.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/oneeternitylater.jpg"></a>
</figure>
</div>
<p>That didn't exactly happen, at least very quickly. Finally, we have a clear picture of what went wrong and why the Instant ARAM DMA hack worked. It turns out the games are erroneously zeroing buffers before the game's audio samples can be fully copied to ARAM. The partial transfer of the audio samples resulted in the characteristic on then off again music that users experienced. This is also why the Instant ARAM DMA hack worked - it made it so that everything was copied before the buffers were cleared. But since this is a game bug, why didn't console run into this problem? For that, we have to look at what happens <em>after</em> it erroneously clears the buffer. The troublesome <code>memset()</code> call that wipes the buffers are followed by a call to <code>DVDRead()</code> which issues instructions to invalidate the data cache (<code>dcbi</code> instructions). This cancels the <code>memset</code> and the buffers never actually get cleared despite the mistake! Because Dolphin lacks data cache emulation, the <code>memset()</code> actually reaches RAM and wipes out the buffers. </p>
<p>To fully emulate this behavior, Dolphin would have to implement data cache emulation. Not only would this be a gargantuan task, it would also slow Dolphin's emulation performance considerably. However, these games aren't our first joust with problems like this. In the past, we've implemented <em>patches</em> to fix game bugs like these and bypass the need for a data cache entirely. In fact, this bug is almost exactly the same as <a href="https://wiki.dolphin-emu.org/index.php?title=Casper%27s_Scare_School:_Spooky_Sports_Day">Casper's Scare School: Spooky Sports Day</a>'s issue <a href="https://dolphin-emu.org/blog/2018/04/02/dolphin-progress-report-february-and-march-2018/#development-diary-the-shovelware-that-buried-dolphin">we patched years ago</a>. Unfortunately, Resident Evil 2 and 3 couldn't be solved so easily. In testing, the method worked - nop'ing out the erroneous <code>memset()</code> does resolve the issue, no data cache emulation required. However, Resident Evil 2 and 3 both use multiple executables, so a patch that worked on one scenario in Resident Evil 2 would cause another to crash! This would force users to constantly juggle between which patch to have enabled and hope that the loader executable itself didn't crash due to the patch! What we needed wasn't just a patch, but a smarter patching system.</p>
<p>Progress Report newcomer <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> went above and beyond to fix this issue and extended Dolphin's game patching system to support conditional patches right in this change! With all of this together, the buffer clearing game bugs in every executable are corrected and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_2">Resident Evil 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Resident_Evil_3:_Nemesis">Resident Evil 3: Nemesis</a>'s audio issues are a thing of the past.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/residentevil2.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/residentevil2_thumb.png"></a>
<figcaption>As someone who is very not ok with horror, this is as far as MayImilae would go for a screenshot.</figcaption>
</figure>
</div>
<h4 id="50-13426-dsp-fix-write-masks-on-audio_42ar_42-mmio-registers-by-smurf3tte"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13426/">5.0-13426 - DSP: Fix write masks on AUDIO_*/AR_* MMIO registers</a></strong> by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong><a class="headerlink" href="#50-13426-dsp-fix-write-masks-on-audio_42ar_42-mmio-registers-by-smurf3tte" title="Permanent link">¶</a></h4>
<p><strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> brings us some audio fixes this time around with a change to audio address masking. When investigating audio clipping issues in <a href="https://wiki.dolphin-emu.org/index.php?title=Nickelodeon_Teenage_Mutant_Ninja_Turtles">Nickelodeon Teenage Mutant Ninja Turtles</a> (not to be confused with <a href="https://wiki.dolphin-emu.org/index.php?title=TMNT_(GC)">TMNT</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=TMNT_(Wii)">TMNT</a> or <a href="https://wiki.dolphin-emu.org/index.php?title=Teenage_Mutant_Ninja_Turtles_(GC)">Teenage Mutant Ninja Turtles</a>), <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> found some new behaviors for masking in various DSP registers.</p>
<p>The game starts an <code>AUDIO_DMA_START_LO</code> with an unaligned address. Because Dolphin was not masking off the low 5 bits as it was supposed to do, all future audio DMAs were misaligned. Further reads are <em>not</em> masked, so the error was not corrected, meaning all future DMAs were then offset. By adding in the correct masking behavior to <code>AUDIO_DMA_START_LO</code>, the issue was quickly resolved, resulting in clearer audio with <em>less</em> clipping. Some of the clipping actually happens on console, which Dolphin faithfully recreates.</p>
<p>As a side note, this also fixes broken audio in another very popular Wii game: <a href="https://wiki.dolphin-emu.org/index.php?title=The_Bachelor">The Bachelor</a>. The audio clipping behavior was nearly identical to <a href="https://wiki.dolphin-emu.org/index.php?title=Nickelodeon_Teenage_Mutant_Ninja_Turtles">Nickelodeon Teenage Mutant Ninja Turtles</a> so it wasn't much of a surprise that this change actually fixed both.</p>
<h4 id="50-13509-fix-wii-remote-disconnect-crash-on-windows-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13509">5.0-13509 - Fix Wii Remote Disconnect Crash on Windows</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-13509-fix-wii-remote-disconnect-crash-on-windows-by-billiard" title="Permanent link">¶</a></h4>
<p>There are tons of benefits to <a href="https://dolphin-emu.org/blog/2020/04/05/dolphin-progress-report-february-2020/#50-11684-add-support-for-wii-remotes-over-inputcommon-by-billiard">connecting real Wii Remotes to Dolphin's InputCommon</a>, such as emulated infrared, customizable inputs and more! Unfortunately, if the Wii Remote turned off while connected to Dolphin, the emulator would crash. This was due to a bit of messiness when connecting things on Windows. <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> went through and cleaned things up so that Wii Remotes can power down and disconnect at any time without causing issues.</p>
<h4 id="50-13240-wii-remote-motion-simulation-allow-360-degree-tilt-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13240">5.0-13240 - Wii Remote Motion Simulation - Allow 360 Degree Tilt</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-13240-wii-remote-motion-simulation-allow-360-degree-tilt-by-billiard" title="Permanent link">¶</a></h4>
<p>Sticking to the topic of Wii Remotes, let's talk a bit about Dolphin's motion simulation. While many of our users have moved onto using Motion Passthrough, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> is still hard at work ironing out some of the issues in Motion Simulation. In the case of <a href="https://wiki.dolphin-emu.org/index.php?title=Another_Code:_R_-_A_Journey_into_Lost_Memories">Another Code R</a>, it was reported that Motion Simulation was unusable for some puzzles due to oversights in how it handles 360 degree tilt motions. The problem was actually very apparent - Dolphin simply wouldn't let the Wii Remote tilt more than 180 degrees. Thus if the player tried to do a tilt that went further than 180 degrees, Dolphin would simply rotate it the other way around to get to the destination angle.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/anothercoder-puzzle.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/anothercoder-puzzle_thumb.jpg"></a>
<figcaption>Turns out that pointing the Wii Remote at the screen and spinning it is a lot harder without a real Wii Remote</figcaption>
</figure>
</div>
<p><strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> corrected the wrapping behavior on tilt simulation in so that the motion will now take the shortest path to the destination angle. This now allows motion simulation tilts to spin a full 360 degrees if necessary.</p>
<h3 id="warning-technical-information-ahead">Warning: Technical Information Ahead.<a class="headerlink" href="#warning-technical-information-ahead" title="Permanent link">¶</a></h3>
<h4 id="50-13242-final-fantasy-crystal-chronicles-mogmail-crash-fix-by-smurf3tte"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13242/">5.0-13242 - Final Fantasy: Crystal Chronicles Mogmail Crash Fix</a></strong> by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong><a class="headerlink" href="#50-13242-final-fantasy-crystal-chronicles-mogmail-crash-fix-by-smurf3tte" title="Permanent link">¶</a></h4>
<p>Yet another game debugged by <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong>. While this one was strongly suspected to be another dcache issue, it actually turned out to be something entirely different. It was a game bug... but one that Dolphin could actually emulate after understanding <em>when</em> the bug was happening. Essentially, after completing the Goblin Wall level, you'd get Moogle Mail and a cutscene. At the end of all of this, Dolphin would freak out with a ton of invalid reads/writes or the game would outright crash if MMU was enabled. This bug has been around for years and has been pretty hard to track down because it seems to appear and disappear with no rhyme or reason.</p>
<p>After years of confusion, everything finally makes sense. Using <em>Store EFB Copies to Texture and RAM</em> fixes this notorious crash. However, wouldn't someone have tried that? The answer is yes! The problem is, that by the time we were changing settings, the bug had already occurred.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/crystalchron-bosscrash.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/crystalchron-bosscrash_thumb.jpg"></a>
<figcaption>This is where everything goes wrong.</figcaption>
</figure>
</div>
<p>To understand this problem, we first need to understand how post-processing works on the GameCube and Wii. While rendering, the GPU rasterizes to the "Embedded Frame Buffer" (EFB), a 2MB chunk of extremely fast working memory that resides in the GPU itself. While some basic post-processing can be applied while the frame is in the EFB, any effect that involves reading then distorting the frame cannot be done while it is in the EFB. So for most post-processing effects, the game will execute an EFB Copy to transfer the frame to main memory, then read the frame as a texture from which to render again with the post effects on top. However, the consoles render in 24-bit RGBA6, but cannot read a texture in that format. To deal with this discrepancy, it is common for games to convert the frame to 32-bit RGBA8 during the EFB Copy to maintain full visual quality. </p>
<p>Crystal Chronicles makes copious use of this method for explosions and other effects. However, the game does something unusual. Crystal Chronicles is pushing memory hard and sometimes they may go a little over. So rather than always reserving space for an RGBA8 frame, the game will dynamically choose which format to do the EFB Copy in depending on how much memory is available. To facilitate this, Crystal Chronicles checks their custom memory allocator to see if there is enough free space in main memory for the larger frame. If the check clears, the game tells the GPU to convert the frame to RGBA8 during the EFB Copy. However if the check fails, the game tells the GPU to convert the frame to the small and lower quality 16-bit RGB565 texture format. With this trick, they can go a little over on their memory usage without worrying about an overrun.</p>
<p>The GameCube was almost always memory starved, so why don't we see lots of games using tricks like this? Because this method carries some risk. The GPU sends the frame into main memory without bounds detection, so if the EFB Copy is larger than the space allotted for it, the copy will just keep going <em>even if it has to overwrite game data</em>. The GameCube and Wii have no way to deal with this so this is <em>literally game over</em>. But it should be fine, right? The whole point of checking the available memory and copying in RGB565 is to prevent this very scenario from ever occurring. There's no way anything could go wrong...</p>
<p>The game relies on a helper function to get the size of the EFB Copy, which it then gives to the memory allocator. Usually this would be done using a helper function provided by Nintendo, however the developer has reimplemented this function on their own for some reason. It does the job very well, except for <em>one</em> texture function in the US release of the Crystal Chronicles. For this texture their helper function is incorrect and feeds the game slightly smaller values than the EFB Copy's actual size. If this happens while the game is strained just enough that the game's memory allocator calculates that there is room for an RGBA8 frame when there is not, we have the perfect recipe for a disaster.</p>
<p>And this occurs at the Goblin Wall, specifically in a post boss cutscene. The memory overrun leads to graphics data overwriting a data structure of the game's memory manager, a data structure the users will access later when the player opens their Moogle Mail in a following cutscene.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/mooglemail.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-december/mooglemail_thumb.jpg"></a>
<figcaption>And here is where the crash occurs.</figcaption>
</figure>
</div>
<p>This is a <em>catastrophic</em> game bug. Yet, why wasn't it crashing on console? <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> immediately assumed the data cache was saving it just like with Resident Evil 2 and 3. However, in hardware testing this proved to not be the case. In fact, the memory is overrun in <em>exactly the same way</em> on console! It turns out that the specific texture data that overwrites that memory manager data structure just so happens to start with 0xFF. The game interprets this as a flag and then ignores all of the other data, bypassing the data corruption entirely. That's how console avoids the crash. Luck, pure dumb luck. Sadly there was no luck left over for Dolphin.</p>
<p><span id="memorymodel"></span>
The GameCube and Wii are unified memory model systems, so the CPU and GPU all share one pool of memory. This allows both the CPU and GPU to edit graphics data with zero performance penalty. Modern PCs on the other hand operate on a split memory model, where the CPU and GPU each have their own pools of memory. To accomodate for this difference, Dolphin has no choice but to have duplicate graphics data in both places and sync any changes across the memory pools. This syncing is by far one of the greatest bottlenecks in Dolphin, so we have developed tons of optimizations and workarounds for this. Our primary approach to this problem is <em>Store EFB Copies to Texture Only</em>. This mode isolates graphics data to the GPU side, preventing the sync from occurring and giving a huge speed up. However, the CPU can decide to tweak graphics data at any point and there has to be <em>something</em> on the CPU side, so in place of the graphics data we write all zeroes. While <em>Store EFB Copies to Texture Only</em> is definitely hacky, it works well enough in most games that it is enabled by default.</p>
<p>This takes us back to Crystal Chronicles. At the Goblin Wall when the bugged texture function is called and the memory overrun occurs, instead of a texture data overwriting the memory manager data structure, it is zeroed out. When Moogle Mail is opened in the following cutscene, the game reads 0x00 and decides to read the remaining zeroes as pointers. These are of course invalid and lead to tons of errors. There's our crash! But it turns out that to resolve this issue, all we have to do is disable <em>Store EFB Copies to Texture Only</em> by default for Crystal Chronicles. The graphics data then overwrites the memory manager data structure and the game reads 0xFF then ignores the rest of the data, just like real hardware! All of this analysis, research, and console testing, and our crash is fixed by changing <em>one word</em> in a GameINI.</p>
<p>Of course we had disabled <em>Store EFB Copies to Texture Only</em> while trying to debug this crash. In fact, it is one of the first things we tried. However, there's a <em>long</em> gap between when the bug is triggered and when it actually manifests. By relying on savestates close to the crash, as we usually do to speed up testing for issues like this, the bug had already occurred and everything we tried was irrelevant. Even though the final solution was a simple one, it took <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> digging deep and truly understanding the problem for the solution to be found.</p>
<p>...</p>
<p>...</p>
<p>Are the casual readers gone? Yea they'd never make it this far into the Report. Good, ok technical detail lovers, let's get into the delicious <em>exceptions</em> you've all been waiting for!</p>
<p>So it turns out that, by default, disabling Store EFB Copies to Texture Only actually <em>doesn't</em> recreate the console behavior! The conclusion ignored a new-ish on-by-default EFB Copies to RAM optimization called <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/#50-8998-add-deferred-efb-copies-mode-by-stenzek">Deferred EFB Copies to RAM</a> where Dolphin delays EFB Copies to the host RAM so it can batch many EFB Copies to RAM together for a sizeable performance boost. However, the optimization has an optimization (oh yes) where it will notice if one EFB Copy is totally overriding another in a batch, and just, doesn't include the first EFB Copy in the batch of EFB Copies going to RAM. This bug just happens to be one of those cases. With Deferred EFB to RAM Copies enabled, the EFB Copy with the buffer overrun never happens on the RAM side, skipping the bug all together! While this is inaccurate, and we could disable deferring by default to allow the overrun to occur exactly as on console... the optimization is a sizeable performance boost, and having tons of error spam is never nice so <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> decided to make a note of it and then leave it be. We couldn't figure out how to explain that exception without ruining our sweet "we tried EFB to RAM!" pay off so we left that out of the conclusion.</p>
<p>But there's more! <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> was not done! They also created a patch to fix the game bug! Specifically, it fixes the bugged texture function's calculation for the memory the EFB Copy will use, which then allows the game to adapt correctly and avoid the overrun. However, there are borderline cases where this can lead to the game running in RGB565 mode where it previously ran in RGBA8 just fine. Since we have the EFB Copies to Texture and RAM solution that performs slightly better, the patch isn't really needed. But since <strong><a href="https://github.com/smurf3tte">smurf3tte</a></strong> already did the work, they included the patch but did not enable it by default.</p>
<p>With that our time is up, and you now know <em>far</em> too much about Final Fantasy: Crystal Chronicles. If you for some reason have any additional questions, you can meet us in the <a href="https://forums.dolphin-emu.org/Thread-dolphin-progress-report?action=lastpost">forum</a> just down the hall.</p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2020-12-01&to=2021-01-31&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-13180/">5.0-13180</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-13603/">5.0-13603</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: October and November 2020
2020-12-09T23:44:20+00:002020-12-10T06:50:02.517144+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2020/12/10/dolphin-progress-report-october-2020/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/progressreportheader-Oct2020.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/progressreportheader-Oct2020mini.jpg" />
</header>
<p>The past two months have been quite busy with a lot of features and fixes spread out between a lot of contributors, new and old. It's only fitting then that we've seen some important fixes for ancient bugs and new ideas bringing in new features. Even if the game you've been playing is already running fine, developers are hard at work coming up with ways to make things even better. Take for instance a new infrastructure that allows Custom Texture Packs to <em>customize</em> what controls show up in games <em>depending on how you've configured your controller in realtime!</em> Also, getting that perfect angle is a bit easier with the new "virtual notches" system, perfect for difficult platforming challenges in games like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a>!</p>
<div class="media-block narrow">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/teaser.jpg">
<figcaption>There's something missing in this picture... or is there?!</figcaption>
</figure>
</div>
<p>Enough teasing, we've made you wait long enough. It's time for the October and November Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes">Notable Changes<a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-12722-externals-update-moltenvk-to-v11-by-stenzek-and-50-12934-re-enable-gpu-texture-decoding-under-moltenvk-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12722/">5.0-12722 - Externals: Update MoltenVK to v1.1</a></strong> by <strong><a href="https://github.com/Stenzek">Stenzek</a></strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12934/">5.0-12934 Re-enable GPU Texture Decoding under MoltenVK</a></strong> by <strong><a href="https://github.com/Techjar">Techjar</a></strong><a class="headerlink" href="#50-12722-externals-update-moltenvk-to-v11-by-stenzek-and-50-12934-re-enable-gpu-texture-decoding-under-moltenvk-by-techjar" title="Permanent link">¶</a></h4>
<p>To start off with something relatively simple, this group of pull requests that are of great benefit to our macOS users. Using Dolphin on macOS can be a bit problematic, thanks to the operating system only giving us access to an ancient version of OpenGL and no native support for Vulkan. While we've been taking advantage of a Vulkan to Metal wrapper, <a href="https://dolphin-emu.org/blog/2018/12/04/dolphin-progress-report-november-2018/#50-9173-vulkan-add-support-on-macos-via-moltenvk-by-stenzek">MoltenVK</a>, things haven't been perfect. Some settings, including <a href="https://dolphin-emu.org/blog/2017/04/05/dolphin-progress-report-march-2017/#50-3220-gpu-texture-decoding-by-stenzek">GPU Texture Decoding</a>, weren't working under MoltenVK and had to be disabled. Also, performance wasn't quite as good as native Vulkan on other operating systems.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2018-november/gputexturedecoding-melee.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2018-november/gputexturedecoding-melee_thumb.jpg"></a>
<figcaption>While this looks really cool, we had to entirely disable GPU Texture Decoding on MoltenVK due to rampant crashing.</figcaption>
</figure>
</div>
<p>We have some good news, MoltenVK has been updated to v1.1! On top of various improvements and apparent performance increases, the issues we had with GPU Texture Decoding are now resolved. With this, we've reenabled GPU Texture Decoding on macOS. This is great news for older macs, as GPU Texture Decoding offloads some work from the CPU onto the GPU and can help systems with weak CPU performance.</p>
<p><strong>Note:</strong> <em>When using GPU Texture Decoding, Arbitrary Mipmap detection does not function, so certain games that use mipmap effects may malfunction.</em></p>
<h4 id="50-12801-dynamic-input-textures-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12801/">5.0-12801 - Dynamic Input Textures</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-12801-dynamic-input-textures-by-iwubcode" title="Permanent link">¶</a></h4>
<p>Custom Textures have proven to be one of Dolphin's most powerful enhancements. Ever since its introduction in 2009, users have been painstakingly going through some of their favorite games and recreating textures at a higher resolution to stunning effect. These packs allow fans to replay their favorite games like never before, with textures that may rival professional remasters! With <a href="https://forums.dolphin-emu.org/Forum-custom-texture-projects">hundreds of packs now available</a>, the popularity of this feature is only surpassed by essentials like higher internal resolution. However, there has always been a pretty big limitation with custom texture loading - it has no idea what controller you are using. Many of our bigger packs include custom textures for different types of controllers so the button prompts the game shows will match what is in your hands, however since Dolphin doesn't understand any of this, it's up to the user to manually pick and install the textures for their controller. This leads to an increase in instruction and installation complexity, increasing the difficulty of the pack for creators and users alike.</p>
<p>Enter <strong><a href="https://github.com/iwubcode">iwubcode</a></strong>'s brainchild: Dynamic Input Textures. By marrying pieces of Dolphin's custom texture support and controller configuration, texture packs can now be aware of what control is mapped to what button and <strong>dynamically</strong> change what is displayed on screen!</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/dynamicinputtextures.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/dynamicinputtextures_thumb.webm" type="video/webm"/>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/dynamicinputtextures_thumb.mp4" type="video/mp4"/>
</video></a></div>
<figcaption>Custom Texture creators now have unprecedented control over how inputs are displayed on screen!</figcaption>
</figure>
</div>
<p>With this feature, when using supported packs users will no longer need to worry about swapping out controller images. When everything is working correctly, users installing texture packs with this feature will only need to copy some files into the Load directory, and that's it! Dolphin is aware of what button you've mapped to what input and can dynamically pull textures from the texture pack in order to match things up so long as it's configured correctly. You can even swap individual buttons and watch them change in real time!</p>
<p>Since this is a feature for texture pack creators, users just need to wait for texture pack creators to update their packs to support it. In fact, you can move on to the next section if you'd like. But if you are a texture pack creator, a power user wanting to add support to an older pack for personal use, or just interested in the process, read on. It's time to talk about this feature in depth.</p>
<h4 id="creating-a-dynamic-input-texture-pack">Creating a Dynamic Input Texture Pack<a class="headerlink" href="#creating-a-dynamic-input-texture-pack" title="Permanent link">¶</a></h4>
<p>Technically you can create Dynamic Input Textures entirely on your own, but to make the process simpler <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has provided a companion <a href="https://github.com/iwubcode/DolphinDynamicInputTextureCreator">tool</a> to help create these dynamic textures packs. They also made a <a href="https://github.com/iwubcode/DolphinDynamicInputTextureCreator/wiki/Tutorial">tutorial</a> that explains how to use it. But here is a quick summary for the sake of demonstrating how it works. First, provide the tool with the original game button textures to get the hash of each button texture into the application. Then map the emulated controller buttons to those button textures so the application knows which button each texture is, for example, mapping the Wii Remote A button texture to "Wii Remote 1, Buttons/A". Now import the custom textures for the host controller, and configure the buttons with their Xinput or Dinput buttons. For example, for the texture of the A button on the Xbox One controller, the device is XInput/0/Gamepad and the input is 'Button A' (including ticks). Repeat for any additional host controllers, then export the pack, and we're done! Now, to reiterate, this was only a summary and it absolutely simplified the process. For the full instructions, please use <a href="https://github.com/iwubcode/DolphinDynamicInputTextureCreator/wiki/Tutorial">iwubcode's tutorial</a>.</p>
<p>Now, that said, there are a lot of limitations to this feature, especially for the time being. Keep these notes in mind if you intend to use this feature in your pack.</p>
<ul>
<li>Texture pack creators must configure the controllers their pack supports and release a new version of the pack. Existing custom texture packs will continue to work exactly as they always have, and for compatibility reasons this is not going to change. </li>
<li>The accompanying tool is in a bit of a beta state. It, and the tutorial, are improving rapidly, but as of this writing there are some bugs, quirks, and UX problems.</li>
<li>The devices that the texture pack creator sets up need to match exactly with the one the user is using, otherwise it will not work. For Xinput devices like the Xbox One controller, this is trivial. Everyone supports XInput/0/Gamepad. But for devices like Playstation controllers which have <em>many</em> different ways of mapping, how the texture pack creator decides to map that controller will matter a lot. Please be explicit in explaining what controllers and drivers are supported in your instructions to users.</li>
<li>There are some built in controller and button names to speed up common mappings. This is limited to Wii Remote, Classic Controller, and Xbox controller for now. More will be added later. Also, joysticks and motion controls are missing from this for now, and have to be entered manually.</li>
<li>Controller configurations that work by pretending to be another controller will not function correctly with Dynamic Input Textures. This disqualifies all the Playstation controller mapping tools that make the Playstation controller pretend to be an Xbox controller. There's nothing we can do about this.</li>
<li>Games that use color-key transparency <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/colorkey.jpeg">do not cooperate with this feature</a>. This is a known issue and a fix is planned.</li>
<li>If an emulated controller input has two different textures, such two different styles of the same button, then Dolphin will pick one and always use that one for all instances of that mapping. You can see this in the gif above: the B/Circle button should be in the style of the X/Square button, but instead it is an angled style used for the main menu. The companion tool has no way to handle this at this time, but we hope to address this in the future.</li>
<li>"Blank" input textures, such as a texture showing an analog stick with no inputs, are currently not supported. With a little creativity this can be worked around, such as mapping it to an analog stick direction so Dolphin knows which texture to use. This should improve in the future.</li>
<li>Dynamic Input Textures can support support advanced expressions (such as "and", "or", and others) if mapped 1:1 with Dolphin, but there is no way to show it in textures. This may change later.</li>
<li>Mapping bits of group textures is supported on the emulated controller side, but not on the host controller side. This is a planned feature.</li>
<li>Exported results for Dolphin cannot be edited by the application. Remember to save your dynamic input projects! And since saves are also JSON files, be sure to keep them separate.</li>
<li>When reopening saved dynamic input projects, the textures they expect must be in the same spot they were when it was saved. Currently, if they are missing the application will crash. That should not remain an issue for long.</li>
</ul>
<p>While that was a lot of notes, Dynamic Input Textures has a lot of potential benefits for texture pack creators. It can offer a drag and drop experience for users, allowing pack creators to get away with FAR simpler installation instructions. And that also means support should be easier too! Plus pack creators can get much more creative with input support in their packs without worrying about ballooning complexity for users. It's a really great option for texture pack creators going forward.</p>
<h4 id="50-12881-remove-asciiart-shader-by-spacexcheesewheel"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12881/">5.0-12881 - Remove AsciiArt shader</a></strong> by <strong><a href="https://github.com/SpaceXCheeseWheel">SpaceXCheeseWheel</a></strong><a class="headerlink" href="#50-12881-remove-asciiart-shader-by-spacexcheesewheel" title="Permanent link">¶</a></h4>
<p>It is with great sadness and regret that we announce that our beloved asciiart post processing shader has been removed from Dolphin. While we have removed many popular features in the past, such as the <a href="https://dolphin-emu.org/blog/2013/10/12/d3d9-why-its-not-part-dolphins-future/">D3D9 backend</a> and <a href="https://dolphin-emu.org/blog/2014/05/19/obituary-32bit/">32-bit support</a>, this one by far hurt the most. </p>
<p>... Okay, maybe it wasn't our most popular feature, in part because of its <em>ludicrous</em> performance demands that made even 1x native at fullspeed impossible for... forever. And yes, it has been completely broken since the <a href="https://dolphin-emu.org/blog/2019/04/01/the-new-era-of-video-backends/">Unification of Videocommon</a> nearly two years ago. And sure, post processing injectors like Reshade can do a <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/asciiart-reshade.png">similar (though much simpler) effect</a> while being actually performant. </p>
<p>But still, it was a feature we loved. It was quirky, ridiculous, and pretty useless, but it was ours, and we are sad to see it go. Goodbye asciiart!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/asciiart-windwaker.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/asciiart-windwaker_thumb.jpg"></a>
<figcaption>Oh asciiart, we will never forget you.</figcaption>
</figure>
</div>
<p>However! As a final farewell we tried it with 2020 hardware and discovered, with much surprise, that modern hardware has finally caught up to the asciiart shader! Fullspeed at 1x Native was finally possible in almost every game! It only took a 9900k and an overclocked RTX 3090.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/eCXRQ1WwHlc" allowfullscreen></iframe></div>
<figcaption>Finally fullspeed! <br/><small>Please crank the resolution on Youtube as much as you can, Youtube hates this shader.</small></figcaption>
</figure>
</div>
<p>Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/asciiart-3090.png">HERE</a> for a sampling of how demanding 1x Native asciiart at fullspeed is on a 3090!</p>
<h4 id="50-12952-ios-hle-abort-pending-operations-on-shutdown-by-sepalani"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12952/">5.0-12952 - (IOS-HLE) - Abort Pending Operations on Shutdown</a></strong> by <strong><a href="https://github.com/sepalani">Sepalani</a></strong><a class="headerlink" href="#50-12952-ios-hle-abort-pending-operations-on-shutdown-by-sepalani" title="Permanent link">¶</a></h4>
<p>Many many years ago, Dolphin's slowly improving IOS emulation mixed with Wii online infrastructure shutting down resulted in a very frustrating regression that would stop would be dancers in their tracks. The video game series, <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Just_Dance_(Series)">Just Dance</a> suddenly started freezing in the main menu in <em>most</em> of their online enabled games. And we're not talking about <em>one</em> game, we're talking about over a dozen that were releasing up until last year!</p>
<p>These games <em>did</em> work in the past, however this isn't actually a Dolphin regression. Instead, the games themselves changed because the servers they were connecting to no longer exist! While this didn't result in any major problems on the Wii, Dolphin's implementation of the network modules assumed that <a href="https://en.wikipedia.org/wiki/Network_socket">socket</a> operations would always complete before a socket is shut down. Since Dolphin was waiting for a reply from the Ubisoft servers and not aborting the pending operations, the game, too, was waiting for a reply that never came. The only way users could work around it was <em>disconnecting their computer from the internet</em> or gutting their NAND of the certificates needed to access online play.</p>
<p><strong><a href="https://github.com/sepalani">Sepalani</a></strong> is no newcomer to the Wii's network services and has been steadily improving things for quite a while. This one has been quite the labor, with hardware tests made and tested across Windows, Linux, macOS and Android to make sure the behavior matched what the games expected regardless of operating system. He discovered there was missing or broken functionality on <a href="https://github.com/dolphin-emu/dolphin/pull/9191">Android</a> and <a href="https://github.com/dolphin-emu/dolphin/pull/9214">macOS</a> and has brought forth fixes so that they can pass the hardware tests as well.</p>
<p>The end result is better online behaviors all around and no more hanging in the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Just_Dance_(Series)">Just Dance</a> games.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/justdance-working.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/justdance-working_thumb.jpg"></a>
<figcaption>With this change, Just Dance now just works!</figcaption>
</figure>
</div>
<h4 id="50-12962-logic-ui-for-virtual-notches-by-nick-michael"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12962/">5.0-12962 - Logic & UI for "Virtual Notches"</a></strong> by <strong><a href="https://github.com/nick-michael">nick-michael</a></strong><a class="headerlink" href="#50-12962-logic-ui-for-virtual-notches-by-nick-michael" title="Permanent link">¶</a></h4>
<p>The Nintendo GameCube controller is broadly speaking very close to any typical modern gamepad. Two joysticks, four face buttons on the right, triggers, dpad, etc etc. However, the GameCube controller has many unique features that most gamepads do not have. These differences can make it surprisingly hard to recreate the intended control experience on modern controllers. As developers and a community of users, we've learned to adapt to these quirks. Dolphin has many features designed to recreate these features as best as we can, and even physical differences like the face buttons can be accounted for with a little creativity. However, there was a commonly overlooked unique feature of the GameCube controller that we had no way to recreate; a feature that noticeably impacts the play experience in the majority of the GameCube's catalog. The GameCube Controller has <em>octagonal gates</em>.</p>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:40%; min-width:180px; float:right; text-align:center;">
<a href="https://commons.wikimedia.org/wiki/File:Gamecube-controller-breakdown.jpg">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/gcoctogonalgate.jpg">
</a></div>
<p>A joystick gate is the border that limits the maximum tilt of the joystick. To put it simply, when you tilt the controller all the way and you hit that rim of plastic, you just hit the gate. Most modern controllers use perfectly circular gates, but Nintendo stuck with octagonal gates for a very long time, well after everyone else had moved onto circular gates. Because, quite frankly, octagonal gates are <em>fantastic</em> for 3D platformers. By having "notches" in the gate that lock the joystick into a specific angle, the player intuitively knows the exact input they are giving the game. This allows for some incredibly precise and high level play, as we've seen in speedrunning. <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_64">Super Mario 64</a>'s crazy speedrun techinques are tremendously easier when using a controller with octagonal gates, as the speedrunner can go to a spot, manipulate the controller a certain way, and consistently land at the same spot, even when passing through multiple universes! However, octagonal gates can be considered annoying for games that don't need such precise movement, as they make continuous rotation less fluid. So when the 3D platforming genre slipped into the background, Nintendo finally moved to circular gates with the Wii U.</p>
<p>Nevertheless, the majority of the GameCube catalog benefits from the octagonal gates that they were designed for. But anyone playing these games with modern controllers will be missing that element of the experience. <strong><a href="https://github.com/nick-michael">nick-michael</a></strong> was playing the GameCube version of Super Monkey Ball, and just didn't feel right on a controller without an octagonal gate. So they decided that they were going to fix this discrepancy - through emulation! <strong><a href="https://github.com/nick-michael">nick-michael</a></strong> created a "virtual notch" system that emulates the effect of an octagonal gate on modern circular gate controllers by snapping some of the joystick's range to octagonal directions. It doesn't emulate the feel of an octagonal gate, so the player won't intuitively feel their input the way an octagonal gate allows, but it emulates the results of the gate shape. If you need to do a really precise set of jumps in a platformer, you can be more or less correct and the notch emulation will send the perfect inputs that you would have been gotten by pressing those almost correct directions into a GameCube Controller.</p>
<div class="media-block full-width">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/virtualnotches.mp4" type="video/mp4"/>
</video></div>
<figcaption>With customizable "Virtual Notches" you can make games control much more precisely even on circular gate controllers!</figcaption>
</figure>
</div>
<p>This can be customized as well, allowing for very tiny precise "notches" or really big ones that dominate the controller directions. And of course, it's all disabled by default, so you can completely ignore it if you prefer.</p>
<h4 id="50-13039-create-wii-shop-log-files-when-installing-a-wad-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13039/">5.0-13039 - Create Wii Shop log files when installing a WAD</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-13039-create-wii-shop-log-files-when-installing-a-wad-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>This isn't technically an emulation bug, but rather an unfortunate confluence of console and game behaviors in an era when the Wii Shop is no longer around to install DLC. Once we knew what was wrong it was easy to fix, but actually getting to that point was the actual difficulty.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/megaman9-nodlc.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/megaman9-nodlc_thumb.png"></a>
<figcaption>The DLC modes are missing, even though they should be installed here.</figcaption>
</figure>
</div>
<p>The original issue report we were working from was simple: Mega Man 9's DLC worked in Dolphin 5.0 but at some point stopped installing correctly in the latest development builds. We believed it was an issue during the installation process as if you took the NAND you created from Dolphin 5.0 and used it in the latest development builds, the DLC would appear as per normal. A simple bisect would <em>usually</em> solve an issue like this, but various testers had inconsistent results where the DLC would suddenly start working, even on the latest development builds! Worse yet, we didn't know exactly <em>why</em> it would start working, sometimes simply running other games would be enough to jolt the DLC into working.</p>
<p>Eventually, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> narrowed down the behavior difference to <a href="https://download.dolphin-emu.org/download/dev/a4de3922e91a23137c6166b50d0392fdf24fa7da/">5.0-7422</a>. Upon looking into it, there was one notable difference - the creation of the Wii Shop log files. <strong><a href="https://github.com/Leoetlino">Leoetlino</a></strong> figured we wouldn't need to create those files as the games <em>should</em> create them on their own regardless of if the DLC were downloaded from the Wii Shop or manually installed. However, it turns out we were proven incorrect by Mega Man 9 and likely other titles. The reason why some of us couldn't reproduce the issue is that once you access the Wii Shop Channel, the issue will completely disappear for that NAND permanently.</p>
<p>The reason that <em>some</em> of us couldn't reproduce the issue is that other games, DLC, and channels could create those files along the way and effectively fix the situation. In order to prevent this from happening again, we now ensure that the Wii Shop log files are created when installing a wad file.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/megaman9-dlc.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/megaman9-dlc_thumb.png"></a>
<figcaption>Now the DLC modes are available!</figcaption>
</figure>
</div>
<h4 id="50-13043-add-a-skip-efb-access-hotkey-by-losuc"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13043/">5.0-13043 - Add a Skip EFB Access Hotkey</a></strong> by <strong><a href="https://github.com/Losuc">Losuc</a></strong><a class="headerlink" href="#50-13043-add-a-skip-efb-access-hotkey-by-losuc" title="Permanent link">¶</a></h4>
<p>This has been a requested feature by users with weaker computers for a <em>very</em> long time, but it was a niche use case so we resisted adding it. However, after years of hotkey improvements adding and using hotkeys has been refined so much that we're at the point where we can go "why not?". <strong><a href="https://github.com/Losuc">Losuc</a></strong>'s addition of a hotkey for EFB Access from CPU can be very useful in games that only need it enabled for specific actions or scenes. Take for example <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> where EFB Access is used a lot but only required for things like Pull Stars and feeding starbits. By only enabling the feature when necessary, you can make the game run on lower hardware than otherwise possible. The same goes for <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">Wind Waker</a> where EFB Access is only needed for the Pictobox.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/mariogalaxy-pullstars.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/mariogalaxy-pullstars_thumb.jpg"></a>
<figcaption>Now you can use EFB Access for levels like this, and easily disable it elsewhere.</figcaption>
</figure>
</div>
<h4 id="50-13081-fix-super-mario-sunshine-debug-cubes-by-stenzek-and-pokechu22"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13081/">5.0-13081 - Fix Super Mario Sunshine debug cubes</a></strong> by <strong><a href="https://github.com/stenzek">stenzek</a></strong> and <strong><a href="https://github.com/Pokechu22">Pokechu22</a></strong><a class="headerlink" href="#50-13081-fix-super-mario-sunshine-debug-cubes-by-stenzek-and-pokechu22" title="Permanent link">¶</a></h4>
<p>To be completely honest with our readers, we <em>really</em> wanted to get this one merged before the end of the last progress report when Nintendo's very own emulator in Super Mario 3D All Stars was discovered to share the same bug. After all, we <em>had</em> the fix and knew it would make for some good screenshots. But alas, unfortunate hindrances like <em>code review</em> and <em>testing</em> got in the way of our devious plan. This particular fix has actually been in the pipeline for a long time, but got delayed and unfortunately forgotten.</p>
<p>For anyone who isn't familiar, during development <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Sunshine">Super Mario Sunshine</a> had dots for traveling platforms indicating their travel, just like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_64">Super Mario 64</a>. However, in the final game the dots were removed. Kind of. The dots are technically still present in the released game, however Sunshine makes them completely transparent. Unfortunately for anyone making a GameCube emulator, the way Sunshine accomplished this is a bit out of the ordinary.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-broken.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-broken_thumb.jpg" /></a>
<figcaption>In Dolphin, there were cubes along the path of the platforms.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-console.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-console_thumb.jpg" /></a>
<figcaption>But the cubes do not appear on console.</figcaption>
</figure>
</div></div>
<p>This has been such a mysterious issue that there have been multiple working theories over the years. Everything from caching the color drawn from the previous pixel, and even wondering if the debug cubes showed up because Dolphin was reporting itself as a debug console!</p>
<p>So what is actually going on here? Well, this is actually related to the <a href="https://dolphin-emu.org/download/dev/066471be076994ea8538d13e8d6979609193a2de/">Cel Damage fix from a few years ago</a>. In fact, the pull request that fixed Cel Damage is where this Sunshine fix originally came from! In Sunshine, the game is setting <strong>numColorChans</strong> (the number of color channels) to 0 for the debug cubes. However, the debug cubes have a full color index with colors that are in use. The question is clear: why is the game setting the cubes color channels to 0? Well, according to hardware testing, if <strong>numColorChans</strong> is a value lower than what is present in the color index, it will use whatever was left in the register. This is undefined behavior. <em>A hack</em>, to put it more bluntly. It is our best guess that they did this peculiar trick to make the debug cubes disappear late in development without editing anything that would force builds to go through QA again, but we have no way to know for sure.</p>
<p>Dolphin, and likely Nintendo's emulator in Super Mario 3D Allstars, made the logical assumption that if a game set numColorChans to 0, it wasn't using the lighting system for that object. But by <em>skipping</em> that step, we were actually skipping the very process that made the cubes invisible!</p>
<p>While we're not sure how Nintendo fixed the cubes on their end, our fix is quite simple. <strong>numColorChans</strong> is a register on console, so the game is relying on undefined register behavior. Registers are more or less as low level as you can get in a processor, and properly emulating bizarre register quirks would be <strong>huge</strong> performance hit. So we've hardware tested this particular case and figured out what values the console gave us, and by slipping in those values when we need it, we were able to recreate the correct behavior in Super Mario Sunshine. Maybe one day we can afford to fully emulate the registers to the degree that quirks like this will just work, but this was the best solution for now. And since it's based on hardware testing it has been very safe in our game tests.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-working.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/debugcubes-working_thumb.jpg"></a>
<figcaption>Now the debug cubes are properly disappeared in Dolphin!</figcaption>
</figure>
</div>
<p>Sadly, Nintendo <a href="https://www.nintendolife.com/news/2020/11/it_seems_the_debug_cubes_in_the_3d_all-stars_version_of_mario_sunshine_are_no_longer_visible">managed to patch the debug cubes</a> a few days before <a href="https://dolphin-emu.org/download/dev/master/5.0-13081/">we did</a>. But that's ok. As their GameCube emulator has a catalog of effectively <em>one game</em>, they didn't have to worry about regression testing the way we have to. It's fine, we're not mad. It wasn't fair so it doesn't count.</p>
<p>As a special note, this is actually our <em>second</em> merged fix for the debug cubes. However, severe regressions from the first attempt prompted its removal and forced the hardware tests that eventually lead to this fix. But, for fun, here's a quick reminder as to how a fix for one game can break another if you're not doing things right with <a href="https://wiki.dolphin-emu.org/index.php?title=Tony_Hawk%27s_Pro_Skater_3">Tony Hawk's Pro Skater 3</a>.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tonyhawkfifo-broken.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tonyhawkfifo-broken_thumb.jpg" /></a>
<figcaption>The original fix hid more than just the debug cubes.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tonyhawkfifo-working.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tonyhawkfifo-working_thumb.jpg" /></a>
<figcaption>But the new fix has no regressions. ...that we know of.</figcaption>
</figure>
</div></div>
<h4 id="50-13163-remove-description-box-in-graphics-tabs-and-use-custom-tooltips-instead-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-13163/">5.0-13163 - Remove description box in graphics tabs and use custom tooltips instead</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-13163-remove-description-box-in-graphics-tabs-and-use-custom-tooltips-instead-by-iwubcode" title="Permanent link">¶</a></h4>
<p>Dolphin has had a bit of a long <em>standing</em> problem with the graphics configuration window. <em>It's too damn tall</em>. As we've added many more advanced graphical settings, the advanced tab has grown immensely. And since every tab needs to be as tall as the tallest tab (by default), everyone gets to deal with a lovely <em>922 pixels tall window.</em> Admittedly, for anyone with massive resolution modern displays this doesn't even matter. But we have definitely heard the complaints of those with 768p and 720p screens. As such, to make sure everyone can see everything in the graphics configuration, resizing was added to the graphics configuration window. No matter how tiny your screen, you will be able to use and configure Dolphin... just with a bit of extra scrolling.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-lowres.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-lowres_thumb.png"></a>
<figcaption>To show this tab with scroll bars we had to go all the way to 800x600. Even this teeny tiny resolution, a whooping 0.48 megapixels, is totally usable in Dolphin.</figcaption>
</figure>
</div>
<p>This is fine. <em>It's fiiine.</em> But it just keeps bugging us. We may have solved the usability problem, but the window is still enormous, and as new features get added in the future, will it stay fine? It isn't that far from requiring scrolling on even <em>1080p</em> screens. So as we pondered this quandry, our eyes turned to the venerable description box.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-descriptiondemo.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-descriptiondemo_thumb.png"></a>
<figcaption>Dolphin has a lot of very unique things to explain, and the description lets us do that.</figcaption>
</figure>
</div>
<p>The description area has been very important for us as an emulator. Dolphin has a lot of weird graphical emulation quirks and options to work around them, and we desperately need a reliable way to educate users about what these options do and why they may or may not want to use them. So, whenever a user moves their mouse over a graphical feature, a description explaining that feature will appear in the description box. It's simple, and has worked wonders for us for a lot of years now. However, some of those descriptions are (necessarily) long winded. The description area is now a huge 200 pixels of vertical height. This is contributing a lot to our window height problem!</p>
<p>Still though, mousing over something for more information... isn't that usually done by a tooltip? Why are we devoting so many pixels of height for something that typically would be handled with non-permanent means? That's because these descriptions <em>used to be tooltips.</em> And they were <em>awful.</em></p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-old.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-old_thumb.png"></a>
<figcaption></figcaption>
</figure>
</div>
<p>Dolphin 2.0 used the plain old Windows tooltip. Designed for small optional tidbits, it was entirely inadequate for our purpose of educating users about complex emulation features. Also, from a modern UI design perspective, they were just bad. </p>
<ul>
<li>They took a full second to appear, limiting accidental discovery.</li>
<li>Faded in over a half second, then faded out over another half second. That plus the long activation time made for a slow and tedious way to get information.</li>
<li>White boxes with black text over white boxes with black text made them difficult to notice and read.</li>
<li>We tend to read top to bottom, and the tooltips placement below the cursor blocks the next item the user might want to read and annoyed them so they ignored and quickly dismissed the tooltip.</li>
<li>Most items didn't have tooltips applied to them, so even if a user was looking for them they most likely would try, fail, and assume we didn't have any tooltips.</li>
</ul>
<p>On and on. They were terrible, failing to adequately fulfill their purpose, so <em>no one used them</em>. Which just made the tooltip situation worse as developers had no reason to bother adding tooltips that no one would ever read! It was a problem, as Dolphin needed, desperately, to convey emulator-specific options to users and educate them. And so, we moved to an always visible description box model. By being literally an empty space that filled with text when a user hovered over a feature with their mouse, it is very obvious and very clear, allowing it to properly fulfill the role of conveying information to the user. The description area has played no small role in forming the knowledgeable user base that Dolphin has today. </p>
<p>But it still takes a lot of height, contributing greatly to the graphics config height problems. How do we fix this without losing the essential functionality that description box provides? iwubcode posed that question in Dolphin's IRC. MayImilae, our resident UI assistant, has had a long time to consider this issue. She responded with the results of years of UI pondering - the best option is to go back to tooltips, but <em>make them good</em>. She made a <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/moderntooltipmockup.png">mockup</a> demonstrating modern tooltip techniques in Dolphin, and iwubcode took on the challenge of implementing custom tooltips in Dolphin's UI. Qt limitations made it so not everything we wanted could be implemented, but iwubcode made a huge impact!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltips-new.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltips-new_thumb.png"></a>
<figcaption>Modern tooltips are up for the task!</figcaption>
</figure>
</div>
<p>Let's go over everything that these tooltips do right compared to the ancient tooltips above.</p>
<ul>
<li>Appears quickly (300ms) allowing for easy accidental discovery without getting in the way.</li>
<li>No fade in or fade out, allowing the user instant access to the information then gets out of the way. While this was a functional choice, it just <em>feels better</em>. </li>
<li>High contrast allows the tooltip to stand out from the original window, making the tooltip easy to notice and the text extremely easy to read.</li>
<li>The tooltip appears <em>above</em> the target, so it doesn't block the view of the next item the user may want to see when reading top to bottom.</li>
<li>Points to the option it is referring to, further improving clarity.</li>
<li>The "if you are unsure" text is contrasted even stronger with a unique color and bold font, easing at a glance guidance for casual users.</li>
<li>Consistent across all desktop operating systems. Anyone who has worked with tooltips before knows just how nice that is.</li>
</ul>
<p>By using these custom tooltips, designed for the purpose, Dolphin is able to effectively convey necessarily information to users while also freeing up the height of the description area! And thanks to the high contrast background, it's <em>even more clear</em> than the description area was as evident <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltip-demo.png">when showing them side by side</a>! This is the have our cake and eat it too solution we've been wanting for years. Now, this is still a work in progress, and we hope to make further improvements over time. For example, it has uneven corners and complete lack of HiDPI support. Still, even where it is now it is a very good solution to our troubles. Plus, since these custom tooltips do not require adjusting the size of the window, hopefully we can finally bring descriptions to more places in our UI.</p>
<p>For our resident dark mode lovers, the <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-october/tooltips-newdark.png">tooltip is inverted there as well to maintain functionality</a>. If you are annoyed by the white tooltip interrupting your black on black oasis, you can switch to a low contrast mode with an <a href="https://github.com/dolphin-emu/dolphin/pull/9153#issuecomment-738585280">INI option</a>. </p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2020-10-01&to=2020-11-30&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-12718/">5.0-12718</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-13178/">5.0-13178</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: July, August, and September 2020
2020-10-05T04:58:36+00:002020-10-08T02:20:36.000227+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2020/10/05/dolphin-progress-report-july-and-august-2020/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/dolphinprogressreportheader-august2020-2.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/dolphinprogressreportheader-august2020mini-2.jpg" />
</header>
<p>Kept you waiting, huh? This summer we had our longest break since we started writing these Progress Reports. Some other obligations came up and a bit of a lull in development gave us the opportunity to postpone things for an extra month. As it turned out, pushing things back <em>might</em> have been a bad idea, as the floodgates opened and now there's a gigantic backlog spanning three months to get through! To put things into perspective, since our last Progress Report, the last Nintendo Wii games were released, Dolphin Android had a huge user experience overhaul, and Nintendo's very own GameCube and Wii emulator hit the Switch with Super Mario 3D All Stars.</p>
<p>So without further delay, let's start getting through the backlog. This one is a bit of a doozy.</p>
<p><a id="cuthere"></a></p>
<h3 id="the-android-user-experience-overhaul"><strong>The Android User Experience Overhaul</strong><a class="headerlink" href="#the-android-user-experience-overhaul" title="Permanent link">¶</a></h3>
<p><br/></p>
<p>Dolphin on Android isn't always the smoothest experience. From the fact that most mobile hardware targets efficiency over power, to the fact that Dolphin's Touch GUI lacks a lot of features present in Dolphin on desktop computers. Things we take for granted on other operating systems were simply missing from Android. The unworkable config system Dolphin used on Android made it impossible to even change emulator settings while a game was running! Over the summer, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> has been chipping away and we're happy to say that the latest Play Store release and development builds finally take advantage of our <a href="https://dolphin-emu.org/blog/2017/07/01/dolphin-progress-report-june-2017/#50-4171-videoconfig-port-to-layered-configuration-system-by-merrymage">layered config system</a>!</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/androidmenu.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/androidmenu_thumb.mp4" type="video/mp4"/>
</video></div></a>
</figure>
</div>
<p>The biggest change is that you can now directly change settings while emulation is running, much like Dolphin's desktop interface. This finally allows Android users to try things like pushing the resolution to see how high it can go before it affects performance, or quickly enabling/disabling hacks to try to find the perfect balance, all without stopping emulation! You might notice the GUI itself has had a bit of a rework, too. Now instead of a drag down menu, hitting the <em>back</em> button will open up a much more robust side menu. While this works better in general, it also allows Android devices that lack a touchscreen to access the menu, such as chromebooks. This menu is the same menu that Android TV Dolphin users have already been using, however it's now been overhauled to support these new features! </p>
<p>Beyond that, <strong><a href="https://github.com/Ebola16">Ebola16</a></strong> and <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> have been doing a ton of work on the rest of the Android GUI. Together, they've repaired things such as the touch/motion pointer not working in some instances, GameCube Adapter detection being spotty, touch layouts getting reset or not saving properly, added missing settings to the menus, and much more. These changes are rather minor in isolation, but together make a much smoother experience overall.</p>
<p>We have one last major addition to Android. In this case, it's a bit easier to show than tell.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/ISOconversion.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/ISOconversion_thumb.png"></a>
<figcaption>Disc compression/conversion, now in the palm of your hand!</figcaption>
</figure>
</div>
<p>That's right, <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> hooked up Dolphin's conversion and compression tools to Dolphin Android! If space is at a premium, you can now compress your disc images into formats suitable for Dolphin without the need for a desktop computer or external software! While Dolphin Android could already take advantage compressed formats, such as Dolphin's new RVZ format, users finally get the power to do everything directly from their mobile device.</p>
<h3 id="notable-changes">Notable Changes<a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-12575-jit-codegen-space-reuse-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12575/">5.0-12575 - JIT Codegen Space Reuse</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-12575-jit-codegen-space-reuse-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>Now that we're done with Android, here's a big one that currently only affects our desktop users. This major change is only for JIT64, Dolphin's PPC to x86-64 recompiler. However, unlike most changes to the JIT, this isn't an optimization for raw performance nor is it a fix to increase compatibility. Rather, this change targets a specific shortcoming in order to provide a much smoother experience in afflicted games. In this case, we're talking about games that can <em>overflow</em> Dolphin's JIT cache. In order to explain what's going on, let's talk a bit about how Dolphin's JIT works and why it needs a cache.</p>
<p>When Dolphin encounters a piece of PPC code for the first time, it has to translate it into something the host CPU can actually execute. Once it's translated, Dolphin's JITs record these translated instructions to a cache so that if the same PPC code is encountered again, it can skip translation and just execute the already translated code.</p>
<p>...However, that's not the end of this story. Dolphin's x86-64 JIT has never been completely rebuilt from the ground up, so it retains many "oldisms" dating all the way back to when Dolphin was first created. That's not to say that it's bad, Dolphin's JIT was designed to be simple and fast. That core design has allowed tons of innovation and crazy optimizations over the years. There are some catches, however. For example, the JIT was more or less designed to just pile more and more translated game code into the JIT cache with no way to prune or manage that memory. If it somehow filled completely, it would simply overflow and flush everything out of the cache before starting over from scratch. This resulted in a sizeable stutter as all of the cached code was lost and Dolphin had to translate everything once again.</p>
<p>Fortunately for us, this doesn't occur in a majority of games as they don't ever use enough code to overfill the JIT cache. That isn't to say <em>there aren't ways</em> for a game to fill the JIT cache, and over the years we've run into many cases that do. The following titles take advantage of techniques that allow them to blow our cache out of the water, flushing over and over again throughout a play session. And remember, with every overflow has an associated hard stutter. It's one of the final white whales of stutter within Dolphin.</p>
<h5 id="the-classic-loading-new-code-off-the-disc"><strong>The Classic - Loading New Code Off the Disc</strong><a class="headerlink" href="#the-classic-loading-new-code-off-the-disc" title="Permanent link">¶</a></h5>
<p>This is one of the earliest examples Dolphin developers would have run into. Though it was primarily seen in the <a href="https://wiki.dolphin-emu.org/index.php?title=Metroid_Prime_(Metroid_Prime:_Trilogy)">Metroid Prime series</a>, many games loaded additional code off of the disc along with new areas. Even though the player is traveling between areas that have the same enemies, textures, and effects, the game is loading into new areas of RAM each time, so Dolphin's JIT considers each bit of code "new" and just piles it all into the cache. With the Metroid Prime games endlessly loading and unloading as you traverse the world, it's not hard to see how it would eventually overflow a static cache. In fact, with the right pathing, you can do so in under ten minutes!</p>
<h5 id="the-mmu-swapping-code-into-and-out-of-aram"><strong>The MMU - Swapping Code Into and Out of ARAM</strong><a class="headerlink" href="#the-mmu-swapping-code-into-and-out-of-aram" title="Permanent link">¶</a></h5>
<p>This is actually the same problem as loading code off of the disc, except instead of the disc, the code is stored in audio RAM. While it is <em>called</em> audio RAM, as that was the primary intended use of this external ram chip, through Direct Memory Access (DMA) you can store and load whatever you want from it. Considering the GameCube had a paltry 24MB of MEM1 and a rather massive <strong>16MB</strong> of ARAM, it was very common for developers to borrow a bit of ARAM for their own needs. Code loaded from ARAM into MEM1 would be recognized as new code by Dolphin's JIT, even if it was swapped in before. This is primarily seen in games like <a href="https://wiki.dolphin-emu.org/index.php?title=Metal_Gear_Solid:_The_Twin_Snakes">Metal Gear Solid: The Twin Snakes</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>, but it was possible in any title that programmed the <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/#memory-management-unit-emulation">MMU</a>.</p>
<p>Using <a href="https://wiki.dolphin-emu.org/index.php?title=Metal_Gear_Solid:_The_Twin_Snakes">Metal Gear Solid: The Twin Snakes</a> as an example, this game would load new enemy routines out of ARAM when you go into alert mode after being spotted. Even if these enemy routines had been loaded before, their RAM addresses wouldn't be consistent and Dolphin would treat the loaded code as new code each time it translated it. Usually getting spotted just one or two times was enough for Dolphin's JIT cache to run out. <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a> on the other hand is a special case. Of <em>normal</em> games, it does the most swapping in and out of ARAM that we've seen.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-january/truecrimestutters.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/truecrimestutters_thumb2.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>This game was the real crime.</figcaption>
</figure>
</div>
<p><em>As an extra note. Yes, <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_II:_Rogue_Leader">Star Wars: Rogue Squadron 2</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Star_Wars_Rogue_Squadron_III:_Rebel_Strike">3</a> also do a lot of ARAM transfers and will overflow the code cache. It's just barely worth mentioning because they have so many other problems still.</em></p>
<h5 id="the-jitception-nintendo-64-virtual-console-games"><strong>The JITception - Nintendo 64 Virtual Console Games</strong><a class="headerlink" href="#the-jitception-nintendo-64-virtual-console-games" title="Permanent link">¶</a></h5>
<p>Jitting a JIT generates a lot of dynamic code. <strong>A lot</strong>. If you were playing <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Ocarina_of_Time">The Legend of Zelda: Ocarina of Time</a> on N64 Virtual Console, it wasn't uncommon for Dolphin to have to clear the JIT Cache three to four times <strong>a minute</strong>. These stutters would essentially render the game unplayable as it'd hitch too often to really do anything. Considering that these games came out late into Dolphin's development <em>and</em> didn't really run well in Dolphin until 2014, these games didn't get a fair look. Even when reports of the constant stuttering did come in, they weren't a huge priority for most normal people. In recent years, people generating randomizers have the ability to output them as <em>wads</em> that can be run on Wii, and thus Dolphin, resulting in an uptick in reports of rampant stutters.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/OoTR1.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/OoTR1_thumb.jpg" /></a>
<figcaption>Loading zones would often generate a ton of new code. It may not look like it, but take a few steps and...</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/OoTR2.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/OoTR2_thumb.jpg" /></a>
<figcaption>The next area with enemies has loaded! Mid-gameplay transition points like these would often assault users with stutters during gameplay.</figcaption>
</figure>
</div></div>
<p>The thing to remember with all of this is that all of these cases are <em>exceptions</em> and make up a tiny portion of Dolphin's library. Even when developers found these cases, the stutters weren't really considered an issue so much as a consequence of how Dolphin emulated things. It wasn't exactly a <em>good</em> behavior, but fixing it permanently pretty much meant rethinking the JIT and there were several other impossible problems like <a href="https://dolphin-emu.org/blog/2017/07/30/ubershaders/">shader generation</a> that meant stuttering like this would never really be a major issue!</p>
<p>...Yet here we are, with JIT cache flush stuttering being the main source of <em>random</em> stutter left in the emulator.</p>
<h5 id="making-better-use-of-space"><strong>Making Better Use of Space</strong><a class="headerlink" href="#making-better-use-of-space" title="Permanent link">¶</a></h5>
<p>The main problem at hand was that Dolphin's JIT simply wasn't designed to handle a game generating its own code. By constantly appending new code to the end of the JIT cache, the cache would eventually fill up and flush again and again without any reprieve. Some desperate users even modified Dolphin to have a <strong>2GB</strong> JIT cache as a way of alleviating the problem. While it's true, a bigger JIT cache did reduce <em>how often</em> the JIT cache flushes happened, it did not eliminate it completely and did result in longer stutters when they did happen. What <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> did was look at the problem from the perspective of the what Dolphin's JIT could do and how we could make it work without a total redesign. His solution? Keep track of what PPC code the game is invalidating and mark it as "free space" in the JIT cache. When adding new code to the cache, Dolphin can use this space for new code instead of continuously writing more and more to the end of the cache until it fills up.</p>
<p>This clever addition alleviates the main cause of stutter and is enough to never see a full JIT cache flush <strong>period</strong> in most titles. However, this method isn't perfect. If a game just loads or generates enough code, it's actually still possible to fill the cache even with this new feature. This is because of a new problem: fragmentation. Even if the cache has free space, it's possible for all of the memory to be scattered about in tiny blocks that aren't big enough for when the game wants to shove a big block into cache! Dolphin is also <em>relying</em> on the game to actually invalidate things correctly. If a game is poorly coded (<a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>), buggy (<a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>), or has extremely poor memory management (<a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>), it's entirely possible to overflow Dolphin's JIT cache despite this addition.</p>
<p>Even in the cases where games <em>do</em> still run into JIT cache flushing, the flushes are <em>much</em> less common. In The Legend of Zelda: Ocarina of Time (VC), it reduces cache flushes from multiple times a minute to maybe once or twice an hour <em>at most</em> during normal gameplay. For people that play games that dynamically generate code, this change is quite literally <em>game changing</em>. ...Sorry.</p>
<p><strong>Note:</strong> Due to an unknown bug while emulating <a href="https://wiki.dolphin-emu.org/index.php?title=True_Crime:_New_York_City">True Crime: New York City</a>, it's very likely you won't be able to actually play far enough in Dolphin to see the improvements. Standing on destructable scenery slowly pollutes the physics engine with <em>NaNs</em>, which eventually causes the game to crash. To get through to the intro and make it into the city segments where the game is <em>improved</em> by the new code, you'll need to abuse a glitch in the game that allows the character to pretty much pass through any wall.</p>
<div class="media-block narrow">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<video controls muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/truecrimeclipping_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Yes, this is a game bug that works on console for most corners. However, the NaN pollution is an emulation bug we've spent countless hours investigating to no avail. <br/><small>Click/Tap to Play. Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/truecrimeclipping.mp4">HERE</a> for the full clip.</small></figcaption>
</figure>
</div>
<h4 id="50-12263-inputcommongcadapter-fix-offbrand-gcadapters-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12263/">5.0-12263 - InputCommon/GCAdapter: Fix offbrand "GCAdapters"</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-12263-inputcommongcadapter-fix-offbrand-gcadapters-by-billiard" title="Permanent link">¶</a></h4>
<p>When Nintendo released their GameCube Controller Adapter for Wii U, it was an exciting moment for Dolphin users and developers alike. An official, standardized adapter that can connect GameCube Controllers to our computers over USB? Sign us up! Since then, GameCube Controller Passthrough via Wii U and Switch adapters has become a very popular feature in Dolphin. It's no hassle and provides accurate, low latency inputs for games. However, in recent times, we've seen a worrying tend taking hold with third party adapters.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/nykoadapter.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/nykoadapter_thumb.jpg"></a>
<figcaption>Nyko and other popular GameCube Adapter solutions couldn't connect to Dolphin.</figcaption>
</figure>
</div>
<p>Newer models of third party adapters no longer seemed to work with Dolphin. While we could recommend Nintendo's adapter or the Mayflash 4 port that we confirmed worked for Passthrough, these newer third party adapters were cheaper and becoming more common every time we looked. As the questions and requests for support mounted from social media and issue reports, it was clear that this was a problem that wasn't going to go away any time soon. However there was a light at the end of the tunnel - <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> bought an adapter with the problem to follow up on a suggestion on how to fix it. After adjusting Dolphin's adapter connection code slightly, he was able to make it work happily with both official adapters and these newer third party adapters. Everything was merged and things were going to be great!</p>
<p>...Of course, it couldn't be <em>that</em> easy right? Fixing the Nyko style adapters <em>broke</em> Mayflash's adapters, which was a bit of a problem as they are very common among our users and developers had been recommending them as a cost effective alternative that worked for Dolphin. In order to get <em>both</em> kinds third party adapters working happily we had to <a href="https://github.com/dolphin-emu/dolphin/pull/8946">hack things up a bit</a>, but everything seems to be fine for now. Oddly enough, throughout all of these minor connection changes, Nintendo's adapters never stopped working. Go figure.</p>
<p><strong>Note</strong>: This fix for connectivity is only for <em>Desktop</em> Dolphin. Android Dolphin uses a different codepath and it is unknown if it requires further adjustment.</p>
<h4 id="50-12334-dolphinqt-videocommon-add-additional-texture-dumping-options-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12334/">5.0-12334 - DolphinQt / VideoCommon: Add additional texture dumping options</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-12334-dolphinqt-videocommon-add-additional-texture-dumping-options-by-iwubcode" title="Permanent link">¶</a></h4>
<p>This is a quality of life change that should allow making texture packs <em>a little</em> bit easier. In order to only dump the textures you want to update, Dolphin now has the option to <em>skip</em> dumping mipmaps. Outside of specific mipmap effects, dumping mipmaps is effectively useless for HD Texture creation, so being able to disable mipmap dumping will allow texture pack creators to skip sorting through tons of needless mipmaps from the actual full textures. When making a texture pack, there are already a lot of tedious steps that go into dumping and organizing textures, so every little thing that the emulator can do to make things easier adds up. While it was possible to delete all the mipmaps manually with searches or automatically with scripts, now Dolphin can simply avoid dumping them!</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/mipmaps-dumped.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/mipmaps-dumped_thumb.png" /></a>
<figcaption>With mipmaps dumped, the skip travel point in Gaur Plains yields 615 textures.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/mipmaps-notdumped.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/mipmaps-notdumped_thumb.png" /></a>
<figcaption>But the useful textures for this scene is only 309 textures, literally half!</figcaption>
</figure>
</div></div>
<h4 id="50-12336-gamesettings-safetexturecachecolorsamples-for-seupey-and-sevpey-by-chungy"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12336/">5.0-12336 - GameSettings: SafeTextureCacheColorSamples for SEUPEY and SEVPEY</a></strong> by <strong><a href="https://github.com/chungy">chungy</a></strong><a class="headerlink" href="#50-12336-gamesettings-safetexturecachecolorsamples-for-seupey-and-sevpey-by-chungy" title="Permanent link">¶</a></h4>
<p>We've traveled a long road. At this point, the Wii is 14 years old, twice replaced by the Wii U in 2012 and the Nintendo Switch in 2017. While Dolphin was just a GameCube emulator when the Wii was announced and released, it wasn't too long after <a href="https://web.archive.org/web/20080831235856/http://www.dolphin-emu.com:80/2008/07/14/dolphin-now-open-source/">that developers began targeting</a> what was essentially a super charged GameCube with innovative motion controls. The Wii's announcement and similarities to the GameCube breathed new life into Dolphin, and gave the project new challenges, new goals, and a longer tail of active development than anyone could have anticipated. Even with its popularity, we couldn't have imagined the Wii having new games released 14 years after its launch. Even the yearly <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Just_Dance_(Series)">Just Dance</a>, were unbelievable, releasing on Wii after they <a href="https://twitter.com/Dolphin_Emu/status/1138202065597952001">discontinued the Wii U version</a>. </p>
<p>But finally, it all seemed to come to an end earlier this year when Nintendo ended disc manufacturing for the Wii. For the aging console, this was a death sentence. Online distribution had long been shutdown, without discs, there was no other avenue for official releases. The library was set, and the curtain, had dropped.</p>
<p><em>Except the Wii would not go quietly into the night!</em> With the help of Nintendo of Europe, developer <em>vblank</em> managed to squeeze out two last <strong>very</strong> limited run releases before disc manufacturing was shutdown permanently. It was so tight in fact, the games are PAL exclusives because <em>all other presses were already dismantled</em>. And so, we have the final FINAL official Wii titles: <a href="https://wiki.dolphin-emu.org/index.php?title=Shakedown:_Hawaii">Shakedown: Hawaii</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Retro_City_Rampage_DX">Retro City Rampage DX</a>.</p>
<p>Throughout the years, new releases meant new challenges for Dolphin. Developers were constantly discovering new optimizations, abusing Wii features in interesting ways, implementing anti-piracy that would incidentally trip up Dolphin, and sometimes just being so generally incompetent with their code that it's hard to emulate through the power of spaghetti. What challenges would the final two retail Wii games present?</p>
<p>None. Dolphin was more than up to the task of emulating these last two titles. The only adjustment we had to make was one we make for a lot of games: Dolphin's texture cache accuracy needed to be set to safe for certain menus to render correctly. <strong><a href="https://github.com/chungy">chungy</a></strong> made quick work of the issue and the games now run flawlessly.</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/shakedownmenu-broken.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/shakedownmenu-broken.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Without a configured GameINI, Shakedown Hawaii's menu fails to work.</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/shakedownmenu-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/shakedownmenu-working.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>But thanks to a small configuration change, everything works correctly.</figcaption>
</figure>
</div>
<p>And so, with these final two games, the Wii's official library should be well and truly set.</p>
<h4 id="50-12483-add-support-for-freebsdarm64-by-kit-ty-kate"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12483/">5.0-12483- Add support for FreeBSD/arm64</a></strong> by <strong><a href="https://github.com/kit-ty-kate">kit-ty-kate</a></strong><a class="headerlink" href="#50-12483-add-support-for-freebsdarm64-by-kit-ty-kate" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-right:2em; margin-bottom:1em; width:128px; float:left; text-align:center;">
<a href="http://www.freebsd.org/">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2015-june/freebsdlogo.png">
</a>
</div>
<p>FreeBSD support in Dolphin is one of those magical things that sometimes happens with Open Source. Despite having our smallest userbase among "supported" operating systems, FreeBSD continues to receive support and maintenance, from FreeBSD users to keep it running! And since FreeBSD support is noninvasive to the rest of the project, we can just leave it be and let the ones who know it best take care of our FreeBSD support. That passion is examplified this month by <a href="https://github.com/kit-ty-kate">kit-ty-kate</a> extending Dolphin's AArch64 JIT to FreeBSD. We don't entirely know if there are many Dolphin users that overlap with FreeBSD ARM users, but if there is, Dolphin is ready and working!</p>
<h4 id="50-12530-add-patches-to-disable-save-protection-on-pokemon-colosseum-and-pokemon-xd-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12530/">5.0-12530 - Add Patches to Disable Save Protection on Pokemon Colosseum and Pokemon XD</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-12530-add-patches-to-disable-save-protection-on-pokemon-colosseum-and-pokemon-xd-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>In the previous Progress Report, <a href="https://dolphin-emu.org/blog/2020/07/05/dolphin-progress-report-may-and-june-2020/#50-12202-fix-memory-card-issues-with-savestates-by-admiralcurtiss">we mentioned</a> that both <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Colosseum">Pokemon Colosseum</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_XD:_Gale_of_Darkness">Pokemon XD</a> had extra save protection. While it ended up that a bug was causing <em>most</em> games to think that the memory card had changed after savestates, it turns out that these games were broken <strong>by design</strong>.</p>
<p>In order to prevent the duplication of Pokemon, these games have purposeful checks to make sure the savegame has not been tampered with or modified. If it detects anything wrong, it'll simply refuse to save, almost the same as the "bug" shown in other games. Mixing savestates with normal game saves can easily trigger this anti-duplication protection, leaving users stuck to savestates and a particular build of Dolphin for all eternity.</p>
<p>This is <em>technically</em> accurate emulation for these specific games, but it's really not a fun situation for anyone. In order to try to make things less complicated on our users, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> dug into their games and ripped out their save protection. We now provide a nice game patch that you can enable directly in the Game Properties menu if you wish to play the games without these restrictions. If you've already triggered the bug in older builds of Dolphin, these patches can be copied into any build and function all the same. With these patches enabled, the anti-duplication code will not function and you should be able to save even if you've triggered it in the past.</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/pokemonpatch.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/pokemonpatch_thumb.png"></a>
<figcaption>To find these patches, right click either game in the game list and click properties, then go to the Patches tab.</figcaption>
</figure>
</div>
<h4 id="50-12548-disc-interface-increase-latency-for-read-commands-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12548/">5.0-12548 - Disc Interface: Increase Latency for Read Commands</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-12548-disc-interface-increase-latency-for-read-commands-by-josjuice" title="Permanent link">¶</a></h4>
<p>Dolphin has a relatively advanced timing model for simulating disc loading times. It takes into account the length of various commands, simulates Constant Angular Velocity, meaning data toward the outside of the disc is read faster than data on the inside, and much more in order to try to provide reasonable loadtimes that match that of a typical console.</p>
<p>When the DVD drive does various commands, Dolphin has long had a constant called <em>Command Latency</em>. This simulates how long it takes the drive to process a command. Unfortunately, <a href="https://github.com/dolphin-emu/dolphin/pull/4829">when adjusting <em>Command Latency</em> to better reflect the results of hardware tests</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Ed,_Edd_n_Eddy:_The_Mis-Edventures">Ed, Edd n Eddy: The MisEdventures</a> stopped working. Reverting <em>hardware verified</em> numbers to fix a game seemed hacky, so the game remained broken as the cause of the issue went unknown.</p>
<p>Finally, after several years, the answer was finally found. In order to fix this issue, we've split up <em>Command Latency</em> into two different constants. Our general Command Latency is now <em>Minimum Command Latency</em>, meaning it's the smallest processing time a command can take. We've added a new latency for read commands called <em>Read Command Latency</em>. This latency is slightly longer than <em>Minimum Command Latency</em> in order to reflect hardware tests that read commands take longer to process than other commands. This very slight change fixes a hang at the beginning of <a href="https://wiki.dolphin-emu.org/index.php?title=Ed,_Edd_n_Eddy:_The_Mis-Edventures">Ed, Edd n Eddy: The MisEdventures</a>.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/3edloading.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/3edloading_thumb.jpg"></a>
<figcaption>Now you can once again enjoy this high quality title!</figcaption>
</figure>
</div>
<p><em>Note</em>: While testing this change, we discovered that <a href="https://wiki.dolphin-emu.org/index.php?title=Ed,_Edd_n_Eddy:_The_Mis-Edventures">Ed, Edd n Eddy: The MisEdventures</a> has icache issues later in the game. Enabling MMU emulation may alter timings enough to make the game playable past various icache crashes.</p>
<h4 id="50-12656-massive-game-ini-update-by-a-lot-of-people"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12656/">5.0-12656 - Massive Game INI Update</a></strong> by <strong>A lot of people</strong><a class="headerlink" href="#50-12656-massive-game-ini-update-by-a-lot-of-people" title="Permanent link">¶</a></h4>
<p>Usually we don't feature INI updates in Progress Reports unless there is something especially notable in them. There are <em>a lot</em> of changes compiled into this INI update and most of them are simply small adjustments to default performance and accuracy settings to make the game immediately playable. However, a few of these changes stand up above and beyond typical INI changes and deserve to be talked about in more detail.</p>
<h5 id="fix-mvp-baseball-2004-and-mvp-baseball-2005-flickering-graphics"><strong>Fix MVP Baseball 2004 and MVP Baseball 2005 Flickering Graphics</strong><a class="headerlink" href="#fix-mvp-baseball-2004-and-mvp-baseball-2005-flickering-graphics" title="Permanent link">¶</a></h5>
<p>Originally reported <strong>seven years ago</strong> by our own JMC47, <a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2004">MVP Baseball 2004</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2005">2005</a> have had flickering 2D graphics that make the games difficult to play at the very best. While the underlying 3D graphics look fine, the seemingly random flickering of UI elements could obscure gameplay or make simply navigating into the game difficult.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/mvpflickering.mp4" type="video/mp4"/>
</video></div>
<figcaption>The pattern of flickering would even vary based on the different timings between Dolphin Android and Dolphin on Desktops!</figcaption>
</figure>
</div>
<p>So you're probably wondering how an <em>INI</em> update fixed this. It turns out the games' code had a minor mistake, creating a class of game bug that doesn't appear on native hardware but rears its head when we try to emulate it. A race condition.</p>
<p>The GameCube and Wii render with "vertex index buffers" (an index buffer for vertex data used on the CPU while building a draw call, not to be confused with the GPU's vertex buffer). Much like how compression squeezes down duplicate data in a file, vertex index buffers allow a CPU to notice shared vertices within an object and merge them so the GPU doesn't have to render a vertex multiple times. This is just a straight up efficiency improvement and has been a long term staple of 3D rendering. Keep this in mind.</p>
<p>When rendering a quad for 2D elements, MVP Baseball does everything pretty normally. It sets up the quad, writes to the vertex index buffer, and sets up the texture. Nothing fancy, it's just a quad. However, before finishing the draw call by flushing to the GPU, the game writes 0 to the vertex buffer index. That's our race condition. Upon reading this change the GPU will immediately render whatever happens to be in the first slot of the index, so if the GPU is busy rendering then is suddenly redirected to index 0, it will send data to the wrong places and UVs go nuts and things start getting bad. On the GameCube, this never presents a problem, since the ArtX programmable fixed function pipeline renders the quad <em>so fast</em> that it <strong>doesn't even see</strong> the index change. However, as an emulator, we have shaders, APIs, operating systems, and all manner of things to deal with. In Dolphin, the redirection will always reach the GPU at some varied point during the rendering process, leading to randomly incorrect UVs and vertex data when rendering 2D elements - flickering. And since this is a race condition, there is absolutely no way for us to address this in Dolphin, this has to be addressed by a game patch.</p>
<p>Thankfully, all of this was discovered by <strong>hthh</strong>, who dug into the game's code, <a href="https://bugs.dolphin-emu.org/issues/6752#note-9">isolated the bug</a>, and also provided patches for both titles! This simple patch inserts a flush to the GPU before the index buffer change in the draw call, preventing the issue from ever occuring. And with that, <a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2004">MVP Baseball 2004</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=MVP_Baseball_2005">2005</a> are flicker free!</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-4by3">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/MVPWorking.mp4" type="video/mp4"/>
</video></div>
<figcaption>Even with the fix, this game just wants to flicker so much that the selection bar flashes! But this bit is intended.</figcaption>
</figure>
</div>
<h5 id="fix-monster-hunter-tri-bloom-disabled-patch"><strong>Fix Monster Hunter Tri Bloom Disabled Patch</strong><a class="headerlink" href="#fix-monster-hunter-tri-bloom-disabled-patch" title="Permanent link">¶</a></h5>
<p>So, we can't really explain <em>how</em> this happened. We can only explain <em>why</em> it became an issue more recently. <a href="https://dolphin-emu.org/blog/2019/04/01/the-new-era-of-video-backends/#unified-efb-peekspokescopies">Upon the unification of VideoCommon</a> we finally removed a default setting that partially disabled the bloom effect in <a href="https://wiki.dolphin-emu.org/index.php?title=Monster_Hunter_Tri">Monster Hunter Tri</a> thanks to optimizations and an offset fix. This effect is accomplished in a different way than most games; while the bloom is done on the GPU, the actual check for what gets bloomed and how much happens on the CPU by use of EFB pokes. This looks just fine on hardware or at 1x Native, but when raising the internal resolution in Dolphin, it makes the game look <em>very</em> wrong.</p>
<p><br/></p>
<div style="max-width: 95%; margin: 0 auto;">
<div style="max-width: 32%; min-width:150px; float:left; text-align:center; padding-left: 2%;">
<a style="text-decoration: none;" href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-blockbloom.jpg">
<img style="max-width: 100%; border-style: none; margin-bottom: .5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-blockbloom_thumb.jpg"/>
</a>
<p>By default, this is how Mon Hun Tri looks in Dolphin. The CPU controlled bloom doesn't scale to higher resolutions. Worse yet, it is 1/10 of 1x Native, so it is VERY blocky.</p>
</div>
<div style="max-width: 32%; min-width:150px; float:left; text-align:center; padding-left: 2%;">
<a style="text-decoration: none;" href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-overbloom.jpg">
<img style="max-width: 100%; border-style: none; margin-bottom: .5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-overbloom_thumb.jpg" />
</a>
<p>The only option was to disable CPU EFB access, but you'd get this - overbloom. The game thinks every pixel is "bloomed" and thus, there is no longer a "bloom" at all, just this over brightening. </p>
</div>
<div style="max-width: 32%; min-width:150px; float:left; text-align:center; padding-left: 2%;">
<a style="text-decoration: none;" href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-native.png">
<img style="max-width: 100%; border-style: none; margin-bottom: .5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-native_thumb.jpg" />
</a>
<p>Here is 1x Native, demonstrating the original look of the bloom. ...This game is blurrier than we remembered.</p>
</div>
<br clear="both"/>
</div>
<p><br/></p>
<p>With optimizations and some recent fixes, Dolphin can finally emulate the effect correctly in the latest development builds. However, that's precisely what annoyed users; they preferred disabling this bloom effect and using their own. This wasn't a problem - Dolphin also shipped with a game patch that would disable the bloom. Except, by the time this was actually possible, the game patches <strong>didn't actually work</strong>. For one of these patches, the reason is quite simple. For the other... we, uh... yeah. See if you can spot the problem.</p>
<p><br/>
<strong>PAL</strong></p>
<pre><code>0x00057058:dword:0xC022FFE4
0x0079FF44:dword:0x3F800000
</code></pre>
<p><strong>NTSC</strong></p>
<pre><code>0x04056FF4:dword:0xC022FFE4
0x0479DA84:dword:0x3F800000
</code></pre>
<p><br/></p>
<p>Let's talk about the PAL code first since it actually makes sense. <a href="https://dolphin-emu.org/blog/2016/09/06/booting-the-final-gc-game/">5.0-540</a> and the work surrounding the improvements to memory emulation it brought meant that these addresses wouldn't work. Fixing them was simple, we just needed to make them actually use the GameCube/Wii's virtual memory addresses instead of the physical ones.</p>
<p><br/>
<strong>PAL Fixed</strong></p>
<pre><code>0x80057058:dword:0xC022FFE4
0x8079FF44:dword:0x3F800000
</code></pre>
<p><br/></p>
<p>Now the NTSC code... is an action replay code that got copied into the patches section. It never actually worked. The "04" at the beginning of 0x04056FF4 is not an address, as much as a description of the code saying that it is <em>four</em> bytes. Fixing it was admittedly just as simple though, as the rest of line <em>is</em> the address.</p>
<p><br/></p>
<p><strong>NTSC Fixed</strong></p>
<pre><code>0x80056FF4:dword:0xC022FFE4
0x8079DA84:dword:0x3F800000
</code></pre>
<p><br/></p>
<hr />
<p>Admittedly, Monster Hunter Tri without the bloom at all <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-nobloom.jpg">doesn't look right either</a>. The game was built to use the bloom effect to brighten the image, so without it it looks dark and lifeless. However, the Wii doesn't support HDRI whatsoever, so there's nothing the game is doing that can't be recreated by external post processing software. Thus by disabling the game's bloom entirely, a user can then use ReShade or like injectors to add their own bloom, and recreate the original look of the game at higher resolutions!</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-recreation.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-recreation_thumb.jpg"></a>
<figcaption>With a little bit of work, the original look of the game can now be recreated at higher resolutions! <br/> Click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/monhun-exampleconfig.jpg">HERE</a> for an example config and comparison. </figcaption>
</figure>
</div>
<h4 id="50-12697-add-hotkey-support-to-input-configuration-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12697/">5.0-12697 - Add Hotkey Support to Input Configuration</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-12697-add-hotkey-support-to-input-configuration-by-billiard" title="Permanent link">¶</a></h4>
<p>Dolphin's Advanced Input Configuration Pane is very powerful and allows you to do <em>a lot</em> of crazy things with key and controller combinations. But, using that pane can be quite the <em>pain</em> if you don't know what you're doing. So in order to ease up on the discomfort, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> has expanded Dolphin's standard input configuration dialogue! This means you can now setup button <em>combinations</em> directly in the main configuration page without having to dive into the mass of logic that is advanced configuration.</p>
<div class="media-block wide">
<figure>
<div class="embed-responsive embed-responsive-16by9">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/hotkeysupport.mp4" type="video/mp4"/>
</video></div>
<figcaption>Hotkey mappings can let you do more with fewer keys and buttons!</figcaption>
</figure>
</div>
<p>As an added bonus, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> has added a new set of expressions to handle hotkey modifiers. This makes them display more cleanly and be setup without needing complicated logic. Also note that this can be done with <em>controllers</em> as well, so if you want to map an upward swing to require both a joystick direction and a button, you can!</p>
<h4 id="50-12711-fix-emulated-wii-remote-default-field-of-view-and-change-default-range-by-billiard"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12711/">5.0-12711 - Fix Emulated Wii Remote Default Field of View and Change Default Range</a></strong> by <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong><a class="headerlink" href="#50-12711-fix-emulated-wii-remote-default-field-of-view-and-change-default-range-by-billiard" title="Permanent link">¶</a></h4>
<p>A few things happened over the last few months that led to a rather interesting change. Perhaps the <em>bigger</em> news in all of this is that <strong><a href="https://github.com/Techjar">Techjar</a></strong> added our first <em>built-in</em> controller profile. The profile is specifically for when users connect Wii Remotes with MotionPlus to Dolphin's emulated controller interface. When you connect a real Wii Remote and select this profile, everything will be automatically mapped correctly, including Pointer Simulation so that you can use your real Wii Remote without a sensor bar!</p>
<p>However, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> wasn't entirely happy without how pointer simulation was behaving and began to dig into the Wii Remotes for more answers. However, Dolphin's numbers on the infrared camera seemed to line up with Wiibrew.org and there was nothing to the contrary.</p>
<p><br/>
<blockquote style="font-size:1.2em">The IR camera has an effective field of view is about 33 degrees horizontally and 23 degrees vertically (as measured on one unit).
<footer><a href="https://www.wiibrew.org/wiki/Wiimote#Optical_Characteristics"<cite>WiiBrew.org</cite></a></footer>
</blockquote></p>
<p><br/></p>
<p>Still unhappy with the performance of the emulated pointer, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> remeasured this data from a Real Wii Remote. To his surprise, the numbers actually comes out to <strong>42 degrees horizontally by 31.5 degrees vertically</strong>. Plugging these numbers into gyroscope simulation of infrared made emulated pointer feel much closer to the real thing.</p>
<p>While he was in the neighborhood, <strong><a href="https://github.com/jordan-woyak">Billiard</a></strong> also made a few other adjustments to the defaults. One of which was was a constant problem with emulated Wii Remotes in general...</p>
<div class="media-block full-width">
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/WiiRemoteFOV-broken.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/WiiRemoteFOV-broken_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>Dolphin's Default Parameters for emulated Wii Remotes couldn't reach the edges of the screen in some titles...</figcaption>
</figure>
<figure class="col-sm-6">
<div class="embed-responsive embed-responsive-16by9">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/WiiRemoteFOV-working.mp4">
<video autoplay muted loop playsinline>
<source src="https://dolphin-emu.org/m/user/blog/progress-report/2020-august/WiiRemoteFOV-working_thumb.mp4" type="video/mp4"/>
</video></div></a>
<figcaption>But now they should work for most titles.</figcaption>
</figure>
</div>
<p>In order to make sure Wii Remotes can reach all of the screen, the default values for how far the Wii Remote Pointer can go were adjusted. This should make it so most, if not all, workable with emulated pointer without further adjustment.</p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2020-07-01&to=2020-09-30&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-12251/">5.0-12251</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-12716/">5.0-12716</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>
Dolphin Progress Report: May and June 2020
2020-07-05T09:49:18+00:002020-10-01T05:15:45.347074+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2020/07/05/dolphin-progress-report-may-and-june-2020/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/progressreportheader-June2020.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/progressreportheader-June2020mini.jpg" />
</header>
<p>We've got a lot to get through the past two months. Headlining it all is that we're happy to announce support for a new compressed disc format developed specifically for Dolphin: RVZ. This lossless format allows for near top of the line game compression without compromising the integrity of ISOs, while also maintaining performance and stability. But what good is compression if emulation isn't up to snuff? The past two months have been chock-full of emulation and usability fixes for both Android and Desktop Dolphin! There's a little bit of everything, from graphics emulation fixes, memory card and savestate compatibility changes, to obscure features like being able to report thermal data to games and homebrew!</p>
<p>Rather than delaying any longer, let's just dive in now! Please please enjoy the May and June Dolphin Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes">Notable Changes<a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-12071-androidgles-fix-efb-access-from-cpu-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12071/">5.0-12071 - Android/GLES - Fix EFB Access From CPU</a></strong> by <strong><a href="https://github.com/stenzek">Stenzek</a></strong><a class="headerlink" href="#50-12071-androidgles-fix-efb-access-from-cpu-by-stenzek" title="Permanent link">¶</a></h4>
<p>When using Dolphin's OpenGLES backend on <em>most</em> Android devices, a lot of games behave poorly when trying to read the screen with EFB peeks. By checking what is on the screen, games can accomplish all kinds of visual effects or even use the data for gameplay! <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">Wind Waker</a> uses EFB Access in order to tell when the sun is or is not visible in order to do a shine effect and darken everything else on the screen. <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> goes a step further, with similar sun effects <em>and</em> gameplay features like Pullstars and collecting Starbits that rely on knowing what's on screen. All of this was broken in Dolphin's OpenGL backend in GLES mode! After doing some debugging, we discovered that glReadPixels() with depth formats is not supported in GLES, meaning that these reads were being <strong>completely skipped</strong>. While this meant there was no performance hit to enabling EFB Access from CPU on OpenGLES, it also meant these effects would <strong>completely fail</strong>.</p>
<p>In order to fix this, <strong><a href="https://github.com/stenzek">Stenzek</a></strong> created a fallback for this situation that copies into color formats instead of depth formats. This allows EFB Access from CPU to finally work correctly on GLES devices.</p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/windwakersun-broken.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/windwakersun-broken_thumb.jpg" /></a><figcaption>On mobile GLES drivers, the sun's shine effect never triggered. It's just a boring ball in the sky.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/windwakersun-working.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/windwakersun-working_thumb.jpg" /></a><figcaption>But now the effect works correctly!</figcaption>
</figure>
</div></div>
<p><strong>NOTE</strong>: Because <em>EFB Access from CPU</em> is working correctly in some games, that means there is now a performance impact to enabling the feature in those games. Users that were used to <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy">Super Mario Galaxy</a> running faster on OpenGL than Vulkan will now see that performance should be much closer between the two backends. This loss in performance <strong>is not a bug</strong>! A <strong>crucial</strong> part of emulation that is required for these games to run correctly was being completely skipped! Do not report performance losses in games that require this feature. Thank you.</p>
<h4 id="50-12078-adreno-fix-invalid-readback-of-efb-d24s8-depth-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12078/">5.0-12078 - Adreno: Fix invalid readback of EFB D24S8 depth</a></strong> by <strong><a href="https://github.com/stenzek">Stenzek</a></strong><a class="headerlink" href="#50-12078-adreno-fix-invalid-readback-of-efb-d24s8-depth-by-stenzek" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; width:42px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>The name of <strong><a href="https://github.com/stenzek">Stenzek</a></strong>'s branch should say everything about how we got to this point: "adreno-more-like-brokenreno". A work-around for <em>another</em> adreno bug has caused us to run into more issues. The problem was that attempting to create savestates in Vulkan would crash Dolphin due to an assert in the driver when reading back D24S8 depth. In order to work around this, Dolphin now uses R32F on afflicted devices instead. This allows savestates to function on Vulkan on Adreno devices.</p>
<h4 id="50-12080-use-correct-window-surface-for-wii-remote-mouse-cursor-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12080/">5.0-12080 - Use Correct Window Surface for Wii Remote Mouse Cursor</a></strong> by <strong><a href="https://github.com/stenzek">Stenzek</a></strong><a class="headerlink" href="#50-12080-use-correct-window-surface-for-wii-remote-mouse-cursor-by-stenzek" title="Permanent link">¶</a></h4>
<p><strong><a href="https://github.com/stenzek">Stenzek</a></strong> strikes yet again, this time fixing up an unfortunate regression that turned up a couple months ago. Changes to Dolphin's window creation procedure was causing Dolphin to use the wrong window surface when trying to handle a user's mouse cursor for infrared. Instead of using the <em>game</em> window, Dolphin was instead using the gamelist! Whoops.</p>
<h4 id="50-12090-and-50-12099-add-option-to-disable-sd-card-writes-by-techjar-and-ebola16"><strong>5.0-12090</strong> and <strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12099/">5.0-12099</a></strong> - <strong>Add Option to Disable SD Card Writes</strong> by <strong><a href="https://github.com/techjar">techjar</a></strong> and <strong><a href="https://github.com/Ebola16">Ebola16</a></strong><a class="headerlink" href="#50-12090-and-50-12099-add-option-to-disable-sd-card-writes-by-techjar-and-ebola16" title="Permanent link">¶</a></h4>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Brawl">Super Smash Bros. Brawl</a> users commonly use SD card data to load up total game conversion mods. However, for netplay to succeed, the users' SD cards needed to <strong>perfectly match</strong>. Unfortunately, the Wii was not designed at all to maintain SD Card determinism; if a game so much as <em>reads</em> the SD card, the contents would be ever so slightly altered. Even these tiny changes are enough to cause desyncs in games on netplay, requiring resharing and resyncing of SD cards. This can cause a lot of headaches, especially when some Brawl mods use <strong>2GB</strong> SD cards! Fortunately, there is now a solution. In order to prevent small SD card changes like this, you can now lock your SD card in Dolphin's Wii Settings page. This should make syncing up and playing games that rely on SD cards much more predictable in the future. If you're unsure if your SD cards match, make sure to compare the hashes in the netplay window before playing!</p>
<div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/sdcardsettings.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/sdcardsettings_thumb.png"></a>
<figcaption>Blocking SD card writes can make setting up netplay much easier in games and mods that need SD card data to be identical.</figcaption>
</figure>
</div>
<p>The reason that this is two commits is that <strong><a href="https://github.com/Ebola16">Ebola16</a></strong> implemented this into Dolphin's Android GUI. They've also been implementing tons of other missing features from the desktop version of Dolphin into the Android touch and TV. Individually, each change is rather minor, but they've slowly been making the Android version of Dolphin easier to use and more powerful all at the same time. Also 5.0-12090 failed to build, hence the missing link.</p>
<h4 id="50-12151-basic-support-for-thermal-sprs-by-delroth"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12151">5.0-12151 - Basic Support for Thermal SPRs</a></strong> by <strong><a href="https://github.com/delroth">delroth</a></strong><a class="headerlink" href="#50-12151-basic-support-for-thermal-sprs-by-delroth" title="Permanent link">¶</a></h4>
<p>It came to our attention that the latest version of <a href="https://github.com/emukidid/swiss-gc">Swiss-GC</a> was hanging on Dolphin. Considering the popularity of <a href="https://github.com/emukidid/swiss-gc">Swiss-GC</a> among our users, it was of the highest priority to get this fixed. You didn't buy that, huh? Well, actually, the reason that this got fixed so quickly is that <a href="https://github.com/emukidid/swiss-gc">Swiss-GC</a> is an open source app for the GameCube with developers that are close to our community. They not only provided us data on what registers they were newly using, but we could <a href="https://github.com/emukidid/swiss-gc/commit/12abb72c349b174363483494a402a74c6154d264">directly look at their code to see what it was doing.</a> After dealing with so many games that are black boxes, it's refreshing to work on something where we actually know what the software is trying to do.</p>
<p><strong><a href="https://github.com/extrems">Extrems</a></strong> documentation on the registers and <strong><a href="https://github.com/delroth">delroth</a></strong> implemented basic support to report sane data so that Swiss-GC would no longer hang.</p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/swissgc.png">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/swissgc_thumb.png"></a>
<figcaption>You're as cold as ice!... wait.</figcaption>
</figure>
</div>
<h4 id="50-12188-support-for-rvz-and-wia-disc-formats-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12188/">5.0-12188 - Support for RVZ and WIA disc formats</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-12188-support-for-rvz-and-wia-disc-formats-by-josjuice" title="Permanent link">¶</a></h4>
<div style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:25%; min-width:150px; float:right; text-align:center;">
<img style="max-width: 100%; margin-bottom:.5em;" src="https://dolphin-emu.org/m/user/blog/progress-report/2016-february/discicon.png">
</div>
<p>Preservation is one of the core benefits of emulation. There will come a day when the last of the Wii's online services are a distant memory, there isn't a working Wii disc drive to be found, and Wii discs are most useful as coasters. All that will be left of these games and their experiences will be the digital backups made in this era, when Wii hardware and discs are still functional and available. Unfortunately, many users turn to mangling their dumps in an effort to conserve limited hard drive space. These dumps may work in the short-term, but lack important files like Wii Update data and IOSes that may be necessary in the future to use various features of the game when NUS no longer functions.</p>
<p>That's why we're happy to introduce a new high compression storage format <em>designed</em> for Dolphin. Built off of Wiimm's WIA format, RVZ is an evolution of that format designed specifically for realtime performance and complete preservation of all disc data while maintaining as high of compression as possible. Unlike WIA and NKit files, which each have their own issues when used directly, RVZ circumvents almost every issue that plague high compression formats. It's designed to have no performance impact when used in Dolphin as long as you have a CPU with more than two cores, which is a huge bonus when other compressed formats result in frustrating stutters during loads that don't happen on uncompressed ISOs. RVZ discs are also directly compatible with ISOs even in situations that require perfect determinism like netplay and movie recordings.</p>
<h5 id="why-lossless-matters"><strong>Why Lossless Matters</strong><a class="headerlink" href="#why-lossless-matters" title="Permanent link">¶</a></h5>
<p>You might be wondering why lossless matters so much. Why does preserving things such as update data and garbage data actually matter? There are multiple reasons that we can quickly go through.</p>
<ul>
<li>Online services like NUS for Wii will not exist forever. Update files on discs may be the only way to access certain features on games that rely on various IOS features.</li>
<li>Inaccurate dumps can cause all kinds of unintended issues. RVZ can be directly verified against ISOs in Dolphin.</li>
<li>Some games may accidentally read data that they do not intend to, meaning that garbage data can actually come into play.</li>
<li>Losslessly compressed discs can be converted back into clean, verifiable ISO files.</li>
<li>Verifiable, Lossless dumps make it so our support staff <em>knows</em> that the disc image is not the problem when providing assistance.</li>
</ul>
<p>By storing Wii data partitions unencrypted, RVZ is able to compress and preserve every data partition without a huge penalty to space. RVZ can even compress garbage data down to almost nothing!</p>
<p>Because RVZ is a brand new format, it isn't well supported in other programs. Thus, to ease the process, we've added support directly to Dolphin to convert to RVZ. Unfortunately, RVZ files are not compatible with Dolphin builds older than 5.0-12188, so going back to prior versions will require converting games back to ISOs beforehand. However, you can do that directly in Dolphin's gamelist, so it isn't too terribly painful.</p>
<h5 id="format-overview"><strong>Format Overview</strong><a class="headerlink" href="#format-overview" title="Permanent link">¶</a></h5>
<p><center>
<div style="max-width: 90%; overflow-x:auto;">
<table id="ProgressReportChart">
<!-- disc format --> <br />
<tr>
<th></th>
<th>ISO</th>
<th>GCZ</th>
<th>WIA</th>
<th>RVZ</th>
<th>NKit</th>
</tr>
<!-- First Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Supports Compression</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<!-- Second Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Can Compress Encrypted Wii Data</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<!-- Third Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Can Compress Garbage Data</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<!-- Fourth Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Correctly Emulated Load Times</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
</tr>
<!-- Fifth Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Good Real-time Performance</td>
<td>Yes</td>
<td>Yes</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
</table>
</div>
</center></p>
<h5 id="space-comparison"><strong>Space Comparison</strong><a class="headerlink" href="#space-comparison" title="Permanent link">¶</a></h5>
<p>When comparing a bunch of formats, inevitably you get to the point where you just have to crunch the raw numbers. There are a few caveats we have to get to before going over what these numbers mean and why. The ratio of garbage data to real game data varies greatly per game, and because garbage data compresses much better than real data, the exact savings is highly variable. It's completely normal to see a game drop from 4GB to 300MB, but it's also normal to see a game nearly unaffected by compression. A famous example of this is <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess_(Wii)">Twilight Princess Wii</a> - as a title originally developed for the GameCube and its smaller discs, the Wii version is mostly empty, allowing it compress at a very good 3.8:1 ratio. </p>
<p>We also must note what settings we used with each of these formats. We could easily make RVZ look fantastic by simply comparing all of these formats in a <em>lossless</em> test. However, that's not how many users used these formats and it would be incredibly misleading. As such, we used the typical settings for GCZ and WIA that users would use in order to save space. If anything, this shows how little is actually sacrificed to use RVZ over a lossy format.</p>
<p><br/>
<center>
<div style="max-width: 90%; overflow-x:auto;">
<table id="ProgressReportChart">
<!-- disc format --> <br />
<tr>
<th></th>
<th>ISO - Lossless</th>
<th>GCZ - Scrubbed</th>
<th>WIA - Scrubbed</th>
<th>RVZ - Lossless</th>
</tr>
<!-- First Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Animal Crossing</td>
<td>1.36 GiB</td>
<td>18.93 MiB</td>
<td>28.38 MiB</td>
<td>19.17 MiB</td>
</tr>
<!-- Second Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Twilight Princess Wii</td>
<td>4.38 GiB</td>
<td>1.14 GiB</td>
<td>956.75 MiB</td>
<td>1.00 GiB</td>
</tr>
<!-- Third Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Luigi's Mansion</td>
<td>1.36 GiB</td>
<td>155.42 MiB</td>
<td>128.58 MiB</td>
<td>155.66 MiB</td>
</tr>
<!-- Fourth Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Fortune Street</td>
<td>4.38 GiB</td>
<td>939.99 MiB</td>
<td>909.94 MiB</td>
<td>675.67 MiB</td>
<!-- Fifth Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Metroid Prime Trilogy</td>
<td>7.93 GiB</td>
<td>7.60 GiB</td>
<td>6.31GiB</td>
<td>6.69 GiB</td>
</tr>
<!-- Sixth Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Rogue Squadron 3</td>
<td>1.36 GiB</td>
<td>1.23 GiB</td>
<td>1.18 GiB</td>
<td>1.24 GiB</td>
</tr>
<!-- Seventh Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Smurfs Dance Party</td>
<td>4.38 GiB</td>
<td>3.24 GiB</td>
<td>3.00 GiB</td>
<td>3.04 GiB</td>
</tr>
</table>
</div>
</center><br/></p>
<h5 id="about-the-nkit-format"><strong>About the NKit format</strong><a class="headerlink" href="#about-the-nkit-format" title="Permanent link">¶</a></h5>
<p>One format we didn't compare to in those charts is NKit. It's just a very hard format to compare against thanks to crazy features and how it will happily split update data and reuse one copy among many games. When doing initial testing, it was very hard to get a grasp of exactly how much it saved. While on an individual basis, it appeared that RVZ was superior to NKit in terms of compression, as you compress more games, because of its ability to reuse update partitions it would actually gain an advantage. This makes it a fantastic choice for the long-term storage of large collections even if it appears as though it loses out on a game by game basis.</p>
<p><br/>
<center>
<div style="max-width: 90%; overflow-x:auto;">
<table id="ProgressReportChart">
<!-- disc format --> <br />
<tr>
<th></th>
<th>RVZ (128 KiB, 22)</th>
<th>.nkit.gcz (NKit defaults, 16KiB)</th>
</tr>
<!-- First Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">Four Sword Adventures</td>
<td>412.87 MiB</td>
<td>448.80 MiB</td>
</tr>
<!-- Second Row -->
<tr>
<td style="background-color:#DDD; text-align: right; color: black; font-weight: bold;">New Super Mario Bros. Wii</td>
<td>423.64 MiB</td>
<td>421.93 MiB</td>
</tr>
</table>
</div>
<br/><p>All games are PAL. Update partitions not removed.</p>
</center><br/></p>
<p>Unfortunately, as great as NKit is for long-term storage, it tends to be just as problematic for emulation. NKit actually shifts file locations around on the disc, moving them to earlier in the file, which would be toward the inside of a disc. This normally wouldn't seem like a problem, but <a href="https://dolphin-emu.org/blog/2014/12/01/dolphin-progress-report-november-2014/#40-4222-support-constant-angular-velocity-for-disc-reads-by-josjuice">Dolphins emulates CAV</a>, and moving files toward the inside of the disc means that less data is read per rotation. The end result is that loadtimes are sometimes increased by 10 to even 20%! Different loadtimes means that features like netplay won't work between NKit discs and dumps that don't modify file locations.</p>
<p>But, beyond those minor gripes, NKit has another problem that makes it much more problematic: some games just really hate it. We are aware of at least two games that simply crash in the NKit format. One unavoidable crash is present in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a> and we've already seen dozens of users confused as to what is going wrong. <a href="https://wiki.dolphin-emu.org/index.php?title=Namco_Museum">Namco Museum</a> (specifically the Galaga Arrangement) <em>also</em> crashes, but that crash can be prevented by converting to Nkit with safer settings.</p>
<p>Regardless of these problems, when used as a <strong>long-term</strong> storage format that isn't going to be used with Dolphin, NKit is fantastic. However, if you want a compressed format to use in Dolphin, use RVZ. When used on a game by game basis, both NKit and RVZ will result in very similar file sizes for losslessly compressed discs.</p>
<h4 id="50-12202-fix-memory-card-issues-with-savestates-by-admiralcurtiss"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12202">5.0-12202 - Fix Memory Card Issues with Savestates</a></strong> by <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong><a class="headerlink" href="#50-12202-fix-memory-card-issues-with-savestates-by-admiralcurtiss" title="Permanent link">¶</a></h4>
<p>The advent of the <a href="https://dolphin-emu.org/blog/2014/06/30/dolphin-progress-report-june-2014/#40-1939-ability-to-use-folders-as-memory-cards-by-lpfaint99">GCI folder</a> option brought convenient save management for large GameCube game collections. It allowed users to bypass annoying file limits present in standard memory card blobs while giving instant access to copy, delete, or modify saves directly in your favorite file manager. Everything seemed fine, but upon promoting and recommending GCI Folders, we started to see a prominent, but confusing issue. Sometimes games would simply start refusing to save. While we didn't know exactly what was causing the issue, it became clear early on that savestates had <em>something to do with it</em>. And, once the game refused to save on that savestate, you were essentially permanently stuck and could no longer use in-game saves unless you restarted from your most recent in-game save.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/ttydsave-broken.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/ttydsave-broken_thumb.jpg"></a>
<figcaption>Many games displayed this message to users using savestates</figcaption>
</figure>
</div>
<p>After cutting his teeth on the Memory Card Manager, <strong><a href="https://github.com/AdmiralCurtiss">AdmiralCurtiss</a></strong> had some idea of what was going on and even provided an <a href="https://github.com/dolphin-emu/dolphin/pull/8476">earlier</a> attempt. One of the important things he provided were steps and information for <em>why</em> this was happening.</p>
<ol>
<li>Create a savestate.</li>
<li>End Emulation.</li>
<li>Open the original game.</li>
<li>Load savestate.</li>
<li>Attempt to save and watch it fail.</li>
</ol>
<p>However, despite having concrete steps to reproduce the issue, and even a potential fix, we were alarmed that all known solutions created the possibility that savestates could overwrite saves of other games, causing users to lose tons of progress. Fortunately, we now have a proper, safe solution. Dolphin now stores the memory card header in EXI_Channel to ensure the same game session is preserved across savestates. This means the game won't think that you're saving to a different memory card, even if you've stopped Dolphin, modified the memcard, and reloaded your savestate. And of course, this has a number of protections so there is no chance that savestates will overwrite the save data of other games.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/ttydsave-working.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/ttydsave-working_thumb.jpg"></a>
<figcaption>Now you can savestate with peace of mind.</figcaption>
</figure>
</div>
<p><strong>Note:</strong> These fixes do not affect <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_Colosseum">Pokemon Colosseum</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=Pok%C3%A9mon_XD:_Gale_of_Darkness">Pokemon XD</a>'s save issues regarding savestates. They have purposeful memory card checks to prevent the duping of Pokemon. Unlike the previous problem, which was more of an emulation oversight, this one is something that should be solved through a game patch. Currently no one is investigating this issue and you should be wary of using savestates with these games. If someone does write a patch or a cheat for this issue, we will be happy to include it with the game's INI file for easy access to users.</p>
<h4 id="50-12226-allow-tweaking-free-look-cameras-field-of-view-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12226">5.0-12226 - Allow Tweaking Free Look Camera's Field of View</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-12226-allow-tweaking-free-look-cameras-field-of-view-by-iwubcode" title="Permanent link">¶</a></h4>
<p>Free Look is a longstanding Dolphin feature that allows the user to reposition the camera in a game however they so please, with abilities far far beyond what game cameras can provide. This allows for exploring blocked off areas, advanced game photography, and more. </p>
<div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/samusfreelook.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/samusfreelook_thumb.jpg"></a>
<figcaption>Did you know that HUDs in the Prime series are all 3D and even in worldspace? Free Look answers questions like this easily!</figcaption>
</figure>
</div>
<p>For the past couple of months <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has been working on an ambitious personal project to improve and expand the Free Look feature set. Over the past two months they added <a href="https://dolphin-emu.org/download/dev/cea779cc844ffe1a470b174bba7198b27d1e5d6a/">new experimental camera modes</a> and <a href="https://dolphin-emu.org/download/dev/d6341c4117d59565b3bc42264d6fa5ba7e796526/">fixed several</a> <a href="https://dolphin-emu.org/download/dev/ef464effaf7cd36420b4a784b9e3202b5989d1c9/">Free Look bugs</a>, and this is only the beginning. The biggest of the changes so far is a new option to allow adjusting the field of view of the Free Look camera. With this new option, all manner of new shots and perspectives that was impossible to do before are now within our grasps!</p>
<div class="media-block wider">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/June2020-headerbg_thumb.jpg">
<figcaption>Photos like this were impossible before this change! <br/>To see the full 16x native image, <a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/June2020-headerbg.jpg">click here</a>. </figcaption>
</figure>
</div>
<p>In addition to game photography, this can also serve a gameplay purpose as well. If you don't like the field of view a game uses and want to go wider or tighter, this new option will allow you to change it! </p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/fovbeyondgoodandevil-normal.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/fovbeyondgoodandevil-normal_thumb.jpg" /></a>
<figcaption>Ever wish a game's camera was just a bit wider?</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/fovbeyondgoodandevil-wide.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/fovbeyondgoodandevil-wide_thumb.jpg" /></a>
<figcaption>Now you can adjust it!</figcaption>
</figure>
</div></div>
<p>This option can be found in Graphics > Advanced tab, or field of view can be adjusted via hotkeys (default is shift+mousewheel). This is only the beginning of the crazy things <strong><a href="https://github.com/iwubcode">iwubcode</a></strong> has planned, so hopefully Free Look will continue to get new features in the coming months.</p>
<h4 id="50-12233-broadband-adapter-support-for-xlink-kai-by-crunchbite"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-12233">5.0-12233 - Broadband Adapter Support for XLink Kai</a></strong> by <strong><a href="https://github.com/CrunchBite">CrunchBite</a></strong><a class="headerlink" href="#50-12233-broadband-adapter-support-for-xlink-kai-by-crunchbite" title="Permanent link">¶</a></h4>
<p>This feature comes directly from the XLink Kai developer <strong><a href="https://github.com/CrunchBite">CrunchBite</a></strong>. If you aren't familiar with it, XLink Kai is a service designed to allow tunneling of LAN games across many consoles from old to new. In this case, they've implemented a BBA backend for Dolphin that allows users to play BBA games locally and online through their service. You can even play with other players so long as you're within as ping tolerance for the selected game. For <a href="https://wiki.dolphin-emu.org/index.php?title=Mario_Kart:_Double_Dash%E2%80%BC">Mario Kart: Double Dash!!</a> it can actually be stable with two players up to around ~60ms of ping, which does give it some range. Other games have their own ping tolerances and they will perform best over LAN.</p>
<p>The biggest benefit to XLink Kai support is that you don't need to go through the setup and downsides of using a TAP adapter on Windows. On Windows, not only is setting up TAP adapters and getting Dolphin to connect to them a rather treacherous task, latency limitations would often cause games to lag and disconnect even when both instances of Dolphin are running from the same machine. There wasn't really anything that could be done, the few people that did rely on BBA support in Dolphin would avoid Windows for Linux just to make things playable. Windows users no longer need to feel like third class citizens in the world of BBA, as this problem is completely non-existent with XLink-Kai. It does not rely on TAP adapters and instead manually injects cleaner ethernet frames than the game could have ever imagined.</p>
<div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/BBA.jpg">
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-june/BBA_thumb.jpg"></a>
<figcaption>Do you have eight friends obsessed with Mario Kart: Double Dash!!? If you do, this is the feature for you!</figcaption>
</figure>
</div>
<p>Using the XLink Kai service can be fairly daunting at first, so we suggest carefully following their guides on <a href="https://www.teamxlink.co.uk/wiki/Dolphin_Gamecube_XLink_BBA_Tutorial">their website</a> to ensure that things are setup correctly and you know the limitations of the service. Also please contact them directly for any support issues regarding the service; our forum helpers are ill equipped to help with XLink Kai.</p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2020-05-01&to=2020-06-30&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-11993/">5.0-11993</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-12247/">5.0-12247</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
<!-- Chart Style Below -->
#ProgressReportChart {
font-family: "Trebuchet MS", Arial, Helvetica, sans-serif;
border-collapse: collapse;
max-width: 90%;
}
#ProgressReportChart td, #ProgressReportChart th {
border: 1px solid #ddd;
padding: 12px;
}
#ProgressReportChart tr:nth-child(odd){background-color: #f2f2f2;}
#ProgressReportChart th {
padding-top: 12px;
padding-bottom: 12px;
text-align: center;
background-color: #DDD;
color: black;
</style>
Dolphin Progress Report: April 2020
2020-05-05T07:35:23+00:002020-05-05T07:35:57.558230+00:00MayImilaehttps://dolphin-emu.org/blog/authors/MayImilae/https://dolphin-emu.org/blog/2020/05/05/dolphin-progress-report-april-2020/
<header>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/progressreportheader-April2020.jpg" />
<img class="mini" src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/progressreportheader-April2020mini.jpg" />
</header>
<p>It feels like it's been some time since we've had actually had a <em>monthly</em> Progress Report. This is because there haven't been as many major changes landing, making it harder to fill out a substantial article. That isn't to say that things have slowed down, these smaller changes increase the quality of life for users and add up, especially when jumping from older builds to the latest. However, these changes are a lot harder to show and feature in a Progress Report compared to things that actually affect the core emulation and games. This time around, we had <em>more than enough</em> on our plate to write about, including support in the latest builds for a very interesting game: <strong>The Metroid Prime 3's E3 2006 Beta</strong>.</p>
<p>But before we get to the new changes, we need to cover something we missed last month. So, without further delay, please enjoy the <em>mostly</em> April Progress Report!</p>
<p><a id="cuthere"></a></p>
<h3 id="notable-changes">Notable Changes<a class="headerlink" href="#notable-changes" title="Permanent link">¶</a></h3>
<h4 id="50-11744-videocommon-allow-texture-folders-to-be-determined-by-a-txt-by-iwubcode"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11744/">5.0-11744 - VideoCommon: Allow texture folders to be determined by a <gameid>.txt</a></strong> by <strong><a href="https://github.com/iwubcode">iwubcode</a></strong><a class="headerlink" href="#50-11744-videocommon-allow-texture-folders-to-be-determined-by-a-txt-by-iwubcode" title="Permanent link">¶</a></h4>
<p>In the chaos of the input changes last month, we managed to miss a notable change regarding custom textures. Whoops. So here's a little something from March!</p>
<p><a href="https://wiki.dolphin-emu.org/index.php?title=GameIDs">GameIDs</a> are the unique codes that Nintendo used to catalog and keep track of games, and they are very important to the GameCube and Wii. For instance, when a Wii console is loading the North American version of <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_Twilight_Princess_(Wii)">Twilight Princess Wii</a>, the console doesn't know or care about the game's name, the only thing it is aware of is that it is loading RZDE01. Since Nintendo went out of their way to create a unique identifier code for each version of each game, Dolphin heavily relies on GameIDs throughout its code. This includes our custom texture loader especially. Within our Load > Texture folder, textures to be loaded must be sorted into folders with either the first three or all six characters of the GameID, otherwise Dolphin will ignore them. This way we know exactly what files belong to which game and everything works as expected.</p>
<p>While this worked well for many years, there was room for improvement. One or two texture packs in the Load > Texture folder are very easy to indentify, but that clarity is very quickly lost as more packs are added. They all just start looking the same after a while. Can you remember WPJEJW from WCKJWN, or SOBD7K from SO3EE9? Even our long term developers and testers would have to look those up!</p>
<p><div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customtextures-before.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customtextures-before_thumb.png"></a>
<figcaption>This is a fairly tame example of a custom texture folder. How many games can you recognize?</figcaption>
</figure>
</div></p>
<p>Annoyed with the sea of GameIDs, <a href="https://github.com/iwubcode">iwubcode</a> has changed our custom texture loading to allow for a descriptor file. Simply by placing a text file with its name set to the GameID of the game within the texture pack's folder, Dolphin can now identify the contents of the folder regardless of the folder's name! With this, you can name and organize your Load > Texture directory so all of your custom texture packs are nice and neat.</p>
<p><div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customtextures-after.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customtextures-after_thumb.png"></a>
<figcaption>Now it is much easier to read!</figcaption>
</figure>
</div></p>
<p>For those wondering, if you want to use two texture packs for one game, you can. For any textures that they both try to change, the last one loaded will override the previous versions of that texture. The folders are loaded in alphabetical order. </p>
<h4 id="50-11838-fix-wii-homebrew-hang-on-netplay-by-techjar"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11838/">5.0-11838 - Fix Wii Homebrew Hang on Netplay</a></strong> by <strong><a href="https://github.com/techjar">Techjar</a></strong><a class="headerlink" href="#50-11838-fix-wii-homebrew-hang-on-netplay-by-techjar" title="Permanent link">¶</a></h4>
<p>Homebrew on Netplay may sound like an <em>incredibly</em> niche use of Dolphin, but it's actually one of netplay's most popular usecases! Why? Well, it's because many <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Smash_Bros._Brawl">Super Smash Bros. Brawl</a> mods use homebrew, such as Gecko OS, paired with SD cards packed with codes and other assets to transform the base game without needing to modify the original dump! With some of these mods having competitive scenes, Dolphin Netplay can be a useful tool for training and practice.</p>
<p><div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/projectm.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/projectm_thumb.jpg"></a>
<figcaption>Super Smash Bros. Brawl is a major hub of both Wii Game Modding and Dolphin Netplay</figcaption>
</figure>
</div></p>
<p>Unfortunately, an oversight in Dolphin's Wii USB emulation caused a hang when booting Gecko OS and other Wii Homebrew in Dolphin. The cause of this is that most of Dolphin's USB emulation is disabled in Netplay (and TASing) in order to keep things deterministic, and Dolphin would attempt to initialize it anyway! Thankfully, once the issue was properly bisected, <strong><a href="https://github.com/techjar">Techjar</a></strong> quickly rectified the issue and now these mods can once again boot in netplay.</p>
<h4 id="50-11858-dolphinqt-dont-overwrite-8x-ir-scale-in-ini-add-maximum-internal-res-option-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11858/">5.0-11858 - DolphinQt: Don't overwrite >8x IR scale in ini, add maximum internal res option</a></strong> by <strong><a href="https://github.com/stenzek">Stenzek</a></strong><a class="headerlink" href="#50-11858-dolphinqt-dont-overwrite-8x-ir-scale-in-ini-add-maximum-internal-res-option-by-stenzek" title="Permanent link">¶</a></h4>
<p>Dolphin is a project that sees use from a wide variety of users. We want to make sure everyone has a good experience, but many of those users desires may not only not overlap, but may even conflict with one another. A casual user looking to plug and play their favorite game will want a very simple, easy to use emulator, while an advanced user looking to exploit their powerful hardware for all it can do will want a wide breath of features that allow them to enhance and fine tune their experience. To handle this, we carefully balance our different user needs to apply to as many users as possible, then have more advanced features hidden for those that need them. Our internal resolution selection is a perfect example of this. Right now, our UI only exposes up to 8x Native (5120x4224). According to the <a href="https://store.steampowered.com/hwsurvey/">Steam Hardware Survey</a> as of this writing, that will cover <strong>more than 98% of users</strong>. This minimizes our exposed options, prevents people who may not know what the option does from potentially crashing their graphics drivers, and allows basically everyone to meet or exceed the maximum resolution of their display.</p>
<p>But of course, there is still the small percentage of users with incredibly insane setups that go well beyond the bulk of our userbase. For that tiny group of users, we allow our INIs to set the internal resolution to go <em>as high as they want.</em> The only limiting factor is the hard limits of your graphics card! </p>
<p><div class="media-block narrower">
<figure>
<img src="https://dolphin-emu.org/m/user/blog/progress-report/2016-november/windwaker35xnative_thumb.jpg">
<figcaption><bold>WARNING</bold>, the fullsize image is 23164x18480 (35x native) and can <em>easily</em> overload browers. If you dare, click <a href="https://dolphin-emu.org/m/user/blog/progress-report/2016-november/windwaker35xnative.jpg">here</a> to view it in full size.</figcaption>
</figure>
</div></p>
<p>Unfortunately, as a very advanced feature for very very few users, time was not kind to this feature. Previously, in WX, if a custom resolution is configured in the GameINI, it appears as "Custom" in the GUI. When we moved to Qt this was never recreated, so if the user configured a greater than 8x native internal resolution via INI and then looked at the Graphics > Enhancement tab, internal resolution would just appear blank. To make this worse, upon loading that blank value, Qt thinks its a new value and writes -1 into GFX.INI for internal resolution. That is not an accepted Internal Resolution, so as long as -1 remains within the INI, Dolphin will crash any time a game is launched. This created a situation where if a user wants to regularly use a resolution higher than 8x native, they had to NEVER look at the Enhancements tab. If they did, they would have to go back into the INIs and reconfigure everything. This is <em>terrible</em> UX. However, this feature is so niche we didn't even notice the issue for years, and we never traced this bug to the Qt move until doing testing <em>for this very article.</em> </p>
<div class="media-block full-width">
<div class="row more-padding">
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-wx.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-wx_thumb2.png" /></a>
<figcaption>In WX, at higher than 8x the Internal Resolution would appear as "Custom" and be stable.</figcaption>
</figure>
<figure class="col-sm-6">
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-qt.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-qt_thumb2.png" /></a>
<figcaption>But Qt would display it as blank and write -1 to GFX.ini.</figcaption>
</figure>
</div></div>
<p><div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-qtcrash.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-qtcrash.png"></a>
<figcaption>With Internal Resolution set to -1, attempting to start a game will crash Dolphin.</figcaption>
</figure>
</div></p>
<p>8k (7680x4320) requires a 12x native internal resolution to fill, so when MayImilae got a shiny used 8k display, she ran headfirst into this issue. Fixing this without over complicating the GUI <em>or</em> exposing potentially dangerous settings to general users was a problem, so a plan was devised with <a href="https://github.com/stenzek">Stenzek</a> to build a new, better way to handle this scenario. Now, any internal resolution set in GFX.ini (positive values only) will be exposed within the GUI, so there is no longer any blank slots and no writing -1 to the INI. Problem solved! But their plan went a step further, and added a new, INI only setting called <em>MaxInternalResolution</em>. This "meta-setting" controls the maximum exposed internal resolution in our UI. So for the few users with 6k or 8k displays, you can now make your display resolution appear in the GUI and switch between them as conveniently as any other setting! </p>
<p><div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-newqt.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/customresolution-newqt_thumb.png"></a>
<figcaption>8k users rejoice! All three of you.</figcaption>
</figure>
</div></p>
<p>Combined with the bug fix, this makes using Dolphin with an unusually high resolution display MUCH more pleasant to use!</p>
<p><em>Note: Please remember that internal resolution does not equal SSAA. Dolphin does not have the filtering that SSAA has, so setting the internal resolution well beyond your display's resolution will create <strong>more</strong> aliasing, not less. For best results, please set the internal resolution to the maximum resolution of your display and then add MSAA or SSAA. You should only go beyond the maximum internal resolution of your display for specific situations, such as reducing fullscreen blur in certain games.</em></p>
<h4 id="50-11866-skip-drawing-objects-with-mismatched-xfbp-stages-by-stenzek"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11866/">5.0-11866 - Skip drawing objects with mismatched XF/BP stages</a></strong> by <strong><a href="https://github.com/stenzek">Stenzek</a></strong><a class="headerlink" href="#50-11866-skip-drawing-objects-with-mismatched-xfbp-stages-by-stenzek" title="Permanent link">¶</a></h4>
<p>This is a relatively minor hack meant to suppress warnings in particular games. Normally, XF (Transform Stage, handles vertex transformations) and BP (Blend Processor/TEV, handles blending) are configured to use the same number of channels. However, it's possible that a game could accidentally set a different number of channels in each stage, resulting in some wonky behaviors. Imagine the game configuring the transform stage to say vertices have 2 color channels associated with them, and then configuring the Blend Processor to say that they actually have three! In hardware tests, situations like this result in mostly broken rendering.</p>
<p>The case we were hitting turned up in <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Paper_Mario">Super Paper Mario</a> and <a href="https://wiki.dolphin-emu.org/index.php?title=SSX_Tricky">SSX Tricky</a>, where they would have <em>extra</em> channels in the transform stage compared to the blending stage. This would cause Dolphin to throw a nearly infinite number asserts rendering the game unplayable. While users could bypass and play the game normally by disabling panic handlers, this was still a rather awkward behavior. <strong><a href="https://github.com/stenzek">Stenzek</a></strong> did significant hardware testing on these cases, though it did not have complete coverage. In order to prevent needlessly deadlocking people's games, we've chosen to skip rendering objects with mismatched XF/BP stages and disable the assert. In early testing, there appears to be no change in rendering, meaning that it's possible that these objects don't render on console as well. More testing will be needed, but this should be a suitable solution for the time being.</p>
<p><div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/superpaper.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/superpaper_thumb.jpg"></a>
<figcaption>There is no visual difference, it just doesn't crash anymore, so... here's a screenshot of Super Paper Mario!</figcaption>
</figure>
</div></p>
<p>In order to keep proper tabs on this issue and gather more information for testing, if you've turned on Usage Statistics Reporting, Dolphin will now automatically report to us any games that use mismatched XF/BP configurations so that we can better test fixes down the road when this issue is looked at in greater detail. If we do find a game that has a rendering difference from this change, it could lead to better emulation of these edge cases.</p>
<h4 id="50-11873-wii-online-abort-socket-operations-on-close-by-sepalani"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11873/">5.0-11873 - Wii Online - Abort Socket Operations on Close</a></strong> by <strong><a href="https://github.com/sepalani">Sepalani</a></strong><a class="headerlink" href="#50-11873-wii-online-abort-socket-operations-on-close-by-sepalani" title="Permanent link">¶</a></h4>
<p>While most Wii games have had their online services shutdown by this point, there are still a few games that <em>can</em> connect online and still play. However, even in games that have had their servers shutdown, correct emulation of how the Wii would act is still important. Games such as <a href="https://wiki.dolphin-emu.org/index.php?title=DJ_Hero">DJ Hero</a>, <a href="https://wiki.dolphin-emu.org/index.php?title=Rock_Band_3">Rock Band 3</a>, the <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Just_Dance_(Series)">Just Dance Series</a>, some of the Wii <a href="https://wiki.dolphin-emu.org/index.php?title=Category:Call_of_Duty_(Series)">Call of Duty</a> games, among others have issues when connecting to online services, whether the servers are still up or not. </p>
<p><strong><a href="https://github.com/sepalani">Sepalani</a></strong> has been investigating these issues for many months while writing hardware tests to verify the Wii's online behavior. This particular set of patches allows the Call of Duty games to connect to their servers without crashing. While the servers are actually still up, we weren't able to play on them in Dolphin. We were unfortunately missing the update files, and with the Wii Shop gone, there doesn't appear to be any method to update the game so that they can connect. If someone has played any of the Wii Call of Duty games online, it may be worth doing a NAND backup and trying them out in Dolphin before the remaining servers are gone, in case there are more problems beyond the ones that we've fixed.</p>
<p>While this does improve the situation overall, by fixing one set of hangs, we've simply progressed to another set. As such, the other games in the list will simply progress <em>further</em>, but hang at a later point in the process. Those behaviors are currently being investigated, and we're hopeful that these games will behave correctly in the near future.</p>
<h4 id="50-11969-configurable-mem1mem2-sizes-by-minty-meeo"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11969/">5.0-11969 - Configurable MEM1/MEM2 Sizes</a></strong> by <strong><a href="https://github.com/Minty-Meeo">Minty-Meeo</a></strong><a class="headerlink" href="#50-11969-configurable-mem1mem2-sizes-by-minty-meeo" title="Permanent link">¶</a></h4>
<p>A feature like this has been long in the works, with varying implementations and ideas for it floating around for years. The initial reason that Dolphin has had <em>compile time</em> support for configuring MEM1, which is the GameCube's RAM, is that the GameCube/Wii Dev units have increased memory for debugging and testing. Developers and power users could modify Dolphin's source code in order to increase memory for running the Metroid Prime 3 Beta, which ran on a development unit with 48MB of MEM1 compared to the 24MB that Dolphin, GameCube and Wii have for MEM1. With <strong><a href="https://github.com/Minty-Meeo">Minty-Meeo</a></strong>'s changes, you can now change MEM1 and MEM2 size directly in Dolphin's GUI, without the need for recompiling Dolphin.</p>
<div class="media-block">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/J5_S1TYmIgw" allowfullscreen></iframe></div><figcaption></figcaption>
</figure>
</div>
<p>However, <strong><a href="https://github.com/Minty-Meeo">Minty-Meeo</a></strong> wasn't doing this for something so obscure like this. His motivation was actually centered around game modding and randomizers. Randomizers are a way to bring a fresh experience to some of your favorite games. By randomizing what enemies spawn, where items spawn, and in some cases, how areas are constructed, and much, much more, randomizers can push your game knowledge and skills to the extreme while presenting unique challenges. Popular game series such as <em>The Legend of Zelda</em>, <em>Metroid</em>, <em>Pokemon</em> and many more are home to randomizers. There are already several randomizers of GameCube games, including <a href="https://wiki.dolphin-emu.org/index.php?title=The_Legend_of_Zelda:_The_Wind_Waker">The Legend of Zelda: The Wind Waker</a> and Metroid Prime 1/2 featuring sizable randomizer communities. These randomizers run on both Console and Dolphin without any modification!</p>
<p><div class="media-block wide">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/windwakerrandomizer.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/windwakerrandomizer_thumb.jpg"></a>
<figcaption>Randomizers breathe new life and challenges into some of your favorite games.</figcaption>
</figure>
</div></p>
<p>While we do believe that targeting original hardware should be the goal <em>when possible</em>, using additional memory during development can allow for easier debugging <em>and</em> can allow for doing things that simply aren't possible on original hardware. Take for instance the Colossal Cavern mod for <a href="https://wiki.dolphin-emu.org/index.php?title=Pikmin_2_(GC)">Pikmin 2</a>, which takes <em>every</em> enemy and treasure and loads it into a single, gigantic cave floor. Memory limitations make a single concurrent level of this size unreasonable on actual hardware, but with expanded RAM, suddenly the improbable becomes possible.</p>
<div class="media-block">
<figure>
<div class="embed-responsive embed-responsive-16by9"><iframe src="https://www.youtube.com/embed/T3fw5zTbwYk" allowfullscreen></iframe></div><figcaption></figcaption>
</figure>
</div>
<p>As soon as this feature was merged, people were asking about turning up memory as a performance hack for games. However, <em>most</em> games do not even query for how much memory is available and will not take advantage of additional memory for features. In fact, some games like <a href="https://wiki.dolphin-emu.org/index.php?title=Super_Mario_Galaxy_2">Super Mario Galaxy 2</a> will outright crash when run with increased memory. There can be benefits, though! The infamous crash in <a href="https://wiki.dolphin-emu.org/index.php?title=Fire_Emblem:_Radiant_Dawn">Fire Emblem: Radiant Dawn</a> where the game runs out of memory in Dolphin for unknown reasons can be avoided by increasing MEM1 by even a slight amount.</p>
<h4 id="50-11934-settingstxt-dont-output-null-bytes-by-josjuice"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11934/">5.0-11934 - Settings.txt: Don't Output Null Bytes</a></strong> by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong><a class="headerlink" href="#50-11934-settingstxt-dont-output-null-bytes-by-josjuice" title="Permanent link">¶</a></h4>
<p>This change is part of an ongoing effort for Dolphin to better preserve your emulated Wii's ID. This ID is useful for connecting to things like Wiimm's WiFi servers, which have a seven day lockout for new users in order to help with cheater and hacker problems. While they allow Dolphin users, you're required to have a real Wii ID, which hasn't been handled all that well. Recent efforts by <strong><a href="https://github.com/JosJuice">JosJuice</a></strong> and <strong><a href="https://github.com/Leseratte10">Leseratte10</a></strong> are at the forefront of better handling these situations so that people that use Dolphin on Wiimm's servers aren't randomly mistaken for new users.</p>
<p><div class="media-block wider">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/wiimmtrack.jpg"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/wiimmtrack_thumb.jpg"></a>
<figcaption>Mario Kart Wii mods, complete with online support, add hundreds of tracks to the game.</figcaption>
</figure>
</div></p>
<p>This most recent change has to do with the encryption of Settings.txt, which stores a lot of important Wii information. While encrypting this file, Dolphin wasn't handling things quite right, which allowed for Null Bytes to end up in the middle of encrypted data. The Wii would treat the Null Byte as end of the line, resulting in data being incorrectly read and users being unable to be verified on their server. With this corrected and other changes over the last few months, users should no longer run into issues where they are suddenly unrecognized by Wiimm's servers.</p>
<h3 id="the-grand-return-of-the-android-progress-report-section">The Grand Return of the Android Progress Report Section<a class="headerlink" href="#the-grand-return-of-the-android-progress-report-section" title="Permanent link">¶</a></h3>
<p>It's been quite a while since we've had enough Android changes that we've felt the need to dedicate a full section to them. But with a smattering of new contributors and gigantic fixes, it was a nobrainer to specifically highlight these changes.</p>
<h4 id="50-11827-android-fix-android-tv-support-on-latest-versions-of-android-by-webgeek1234"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11827/">5.0-11827 - Android - Fix Android T.V. Support on Latest Versions of Android</a></strong> by <strong><a href="https://github.com/webgeek1234">webgeek1234</a></strong><a class="headerlink" href="#50-11827-android-fix-android-tv-support-on-latest-versions-of-android-by-webgeek1234" title="Permanent link">¶</a></h4>
<div title="The Android robot is reproduced or modified from work created and shared by Google and used according to terms described in the Creative Commons 3.0 Attribution License." style="margin-top: .5em; margin-left:2em; margin-bottom:1em; max-width:8%; min-width:72px; float:right; text-align:center;">
<img style="max-width: 100%;" src="https://dolphin-emu.org/m/user/blog/progress-report/2017-april/android-logo-peeking.png">
</div>
<p>When it comes to finicky platforms like macOS or Android TV, we have always warned users to be wary when upgrading to a new OS version. Not only are they the platforms most likely to randomly break something in an update, they also have our smallest userbase and no regular developers to address when something goes wrong. Case in point, Android TV 9 has not been able to launch Dolphin since it was released in August of 2018. That's a lot longer than we'd like for the latest version of a platform we support to be broken, but honestly, it couldn't be helped. Our audience of up to date Android TV players is incredibly small, and none of our developers use Android TV for Dolphin on a regular basis. Fortunately, we have a great community that we can lean on for situations like this. After reporting the issue to us, <strong><a href="https://github.com/webgeek1234">webgeek1234</a></strong> turned around and started investigating it themselves. They determined the entire incompatibility was because Dolphin was bringing up a popup in a deprecated way. Yes, the entire application was crashing because of one old popup. Android. They updated the way Dolphin brought the popup, a one line change, and suddenly everything is working once more!</p>
<h4 id="50-11849-android-add-sd-card-settings-to-gui-by-ebola16"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11849/">5.0-11849 - Android - Add SD Card settings to GUI</a></strong> by <strong><a href="https://github.com/Ebola16">Ebola16</a></strong><a class="headerlink" href="#50-11849-android-add-sd-card-settings-to-gui-by-ebola16" title="Permanent link">¶</a></h4>
<p>While this particular setting may not make much sense to people on the outside, we weren't surprised to see <strong><a href="https://github.com/Ebola16">Ebola16</a></strong>'s interest in adding it to Dolphin Android. For many years, they have been one of our most dedicated bug reporters when it comes to various Super Smash Bros. Brawl mods. One of the biggest things you need to boost Brawl mods is SD card support. While you could manually enable SD cards via INI files, <strong><a href="https://github.com/Ebola16">Ebola16</a></strong> decided to streamline the process by allowing users to enable, disable, and select SD cards directly in the Dolphin Android Interface.</p>
<p><div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/dolphinandroid-sdcard.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/dolphinandroid-sdcard_thumb.png"></a>
<figcaption>Enabling SD cards is simple and painless, just like on desktop builds.</figcaption>
</figure>
</div></p>
<p><strong>Note</strong>: Dolphin will automatically create a 128MB blob file that acts as a virtual SD card, much like it does on desktop builds. Dolphin cannot use an actual SD card.</p>
<h4 id="50-11860-android-immediately-update-wii-remote-settings-by-ebola16"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11860/">5.0-11860 - Android - Immediately Update Wii Remote Settings</a></strong> by <strong><a href="https://github.com/Ebola16">Ebola16</a></strong><a class="headerlink" href="#50-11860-android-immediately-update-wii-remote-settings-by-ebola16" title="Permanent link">¶</a></h4>
<p>Configuring Wii Remote settings on Android is a pain for multiple reasons, one of which is that Dolphin Android <em>required</em> a full restart in order for changes to take effect. This meant that making simple changes was sometimes a multistep process. <strong><a href="https://github.com/Ebola16">Ebola16</a></strong> had enough of the problem and restructured how Wii Remote settings were saved in order for them to immediately take effect, much like how it is handled on the desktop version.</p>
<h4 id="50-11909-android-add-install-wad-functionality-to-the-gamelist-by-ebola16"><strong><a href="https://dolphin-emu.org/download/dev/master/5.0-11909/">5.0-11909 - Android - Add Install WAD Functionality to the Gamelist</a></strong> by <strong><a href="https://github.com/Ebola16">Ebola16</a></strong><a class="headerlink" href="#50-11909-android-add-install-wad-functionality-to-the-gamelist-by-ebola16" title="Permanent link">¶</a></h4>
<p>Installing WADs is an important feature for Dolphin, which wasn't easy to do on Android. The original intent behind this Pull Request is to make installing IOS files easier for mod loaders. Unlike the desktop version, accessing updates and the system menu isn't quite as easy right now. Plus, when space is a concern, simply lugging around a single IOS wad is a lot cheaper than transferring a Wii game or installing a full System Menu, Default Channels, and a full set of IOS files from a system update.</p>
<p>In the end, this is a nice feature to have and makes the Android GUI more powerful and closer to the the desktop GUI.</p>
<p><div class="media-block narrower">
<figure>
<a href="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/dolphinandroid-installwad.png"><img src="https://dolphin-emu.org/m/user/blog/progress-report/2020-april/dolphinandroid-installwad_thumb.png"></a>
<figcaption>Installing WADs is painless and simple.</figcaption>
</figure>
</div></p>
<p><br/></p>
<h3 id="last-months-contributors"><strong>Last Month's Contributors...</strong><a class="headerlink" href="#last-months-contributors" title="Permanent link">¶</a></h3>
<p>Special thanks to <a href="https://github.com/dolphin-emu/dolphin/graphs/contributors?from=2020-04-01&to=2020-04-30&type=c">all of the contributors</a> that incremented Dolphin from <a href="https://dolphin-emu.org/download/dev/master/5.0-11825/">5.0-11825</a> through to <a href="https://dolphin-emu.org/download/dev/master/5.0-11991/">5.0-11991</a>!</p>
<style>
.entry-content h3 { margin-top: 1.5em; }
.entry-content h4 { margin-top: 2em; }
.entry-content h5 { margin-top: 2.5em; }
</style>