RetroArch Cores 2026: Right Core in 12 Steps, 30 Min

RetroArch is not an emulator. This is the first thing that trips people, and the entire Core Downloader is engineered to keep them tripping. RetroArch is a frontend — a shell that loads emulators as swappable plug-in libraries called cores. Install RetroArch and you have installed exactly zero emulators. The "200+ cores" number you keep reading is a catalogue figure, a boast, and on your specific device it is a lie by roughly half. This tutorial is about closing the gap between what the marketing implies and what actually loads on your hardware — which core to pick for each system, how to install it without the downloader sabotaging you, and how to configure it per-game without nuking your global setup.

If you just want the machine set up and playing in half an hour, we have a companion piece — the 12-step, 30-minute setup walkthrough — that gets you to a working library fast. This article is the deeper one: the reasoning behind every pick, the regressions nobody warns you about, and a complete config at the end you can copy.

What a Core Actually Is

Before you download anything, understand the architecture, because every mistake downstream comes from misunderstanding it. RetroArch implements the libretro API, a thin contract that says: a core exposes functions for loading content, running one frame, and handing back video, audio, and input. The frontend supplies the window, the shaders, the input mapping, the save states, the netplay. The core supplies the actual emulation. They are compiled separately and shipped separately, and they can have wildly different licenses, maintainers, and quality.

The frontend-and-core split

On disk a core is a single dynamic library: snes9x_libretro.so on Linux, .dll on Windows, .dylib on macOS, .dll-equivalent bundles on consoles. RetroArch scans its cores/ directory, reads a matching .info file for each one, and builds the menus you see. The consequence that bites everyone: the frontend and the core must be built for the same platform and CPU architecture. A brilliant x86_64 core is inert on an ARM handheld. This is not a bug you can configure your way out of — it is the whole design. When someone says "my core won't load," the answer is almost always "you downloaded the wrong architecture" or "you never fetched the info file."

Why "200+ cores" is a catalogue, not an inventory

The often-quoted 200-plus figure is the total across the entire libretro ecosystem — every emulator, game engine (Doom, Cave Story, Quake), and media player anyone has ever wrapped. Your Core Downloader shows only the builds that exist for your exact platform and architecture. On a desktop x86_64 machine you will see most of them. On an ARMv7 device you will see far fewer, and on something exotic you might see a third of the list. The webOS core repository, rebuilt in December 2025, ships roughly 170-plus ARMv7 cores plus an experimental aarch64 set — a good concrete reminder that "how many cores exist" and "how many run on your box" are different questions with different answers.

Licensing, GPLv3, and why nobody charges you

RetroArch itself is GPLv3, open source, with a GitHub repository sitting north of 13,200 stars. Cores carry their own licenses — many GPLv2, some more permissive, a few non-commercial. Nobody sells you a core. If a page is quoting "dollar amounts" for RetroArch cores, close the tab; it is either confused or fabricated. The one real cost is your time and, for certain systems, a legitimately-dumped BIOS from hardware you own. That legal line matters more than people admit, and we will come back to it. If you would rather a whole distribution assemble the cores for you, the Batocera 43.1 install guide covers the batteries-included route that bundles a curated core set out of the box.

Prerequisites: Versions & Hardware

Skipping prerequisites is how you spend an evening debugging a black screen that a version bump would have fixed in ten seconds. Pin these down first.

Software: RetroArch 1.22.2 and why the version matters

Run the current stable. As of mid-2026 that is the 1.22.x line, with 1.22.2 released 20 November 2025. There is a specific trap here: 1.22.0 shipped a regression where enabling shaders produced a black screen on some drivers. It was patched quickly in 1.22.1 and again in 1.22.2, so if you are on 1.22.0, update before you do anything else. The prior milestone, 1.21.0 from spring 2025, is the one that landed the Apple Vulkan backend, CoreMIDI, and a batch of 3DS fixes — relevant if you are on macOS or iOS. Do not chase "2.0"; there is no such release, and any site advertising one is inventing it.

