It's been a very hectic two months. Dolphin's development builds officially dropped support for Windows 7, Windows 8, and Windows 8.1 in 5.0-16393 when the Windows buildbots were updated to use Qt6. If you read the last Progress Report, 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 here if you haven't already.
But with loss, some new has also come. We now have a new builder for Windows on ARM! Dolphin has supported Windows on ARM for a couple of years now, 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 shuffle2 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 Downloads page. We're not exactly sure how much use these builds will get, but we're hopeful for the future of the platform.
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 edge 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 real Action Replay discs does make a difference!
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!
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 after 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.
While most users are probably waiting for our Post Processing system to be rewritten, iwubcode 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 Graphics Mods!
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.
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, extremely 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.
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 Super Mario Galaxy 2 on Dolphin without enabling any Graphics Mods.
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!
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.
For the feature's debut, the following titles have Graphics Mods:
- Arc Rise Fantasia
- Battalion Wars 2
- Donkey Kong Country Returns
- Fragile Dreams - Farewell Ruins of the Moon
- The House of the Dead: Overkill
- The Last Story
- Link's Crossbow Training
- Little King's Story
- Mario Kart Wii
- Monster Hunter Tri
- Nights: Journey Into Dreams
- Super Mario Galaxy 2
- Mario Strikers: Charged
- The Conduit
- The Legend of Zelda: Twilight Princess - Wii version only currently
- The Legend of Zelda: Skyward Sword
- Wii Play
- Xenoblade Chronicles
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.
- Skip: Allows the modder to skip rendering this target group.
- Scale: Allows the user to scale/stretch a target group.
- Move: Allows a user to move a particular target group.
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.
If you're interested in creating your own Graphics Mods, we'll be maintaining a Graphics Mod guide on the Dolphin Wiki that should stay up to date as the feature evolves.
iwubcode has many grand plans to renovate Dolphin's ability to enhance graphics. From post-processing to Graphics Mods, they've got a lot up the pipeline. But if anything was going to get merged, that meant breaking down their projects into smaller pieces. This is just a taste 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.
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 wants to do it, it's just that some end up having to do it.
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.
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.
But if the GameCube and Wii are Single Core 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.
Dual Core is actually moving GPU 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 all of the major work that Dolphin does on a typical configuration, splitting them up can theoretically give up to 100% faster performance depending on the game.
This was essential in Dolphin's early days. Back then, both Dolphin's CPU JIT and the CPUs we'd be running it on were significantly slower than today. Twelve years ago, hundreds of games were too demanding to run fullspeed on the fastest computers in the world. 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.
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 detected, 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 as little as possible in order to get the massive performance gains that it gives.
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 always this problematic. Something changed along the way that has exasperated the core problem of Dual Core...
What exactly happened?
After Dolphin 4.0, something flipped that no one in the early days of Dolphin's development could have predicted. With the advent of TEV Fixes New and a huge slate of massive JIT optimizations, we actually made it so that the GPU thread was now the bottleneck most of the time!
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!
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.
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.
This pull request doesn't 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 if 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.
Thankfully, the panic handler issue has finally been stopped. JosJuice 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.
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.
Speaking of annoying unknown opcode popups, pokechu22 investigated a case where Dolphin could erroneously execute bad data after a game called the command for a FIFO RESET.
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 The Legend of Zelda: Ocarina of Time (VC). 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.
pokechu22 investigated a similar case found in a demo disc that used FIFO RESET between games and menus and found that any data leftover past a FIFO RESET was thrown out. As such, we now throw out any commands immediately following a FIFO RESET before things are reinitialized.
Let's be honest here. In the past, booting Datel titles in Dolphin was a pain in the ass. It required both DSP-LLE and 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.
You may wonder: "Why would I want to boot a Datel title in an emulator? All Datel did was make a bunch of unlicensed products, right?" 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 GBA Emulator 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.
This brings us to a rather weird 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 should 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 The Legend of Zelda: The Wind Waker only works when using a real Action Replay disc to initialize the code.
In an effort to make these unlicensed titles more accessible, pokechu22 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.
For the HLE audio issue, the problem was caused by a typo in Datel's 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 just 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 pokechu22 to rely on yet. All we know is that by improving the timings on DSP-HLE, pokechu22 was able to get it working in the same manner that it was on DSP-LLE and console.
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.
The reason why Emulated BS2 didn't work with Datel's Loader stemmed from the fact that Datel did way less initialization than actual games. Datel's titles heavily relied on the Main Menu to setup almost everything. pokechu22 had to go through various registers and 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.
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.
We highly recommend not 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 True Crime: New York City) or homebrew that can do unexpected things, please use these titles with caution.
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!
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 many times faster, to the point where DSP emulation is never a performance bottleneck when using DSP-HLE. Yet in modern builds of Dolphin, DSP-HLE and DSP-LLE have near parity in supported microcodes. Users no longer have to choose between the accurate but demanding DSP-LLE or old HLE audio that was rife with bugs and only supported a handful of titles well.
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.
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.
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, pokechu22 implemented the libasnd microcode used in most homebrew on the side while working on other audio things.
Some homebrew that use the slightly more complicated libaesnd still require LLE audio as of this Progress Report, but work on changing that is already underway.
Dev Diary - Solving the Mystery of Monster House¶
Monster House is a game that has been problematic in Dolphin for a very long time. It's right in that zone where it's not popular enough to see a lot of attention, but not awful enough to draw a lot of morbid curiosity. It's a servicable game that falls apart in the final act.
There have been reports that Monster House 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.
After many years of avoiding the eyesore, it was time to send someone in for real. Someone to get to the bottom of Monster House and find out the truth.
Our unwilling volunteer this time around was JMC47. 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.
Testers Log - Day 1
I've seen Monster House 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 True Crime: New York City, it just seemed like it wasn't worth my time. Yet, supposedly this game still isn't playable. We'll see about that.
The game starts out rather suddenly, with the main cast getting thrown into the Monster House 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 Monster House 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.
Testers Log - Day 2
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.
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 know that, but it seems like they didn't understand why 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.
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.
Testers Log - Day 3
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 Monster House had swallowed me alive.
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.
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 Monster House should have stopped me while it had the chance. Now it's war.
Testers Log - Day 4
The game put up a rather spirited fight, but i have emerged victorious.
It tried the same trick on me again with the invalid reads and 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. This game is just icache sensitive!
If I had been playing this game years ago, perhaps I wouldn't have known what to do. Thankfully, by this point we have weapons to fight off such a problem thanks to pokechu22 and the infamous Scooby Doo! incident.
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.
Testers Log - Day 5
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 accurate 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.
If the game crashes now, I'll be able to follow a stack trace and figure out exactly where in the game code the problem is happening. From there, if the game is relying on icache behaviors to the point of needing accurate emulation of it, we can just patch the game instead.
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!
Testers Log - Day 6
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.
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!
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 but two 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.
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.
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.
Testers Log - Day 7
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.
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.
And, why exactly are the cutscenes where you get caught to switch characters exactly the same as the QTEs that you can't fail 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.
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.
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!
How come the #@&$ing house can seemingly capture these kids at will and kill them but doesn't. The same exact cutscene where the vent comes down and grabs you during a QTE to kill you is used multiple times 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?!
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.
Testers Log - Day 8
@#&$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 gameplay. 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!
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.
This is just wonderful.
Testers Log - Day 9
This log has been removed due to excessive profanity.
Testers Log - Day 10
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.
Testers Log - Day 11
After several minutes of playing the worst version of Simon says 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 barely 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.
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 grazes 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.
The boss's health bar is almost depleted... please... just end... YES! IT'S OVER!
After all of that, it's hard to judge Monster House because of how hard it relies on quick time events toward the end of the game. The core gameplay isn't bad, 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.
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-
What you want me to hit buttons 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-
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.