For those who may have heard about ShmupArch already, and for those who have not, I felt it would be a good idea to write this article to give a more in-depth explanation of what ShmupArch is and how it works. I think this article can also help clear up some confusion or misunderstandings about the emulator.
To start things off, ShmupArch is merely a custom configuration of a popular emulation front-end called Retroarch. By custom configuration, I mean that I have not done any in-depth coding or altering of Retroarch itself. What I have done is gone in and configured all these different settings in Retroarch in the aims of achieving the LOWEST POSSIBLE input lag and display lag that the emulator offers. Additionally, I have created a bunch of custom configuration files for shmups specifically, in order to get the emulator to run these games at their correct frame rates. I did this because, when it comes to shmups, Retroarch often does not know the correct frame rate for them and runs them at 60 fps when it shouldn’t, Dodonpachi DaiOuJou is a notable example of this. Science has shown that, with too fast frame rates, comes less slowdown, increased bullet speed, and high sodium levels.
Let’s back up a sec though. So … if I haven’t done any in-depth coding, why even bother with such a release? Why not just download the default version of Retroarch and call it a day? Does ShmupArch need to exist? This is actually a question I have heard a time or two. To begin answering this question, I think we should turn and look at Retroarch itself. If you have never used Retroarch before, the first thing you should know about it is that it is not a traditional emulator; not at all. In fact, it might be more accurate to describe Retroarch as more of a pseudo operating system than an emulator. What Retroarch does is it houses the “cores” of other emulators and then runs them through its own program and settings. For example, Snex9x is a popular Super Nintendo emulator and by using this emulator’s “core,” Retroarch is able to run Super Nintendo games like Snes9x, while also adding in its own settings and features.
To be completely honest, up until this year, I was not much of a fan of Retroarch. Yes, it was convenient how it could run all these different emulator cores, but with that broad compatibility came an extremely clunky user interface, frequent bugs, and additional input lag. Why bother, I thought, it’s better just to stick to the traditional single system emulators. Then around May of this year, Retroarch released a game changing feature … Run-ahead.
What is Run-ahead? Well, to put it simply: it is a feature that cuts out input lag from the emulation process. Run-ahead takes a game like Battle Garegga, which previously had 4 frames of lag in emulation, and chops it down to 1. BEAUTIFUL! Now we’re talking!
If you’re curious about how exactly this works, check out this article for a detailed explanation on the technical aspects of the feature:
After learning about Run-ahead, I remember checking the shmup forums from time to time to see if anyone was talking about it or was using it, but nothing. Not a word for months. Everyone had pretty much just settled into either Shmupmame or regular MAME. Why aren’t more people using Retroarch? I wondered. As I discovered, there are a number of reasons why.
The first is that the Retroarch user interface is extremely confusing, cluttered, and oddly separated. For example, it took me a week of trial and error to figure out how to turn on the frame-rate display, as it is not located in video settings, but in “user interface.” So that’s an immediate barrier for players. A second is that the Run-ahead feature isn’t plug and play type of deal; far from it. Instead, in order to not cause stuttering and glitchiness, you need to manually configure each game using the Retroarch frame advance feature. Then you need to know how to save all these settings on a per-game basis, which is far more confusing than it should be. What is more, the way each game reacts to the different Run-ahead settings can vary as well, which is another point of consideration. Then there is the fact that you need to know what cores support Run-ahead and what emulators don’t. Some cores just straight up crash if you try and use the feature. Basically, in order to make any sort of permanent change in the Retroarch system, and get the lag reduction to work correctly, you have to fight the emulator kicking and screaming.
TLDR Retroarch itself, as well as its revolutionary Run-ahead feature, is extremely complicated, time consuming, and confusing to setup. The average player, even the one familiar with emulation, is not going to have the time and patience to dedicate towards optimizing their setup for maximum performance, nor creating all the custom configuration files handling the proper framerates. This is where ShmupArch comes in. Think of ShmupArch as a standard for shmups that we can all default to and work off of. More likely than not, ShmupArch is saving the user a 3 hour tutorial and troubleshooting process and a weekend’s worth of creating custom configuration files.
What are the Advantages and Disadvantages of ShmupArch?
Plain and simple, the main advantage of ShmupArch is its ability to achieve extremely low input and display lag. Performance wise, there is no emulator out there that can compete with 1-frame of input lag. Sure, Shmupmame can get close with 2 frames of lag on games like Dodonpachi and Ketsui, but still greatly falls behind with the Raizing and Psikyo games.
For a detailed comparison between the lag performance of these two emulators, check out this video by yours truly:
As for disadvantages, the time I am writing this article (11/21/2018), I am afraid to say that ShmupArch is not the all-in one solution I wish it could be. Getting past the disadvantage of its clunky interface, even with all the configuring that has been done, ShmupArch still has one huge weakness: compatibility. Right now, ShmupArch is only able to effectively function on one emulator core, Final Burn Alpha. FBA, for those unfamiliar with it, is an open source arcade emulator with very strong serialization support — meaning it effectively creates and loads save-states. In terms of Run-ahead, this is a must because the Run-ahead feature is only able to function due to rock solid save-state support. Fun fact, FBA is also the emulator core that was used to develop the groundbreaking GGPO rollback netcode, which functions very similarly to how Run-ahead works by utilizing save-states.
Anyway, since arcade emulation with Run-ahead is only possible using the FBA core (at least right now), this means that ShmupArch’s compatibility equals Final Burn Alpha’s compatibility. This isn’t anything to sneeze at, as FBA can emulate many of the best shmups of all time. However, FBA isn’t perfect and basically is unable to support any CAVE games from Mushihimesama onward which is a disappointment. It also has some slowed-down audio issues with Battle Garegga and Batrider.
For a complete list of what shmups are compatible, check out this list here:
However, with all this said, there is hope of greater compatibility! Remember the emulation “cores” I mentioned earlier? Well, it just so happens that there is a MAME core that is able to run newer shmups. The drawback, though, is that this core currently does not have any run-ahead support. This means that not only is the MAME core laggy in itself, it is also stricken with added latency from Retorarch. So, as of 11/21/18, this core is nothing more than hot garbage. Better just to use the stand alone MAME emulator for these newer titles. However, there have been some small baby steps in this department and, once the MAME core does get functioning Run-ahead support, this will be a massive breakthrough! The vast majority of arcade-released shmups will then be playable with only 1 frame of input lag. When this happens, ShmupArch will be hard to deny as the new standard. Hopefully the user interface will be improved by then as well 🙂
Thank you for reading! I hope this helped to clear up what ShmupArch is exactly, and how it functions.