Hardware: what your CPU can and cannot brute-force

Emulation accuracy costs cycles, and the highest-accuracy cores are unapologetic about it. Match your ambitions to your silicon. The table below is deliberately conservative — it assumes you want full speed with the accurate core, not the fast-and-loose one.

The 4GHz line is not decoration: bsnes Accuracy is cycle-accurate and genuinely wants roughly that single-thread clock to hold full speed. On a handheld you will use Snes9x instead and never notice the difference in 99% of games. If you are shopping the handheld tier and weighing what actually runs, our Retroid Pocket 6 versus G2 breakdown gets specific about which chips clear which systems, and the Miyoo Mini Plus PS1 reality check shows exactly where a budget ARM core tops out.

BIOS, ROMs, and the legal line

Some cores refuse to run without a BIOS: PS1, PS2, Sega CD, and a handful of others expect the real firmware, checked by filename and often by hash, sitting in RetroArch's system/ directory. RetroArch does not and will not distribute these — dump them from hardware you own. The same principle governs game content. This site does not host ROMs and will not tell you where to get them; what we will tell you is that a mismatched or corrupt BIOS is the single most common reason a correctly-installed core "loads but does nothing," so verify the file before you blame the emulator.

Installing Cores: 12 Steps

Here is the whole procedure, in order, with the reasoning for each step. Do them in sequence; several of them exist specifically to prevent a failure that happens two steps later.

1. Confirm your build and version. Open Information → System Information and check the RetroArch version and, crucially, your CPU architecture. Rationale: every later download must match this. If you are below 1.22.2, update now to dodge the 1.22.0 shader bug.
2. Identify your platform and architecture precisely. x86_64, aarch64, and armv7 are not interchangeable. Rationale: the buildbot serves separate binaries per arch, and grabbing the wrong one is the number-one cause of "failed to open libretro core."
3. Open the Online Updater. From the main menu, Online Updater. Rationale: this is the one screen that fetches everything RetroArch needs to describe cores to itself.
4. Run "Update Core Info Files" first. Before touching the Core Downloader, update the info-file manifest. Rationale: the downloader reads these to know what exists for your platform. Skip this and the downloader is empty, or lists cores that then refuse to load as "unrecognized." This is the single most-missed step in the entire process.
5. Update assets, databases, and controller profiles. Still in Online Updater, refresh Assets, the Database/Cheats, and Controller Profiles. Rationale: playlists (scanned game lists) depend on the databases, and your gamepad mapping depends on the autoconfig profiles.
6. Open the Core Downloader. If the menu item is missing, go to Settings → User Interface → Menu Item Visibility → Show Core Downloader and enable it. Rationale: some builds hide it by default, and people assume the feature is gone.
7. Pick cores by system, not by name. Download the recommended core for each console you care about (the next section is the whole map). Rationale: the list is alphabetical and full of near-duplicates; choosing blind gets you a fast-but-inaccurate core when you wanted the reference one, or vice versa.
8. Verify the core appears under Load Core. Go to Load Core and confirm each download is listed. Rationale: a download that succeeded but does not appear here means an architecture or info-file mismatch — catch it now, not mid-game.
9. Place any required BIOS in the System directory. For PS1/PS2/Sega CD and similar, drop the correctly-named firmware into system/. Rationale: these cores hard-fail without it, and the error message rarely says "BIOS," it just closes content.
10. Load content and confirm the core binds. Load a game and watch it start. Rationale: the log (below) tells you whether the core loaded the ROM or bailed — the definitive success signal.
11. Set core options, then save an override. Open Quick Menu → Options, tune what you need, and save a core or game override (covered in its own section). Rationale: doing this per-game keeps one demanding title from degrading everything else.
12. Update installed cores periodically — and pin when needed. Use Online Updater → Update Installed Cores on a schedule, but be ready to pin a known-good build when a core regresses (yes, that happens — see N64). Rationale: cores move fast, and "latest" is not always "working."

