Ever spent an evening getting a game to boot, only to watch it crash the moment you press Start? If so, you have already met the strange triangle of retro emulation: MAME, FBNeo, and RetroArch. People talk about them as if they were three rival consoles, but they are not the same kind of thing at all. One is a preservation project, one is a performance-focused arcade fork, and one is a frontend that hosts other emulators. Understanding that difference is the whole game.
This guide walks through the three areas where newcomers get stuck: compatibility, controls, and save files. No hype, no download links, just how the pieces actually fit together and where the traps are hiding.
What Each One Actually Is
Before comparing behavior, it helps to know what you are comparing.
MAME (Multiple Arcade Machine Emulator) is an open-source project that started in 1997 with Nicola Salmoria and has grown into a documentation and preservation effort as much as an emulator. It emulates arcade hardware first, and since the MESS project merged into it in 2012, it also covers a huge range of home computers and consoles. Its guiding philosophy is accuracy: if the original hardware did something odd, MAME tries to reproduce the odd thing.
FBNeo (FinalBurn Neo) is a fork of FinalBurn Alpha, which itself descended from the original FinalBurn emulator. It focuses on arcade games, with an emphasis on speed and a carefully curated set rather than exhaustive hardware coverage. The FBNeo repository describes it as a continuation of that lineage, and its community treats it as a leaner, faster alternative for the arcade titles it supports.
RetroArch is the reference frontend for libretro, a cross-platform API that lets emulator “cores” plug into one common interface. The libretro documentation describes RetroArch as a frontend for emulators, game engines, media players, and other applications. Crucially, RetroArch is not an emulator itself. It is the shell. The actual emulation comes from whichever core you load, and that may include MAME or FBNeo cores.
| Tool | Type | Main goal | Emulation comes from |
|---|---|---|---|
| MAME | Standalone emulator | Accuracy and preservation | Its own drivers |
| FBNeo | Standalone emulator | Speed and a curated arcade set | Its own drivers |
| RetroArch | Frontend | One interface for many cores | libretro cores |
That table explains most of the confusion. Asking “is RetroArch compatible with this game?” is really asking “is the core I loaded compatible with this game?”
Compatibility: Why the Same Game Behaves Differently
ROM sets are version-sensitive
This is the number one source of heartbreak. A ROM set is the collection of files a specific emulator version expects. MAME changes its ROM set between releases as drivers are corrected or redumped. FBNeo expects its own set as well. Mix sets across emulators and you get “missing files” errors, even when the game folder looks complete. (MAME emulator encyclopedia entry)
The practical fix is boring but effective: keep one ROM set per emulator, label the folder with the version, and never mix them. Audit tools exist for checking sets against a build, and they save hours compared with trial and error. When people complain that a game “works in one emulator but not the other,” nine times out of ten they are comparing two different set versions.
Accuracy versus speed
MAME’s accuracy-first approach means some games run heavier than they would elsewhere, because the emulator is doing more work to get the timing right. FBNeo’s curated approach means the games it supports tend to run fast and smoothly, but the list of supported titles is narrower by design. Neither is wrong. They are answering different questions.
RetroArch sits above this. Its compatibility depends entirely on the core you choose, and different cores have different strengths. Loading a MAME core inside RetroArch gives you MAME’s behavior with RetroArch’s interface. Loading an FBNeo core gives you FBNeo’s behavior with the same interface. The frontend does not magically make an incompatible title work.
The frontend layer adds its own variables
Because RetroArch is a host, there is one more layer where things can go wrong: core options. Settings like video resolution, frame timing, and audio latency live in the frontend, and a mismatched option can make a perfectly good core misbehave. If a game runs fine in standalone MAME but stutters in RetroArch, check the core options before blaming the core.
This layering is the same idea you see in modern infrastructure, where a control plane manages many data planes. If that phrasing sounds familiar, the service mesh architecture explained control plane data plane breakdown covers how separation of concerns works in distributed systems, and the same logic applies here: the frontend coordinates, the core does the work.
Controls: Mapping, Profiles, and Muscle Memory
How MAME handles input
MAME lets you remap keyboard and gamepad input globally and per game. That per-game layer matters, because arcade cabinets had wildly different layouts. A fighting game with six buttons and a trackball game do not want the same mapping.
The common mistake is remapping everything globally and then wondering why one game feels wrong. The better habit is to configure a sane default, then override only the games that need it. MAME remembers those overrides, so you set it once.
How FBNeo handles input
FBNeo also supports keyboard and gamepad mapping with per-game configuration. Its options are generally simpler than MAME’s, which is part of its appeal. Fewer knobs means fewer ways to get lost, though it also means less fine-grained control for unusual cabinets.
How RetroArch handles input
RetroArch centralizes input through its RetroPad abstraction. Instead of mapping your physical controller to each emulator’s internal buttons, you map it once to a virtual pad, and each core translates from there. Per-core overrides let you adjust when a system needs something different.
Two practical tips that save real frustration:
- Set up your controller once in RetroArch’s input menu, then verify it inside a core.
- Save a per-core override the moment a game feels right, before you touch anything else.
The universal control mistakes
- Mapping buttons while a game is running instead of from the menu, then losing the mapping on exit.
- Forgetting that analog sticks and d-pads are separate inputs, so a game that expects digital input ignores the stick.
- Assuming a controller that works in one emulator will work identically in another. It usually will, but hotkeys and menu buttons often differ.
This is the same lesson that shows up in networking: the hardware underneath matters more than the interface on top. The router hardware offloading explained your CPU not doing article makes a similar point about where work actually happens, and emulation rewards the same kind of thinking. (Web application firewall explained beginners it blocks it)
Save Files: States, SRAM, and the Compatibility Trap
Save files cause more confusion than any other topic, mostly because “save” means three different things.
Save states are snapshots of the emulator’s entire memory at a moment in time. They are convenient and instant, but they are tied to the emulator and version that created them. A state made in one build may not load in another.
SRAM and battery saves are the in-game saves the original hardware wrote to cartridge or board memory. These are far more portable, because they represent what the game itself stored.
NVRAM and high-score files are arcade-specific. Arcade boards kept settings and scores in non-volatile memory, and emulators can persist that data too.
| Save type | Portability | Tied to version? |
|---|---|---|
| Save state | Low | Usually yes |
| SRAM / battery save | High | Rarely |
| NVRAM / high scores | Medium | Sometimes |
MAME supports save states and NVRAM files. High-score saving has historically been limited or required extra configuration, and the details vary by version, so check current documentation rather than trusting an old forum post. FBNeo supports save states as well. RetroArch provides save states and SRAM saves per core, and here the version sensitivity is sharpest: a state created under one core version may refuse to load under another.
The practical rule is simple. Use save states for convenience during a session, and rely on in-game saves for anything you want to keep long term. Back up your save folders before updating any emulator, because updates are exactly when states break.
Which One Should You Actually Use?
There is no single winner, and anyone who tells you otherwise is selling something. The honest answer depends on what you want.
Choose MAME if you care about accuracy, obscure arcade hardware, or the preservation mission. Choose FBNeo if you want fast, smooth arcade play for a well-supported set of popular titles. Choose RetroArch if you want one interface, one controller setup, and one place to manage many systems, and you are willing to learn how cores and overrides work.
Many people run all three. That is fine. The trick is keeping their ROM sets and save folders separate so they never contaminate each other. Treat each as its own little ecosystem with its own rules, and the frustration drops dramatically.
If you enjoy understanding how layered systems fit together, the GitOps explained: how Git became the control plane of modern infrastructure piece is a good parallel read, because it is the same pattern of a declarative layer managing many workers underneath.
Conclusion
MAME, FBNeo, and RetroArch are not rivals in a fight. They are three answers to three different questions. MAME asks how faithfully can we reproduce the hardware. FBNeo asks how fast and cleanly can we run a curated arcade library. RetroArch asks how do we give all of these a single, consistent home.
Once you separate compatibility from controls from saves, the confusion mostly evaporates. Keep ROM sets matched to versions. Map controls once and save overrides. Treat save states as temporary and in-game saves as permanent. Do those three things and the evening you used to spend troubleshooting becomes an evening you spend playing.
Frequently Asked Questions
Is RetroArch an emulator?
No. RetroArch is a frontend for the libretro API. It provides the interface, input handling, and save management, while the actual emulation comes from whichever core you load. Some cores are based on MAME or FBNeo, which is why RetroArch can feel like an emulator without being one.
Why does a game work in MAME but not in FBNeo?
Usually because the two emulators expect different ROM sets, and the game’s files are matched to only one of them. FBNeo also supports a narrower curated list of titles by design. Check that your set matches the emulator version before assuming the game itself is the problem.
Can I use the same save state in MAME, FBNeo, and RetroArch?
Generally no. Save states capture the emulator’s internal memory and are tied to the emulator and often the exact version that created them. In-game SRAM and battery saves are far more portable. Keep states for short-term convenience and rely on in-game saves for anything you want to preserve.
Do I need to remap controls separately for each emulator?
Yes, unless you use RetroArch’s RetroPad abstraction, which lets you map a controller once to a virtual pad and then translate per core. MAME and FBNeo each keep their own input configuration, including per-game overrides, so settings do not carry across.
Which emulator is most accurate?
MAME is the accuracy-focused project, prioritizing faithful reproduction of arcade hardware even when that costs performance. That does not make it the best choice for every player. If you want speed and smooth play for well-supported arcade titles, FBNeo is often the more pleasant option.
What is the biggest mistake beginners make?
Mixing ROM sets between emulators and then concluding a game is broken. Each emulator expects files matching its own version, and mismatches produce missing-file errors that look like compatibility failures. Keep separate, clearly labeled folders for each emulator and its set.