Update Core Info Files before anything else

It deserves repeating as its own beat because it causes more support threads than any other single issue. The official install-cores guide puts the manifest step ahead of the downloader for exactly this reason. On Android the frontend now tries to auto-run the info update when the cores directory is empty, but do not rely on that on desktop — do it by hand, once, before your first download.

Platform installs: winget, apt, and webOS

The in-app downloader is not the only path. On Windows, the package manager keeps the whole frontend current. On Ubuntu/Debian a community PPA ships cores as ordinary system packages. And you can always pull a single core straight off the libretro nightly buildbot if the stable channel is behind.

# Windows (winget) — installs or upgrades the whole frontend
winget upgrade Libretro.RetroArch
# then, inside RetroArch: Online Updater -> Update Installed Cores

# Ubuntu / Debian — the PPA ships cores as system packages
sudo add-apt-repository ppa:libretro/stable
sudo apt-get update
sudo apt-get install libretro-mupen64plus-next libretro-beetle-psx-hw

# Any platform — pull one nightly core straight from the buildbot
# (example path: Linux x86_64; swap the folder for your OS/arch)
wget https://buildbot.libretro.com/nightly/linux/x86_64/latest/mupen64plus_next_libretro.so.zip
unzip mupen64plus_next_libretro.so.zip -d ~/.config/retroarch/cores/

Expected output: a healthy cores directory

After a successful round of downloads, your cores directory should look roughly like this — one library per system you chose, named for the core, not the console:

~/.config/retroarch/cores/
├── mupen64plus_next_libretro.so
├── parallel_n64_libretro.so
├── snes9x_libretro.so
├── bsnes_libretro.so
├── mesen_libretro.so
├── mgba_libretro.so
├── genesis_plus_gx_libretro.so
├── fbneo_libretro.so
├── beetle_psx_hw_libretro.so
└── swanstation_libretro.so

Choosing the Right Core Per System

This is the section people actually need and the one RetroArch refuses to provide. The Core Downloader lists cores alphabetically with no opinion, so here is the opinion. Rule of thumb: pick the accurate core on capable hardware, the fast core on constrained hardware, and never assume the newest-named core is the best one.

Nintendo: NES, SNES, and Game Boy

For the NES, Mesen is the reference: PPU-accurate, exhaustive mapper support, and a debugger baked in for the curious. For the SNES it is a two-horse race — bsnes Accuracy if you have the ~4GHz single-thread budget for cycle-accurate emulation, Snes9x everywhere else; Snes9x is the pragmatic default on any handheld and is wrong for almost nothing. Game Boy and Game Boy Color run beautifully on Gambatte or mGBA, and the Game Boy Advance answer is simply mGBA — accurate, fast, actively maintained, and it doubles as your GB/GBC core if you want one library for all three.

Sega and arcade: Genesis Plus GX and FBNeo

For Sega, Genesis Plus GX is the workhorse: 100% coverage of Mega Drive/Genesis, Sega CD, Master System, Game Gear, SG-1000, and the Pico, all in one core, descended from the old Wii homebrew emulator. The one thing it does not do is 32X — for that you switch to PicoDrive, which handles the 32X and Sega CD but is less accurate on the base Genesis. For arcade, Final Burn Neo (FBNeo) is the default: a curated, well-behaved library stretching back to 1970s hardware, and far friendlier than a full MAME set for someone who just wants games to run.

The recommendation table

Print this, tape it to the monitor. "Accurate" is your pick with cycles to spare; "Fast" is the handheld/low-power pick.

The N64 Problem

The Nintendo 64 is where RetroArch's "just pick a core" model breaks down hardest, because the recommended default and the actually-correct choice diverged in 2025. Read this section before you download anything N64-related.

mupen64plus-next and the early-2025 regression

The mupen64plus-next core is still the documented default, and for good reason: it bundles the GLideN64 high-level-emulation graphics plugin, the angrylion software renderer for reference-quality pixels, and Themaister's ParaLLEl-RDP/RSP for low-level Vulkan accuracy — one core, multiple engines you select in options. The catch is that it regressed in early 2025. Specific titles — Stunt Racer 64, World Driver Championship — stopped loading entirely. The community response was to pin the last-known-good January build rather than run "latest," which is exactly the kind of thing the Core Downloader will never tell you, because it only ever offers you the newest binary.

Parallel N64 as the accuracy fallback

When mupen64plus-next misbehaves, or when you simply want the most faithful output, switch to Parallel N64. It leans on the ParaLLEl LLE approach — a Vulkan-based low-level RDP/RSP that emulates the hardware rather than guessing at it via HLE. The trade-off is real: narrower game compatibility and a hard Vulkan requirement, so it is a desktop pick, not a budget-handheld one. But for the games it runs, it is the accuracy answer while mupen's HLE path sorts itself out.

The plugin soup, briefly explained

N64 emulation is a stack of interchangeable plugins, and mupen64plus-next exposes them as core options. GLideN64 is HLE: fast, compatible, occasionally wrong in ways that look like graphical glitches. angrylion is a pure software renderer: slow, essentially pixel-perfect, wonderful for screenshots and miserable for framerate. ParaLLEl-RDP splits the difference — hardware-level accuracy on the GPU via Vulkan compute. If a game renders wrong on the default, flipping the RDP/RSP plugin to "parallel" in the options is your first move, and we will save exactly that as a per-game override shortly.

PS1 & PS2: Beetle, LRPS2, ParaLLEl-GS

PlayStation is two very different stories. PS1 gives you a clean three-way choice scaled to your hardware. PS2 gives you one core and one uncompromising hardware requirement.

PS1's three-way: Beetle PSX HW, SwanStation, PCSX ReARMed

For the original PlayStation, pick by power. Beetle PSX HW — the Mednafen-derived core with a hardware renderer — is the most accurate and the heaviest; it is your desktop reference, with internal upscaling, texture filtering, and PGXP geometry correction. SwanStation — a libretro port of DuckStation — sits in the middle: excellent accuracy, lighter than Beetle, a strong default on mid hardware. PCSX ReARMed is the lightweight ARM specialist that powers the budget-handheld world — it is what muOS, OnionOS, and ROCKNIX lean on to hit full speed on cheap silicon. If you are running PS1 on a sub-$100 handheld, ReARMed is not a compromise, it is the correct engineering choice.

PS2 and LRPS2: x86_64 only, no exceptions

The PlayStation 2 core is LRPS2, a hard fork of PCSX2, introduced in a January 2025 libretro blog post. Here is the fact that saves you hours of confusion: LRPS2 is x86_64-only. It runs on Windows, Linux, and macOS under Rosetta. There is no Android build, no iOS build, and no ARM-Linux build. If your Core Downloader on a Retroid or a phone does not list a PS2 core, nothing is broken — the binary does not exist for your architecture, and no amount of updating will conjure it. LRPS2 also expects a real PS2 BIOS in your system directory; the GameIndex.yaml compatibility database that used to live outside the core is now embedded inside it, so that is one fewer file to manage.

ParaLLEl-GS, the new renderer

What makes LRPS2 interesting beyond "PCSX2 in RetroArch" is ParaLLEl-GS, a fresh Graphics Synthesizer renderer written by Themaister — the same developer behind the ParaLLEl N64 work. It targets Vulkan, OpenGL, and Direct3D 11/12 via compute shaders and adds a software-accuracy path for the cases where hardware rendering diverges from real GS behavior. That is the real reason to run PS2 inside RetroArch rather than standalone PCSX2: you get RetroArch's shader chain, run-ahead, and save-state plumbing on top of a renderer built for accuracy. It is desktop-only by consequence of the x86_64 core, but on desktop it is genuinely good. If a purpose-built hardware solution is more your speed than a software core, the MiSTer Multisystem 2 FPGA overview is the other end of the accuracy spectrum — silicon-level emulation instead of a compute-shader approximation.

3DS After Citra: Azahar

If you tried to add a 3DS core in the last year and came up empty, this is why: the core you were looking for no longer exists, and its replacement is new enough that half the internet has not updated.

Citra died; here is what replaced it

Citra, the long-standing 3DS emulator and its libretro core, was taken down. The community response was consolidation: Azahar is the merge of the most prominent surviving forks — PabloMK7's Citra fork and the Lime3DS project — into a single actively-developed emulator. If a guide tells you to download the "Citra core," the guide is stale. There is no Citra core to download anymore.

Azahar 2125.0 and the first official core

The Azahar project shipped its first official libretro core in Azahar 2125.0 Alpha 4, built for six platforms in one go: Linux, Windows, macOS, Android, iOS, and tvOS. The full 2125.0 stable release is what puts the core into RetroArch's built-in Core Downloader; until stable propagates to the buildbot for your OS, you fetch the alpha directly from the GitHub releases and drop it in your cores directory manually. As a nice side effect of the rebuild, the libretro binaries are now stripped, so the Android core in particular is meaningfully smaller than the old Citra one.

What broke: encrypted titles and the CDN

Two capabilities did not survive the transition, and you should know before you assume a bad install. Azahar dropped support for encrypted games and removed the old Nintendo CDN integration — the path Citra used to pull certain system files. The project's replacement is the Artic Setup Tool for provisioning what you need legitimately. Practically, if a title that ran on old Citra refuses to load on Azahar, encryption is the first thing to check, not the core.

Overrides & Per-Game Config

This is the feature that separates a tolerable RetroArch setup from a great one, and it is criminally underexplained in the UI. Overrides let you change settings for one game, one folder, or one core without touching your global config. Get the hierarchy right and you never fight yourself again.

The precedence pyramid

RetroArch merges configuration from most-specific to least-specific. Game beats directory beats core beats global. The official overrides documentation lays out the exact file paths; here they are in the order they win:

The key design detail: overrides store only the settings that differ from the layer beneath them. A game override that changes one value is a two-line file, not a copy of your entire config. That is what makes them safe — you are never duplicating and drifting.

Core options versus overrides versus remaps

Three separate systems, and conflating them is a rite of passage. Overrides (.cfg) carry RetroArch-level settings: video driver, aspect ratio, shaders, latency. Core options (.opt per-game, or the global retroarch-core-options.cfg) carry emulator-specific settings — the N64 plugin selection, PS1 internal resolution, that sort of thing. Remaps (.rmp under config/remaps/) carry controller button mappings only. Save the right thing in the right place: an aspect-ratio tweak is an override, a renderer plugin is a core option, a button swap is a remap. Here is a per-game core-options file that pins the N64 plugins we discussed to the accurate path for one specific game:

# ~/.config/retroarch/config/Mupen64Plus-Next/Star Wars - Rogue Squadron (USA).opt
mupen64plus-rdp-plugin = "parallel"
mupen64plus-rsp-plugin = "parallel"
mupen64plus-EnableFBEmulation = "True"
mupen64plus-43screensize = "960x720"
mupen64plus-BilinearMode = "3point"

Saving changes without nuking global

The workflow that keeps you sane: change settings while a game is loaded, then Quick Menu → Overrides → Save Game Overrides. RetroArch writes only the deltas. To load them automatically next time, two config keys must be enabled — auto_overrides_enable for the .cfg overrides and game_specific_options for the .opt files. Both are on by default in a modern build, but if your per-game settings mysteriously fail to stick, these are the two switches to check. Here is a compact per-game override for a PS1 title running on Beetle PSX HW:

# ~/.config/retroarch/config/Beetle PSX HW/Gran Turismo 2 (USA).cfg
video_shader_enable = "true"
video_smooth = "false"
aspect_ratio_index = "22"
video_scale_integer = "true"

Common Pitfalls & Fixes

Every one of these has generated its own long forum thread. Read them now and skip the thread.

The empty Core Downloader (and the info-file trap)

You open the Core Downloader and it is blank, or you download a core and it "fails to load" as unrecognized. Fix: Online Updater → Update Core Info Files, then reopen the downloader. The manifest is what tells RetroArch which cores exist for your platform; without it the downloader has nothing to show or misidentifies what you fetch. This is step 4 for a reason — it is the most common failure in the entire pipeline.

Wrong architecture, silent failure

A core downloads successfully, then throws "Failed to open libretro core" or simply never appears under Load Core. Fix: confirm your CPU architecture in System Information and make sure the core matches — x86_64, aarch64, and armv7 are mutually exclusive. On handhelds this bites constantly; owners of the Retroid Pocket 3+ hit exactly this with Colecovision and a few others, where the specific arch build was missing or broken. The frontend cannot run a binary compiled for a different instruction set, and it will not translate one for you.

The PS2-on-ARM impossibility

You cannot find a PS2 core on your Android device or handheld and assume you did something wrong. Fix: nothing to fix — LRPS2 is x86_64-only and has no ARM build. Stop looking; it does not exist. This is a hardware/architecture wall, not a configuration error.

BIOS present but content still closes

PS1/PS2/Sega CD content opens and immediately closes, or the screen stays black. Fix: the BIOS is missing, misnamed, or the wrong region/hash. RetroArch checks these strictly. Put the correctly-named firmware in system/ and verify the filename against the core's documentation. A close second cause: a corrupt or bad ROM dump — swap in a known-good file to isolate which it is.

The 1.22.0 black screen

You enabled a shader and the screen went black after updating. Fix: you are on 1.22.0, which shipped that exact regression. Update to 1.22.2. This is a version bug, not a driver problem, and no amount of shader-fiddling fixes it — only the update does.

N64 game refuses to load at all

A specific N64 title (Stunt Racer 64, World Driver Championship) will not load on the latest mupen64plus-next. Fix: this is the early-2025 regression. Roll back to the pinned known-good January build, or run the game on Parallel N64 instead. "Update Installed Cores" made this worse, not better — the fix is to not be on latest for these titles.

Troubleshooting Table

Symptom on the left, the actual cause and fix on the right. If your problem is not here, it is almost certainly a variant of the architecture or info-file issues above.

Advanced Tips

Once the basics work, these are the moves that separate people who use RetroArch from people who actually control it.

Nightly buildbot and pinning a known-good core

The Core Downloader serves stable-ish builds; the nightly buildbot serves the bleeding edge, compiled per-OS and per-arch every day. Use it two ways. First, when a fix landed upstream but has not reached your downloader, grab the nightly core directly. Second — and this is the underused one — when a core regresses, the buildbot's dated archive folders let you retrieve an older, known-good binary. The N64 situation is the textbook case: pin the January build, keep a copy outside your cores directory, and re-drop it if an update overwrites it. Treat "latest" as a suggestion, not a mandate.

Manual core installation

Any core you download as a zip can be installed by hand: unzip the *_libretro.so (or .dll/.dylib) into your cores/ directory, then run Online Updater → Update Core Info Files so RetroArch picks up its description. RetroArch also supports installing a core straight from a file with Load Core → Install or Restore a Core, which handles the copy for you. This is exactly how you sideload the Azahar 3DS alpha before it reaches the downloader, or any core the buildbot has but your build's downloader has not yet listed.

Handhelds: know your arch, respect the ceiling

On ARM handhelds the rules tighten. Your core options are whatever was compiled for your instruction set — armv7 versus aarch64 is a hard line, and the community webOS core repository (roughly 170-plus armv7 cores as of its December 2025 rebuild, plus experimental aarch64) is a good reference for what actually builds for ARM. Lean on the lightweight cores by design: PCSX ReARMed for PS1, Snes9x for SNES, Genesis Plus GX for Sega. Do not port a desktop mindset onto a handheld — bsnes Accuracy and LRPS2 are not options there, and the cores that are options were chosen precisely because they run. If you are deciding between devices on that basis, the Retroid Pocket comparison maps chips to real-world core performance.

A Complete Working Config

Here is the payoff: a reference configuration you can adapt. It assumes an x86_64 desktop on RetroArch 1.22.2 with Vulkan, and it wires up the override system correctly so per-game settings actually work.

A reference retroarch.cfg fragment

These are the lines that matter for core and content management — not a full dump, just the ones people get wrong. Everything else can stay at defaults.

# ~/.config/retroarch/retroarch.cfg  (relevant lines only)

# --- Core & override behaviour ---
auto_overrides_enable = "true"       # load per-game/dir/core .cfg overrides
game_specific_options = "true"       # load per-game .opt core options
core_updater_buildbot_url = "http://buildbot.libretro.com/nightly"

# --- Paths (BIOS lives here; strict filename/hash checks) ---
system_directory = "~/.config/retroarch/system"
savefile_directory = "~/.config/retroarch/saves"
savestate_directory = "~/.config/retroarch/states"

# --- Video: global defaults, override per demanding game ---
video_driver = "vulkan"
video_scale_integer = "true"
video_smooth = "false"
aspect_ratio_index = "22"            # 22 = Core provided

# --- Latency: cheap wins, safe as global defaults ---
video_frame_delay_auto = "true"
run_ahead_enabled = "false"          # enable per-game where it helps

A per-game override in practice

Say Star Wars: Rogue Squadron renders wrong on the default N64 plugin. You load it, flip the RDP/RSP plugins to parallel in Quick Menu → Options, bump the internal resolution, then Quick Menu → Overrides → Save Game Overrides plus Quick Menu → Options → Game-options file. RetroArch writes two tiny files — one .cfg, one .opt — that touch that game and nothing else. Your global config, and every other N64 game, is untouched:

# The two files RetroArch writes for that one game:
#   config/Mupen64Plus-Next/Star Wars - Rogue Squadron (USA).cfg   -> RetroArch settings
#   config/Mupen64Plus-Next/Star Wars - Rogue Squadron (USA).opt   -> core options

# .cfg contents (RetroArch-level, only the deltas):
video_scale_integer = "false"
aspect_ratio_index = "21"            # 21 = 4:3

# .opt contents (mupen64plus-next core options):
mupen64plus-rdp-plugin = "parallel"
mupen64plus-rsp-plugin = "parallel"
mupen64plus-43screensize = "1440x1080"

The final pre-flight checklist

Before you declare victory, confirm the sequence held: you are on 1.22.2 or newer; you ran Update Core Info Files before downloading; every core you installed shows under Load Core; required BIOS files sit in system/; and a game actually loads with the log confirming it. That log is the last word — if you see the core bind to content and report success, you are done, and everything after is just picking the right core per system and saving overrides where they belong.

# A healthy load in the RetroArch log (verbose):
[INFO] [Core]: Loading dynamic library ".../cores/mupen64plus_next_libretro.so"
[INFO] [Core]: Version of libretro API: 1, Compiled against API: 1
[INFO] [Environ]: SYSTEM_DIRECTORY: ".../system".
[INFO] [Content]: Loading content file "Mario Kart 64 (USA).z64".
[INFO] [Core]: Geometry: 640x480, Aspect: 1.333.
[INFO] [Core]: Content ready. Core loaded successfully.

That is the whole discipline: the frontend is not the emulator, the core is; the Core Downloader will not tell you which core is right, so you decide; and the override hierarchy means you only ever have to solve each game's quirks once. Do it in this order and RetroArch stops being a maze of near-identical menu entries and becomes what it was supposed to be — one clean shell over the best emulator for every system you own.