Install RetroArch Cores: 12 Steps, 30 Minutes (2026)

RetroArch is the most misunderstood piece of software in the emulation hobby, and the misunderstanding is structural. People install it expecting an emulator. It is not an emulator. It is a frontend, a launcher, and a runtime framework that does almost nothing useful on its own until you feed it the parts that do the actual work. Those parts are called cores, and the official project still describes them, in 2025 and into 2026, as modular plugins — with the libretro side of the house putting the count at over 200 cores spanning emulators, game engines, standalone games, and multimedia programs.

This is the part the YouTube setup videos gloss over while they show you a tidy grid of console icons. A clean RetroArch install can start with no cores present at all. You open Load Content, point it at a ROM, and the program politely informs you it has no idea what to do with it, because the thing that knows what to do with it has not been downloaded yet. That is not a bug. That is the entire architecture working as designed.

This tutorial walks through the whole core lifecycle: what a core is, what hardware and versions you need, how to choose one, how to install it through the Online Updater in roughly twelve discrete steps, how to handle the support files that the updater does not install for you, how to assign cores per game, how to pin core-level settings with overrides, and what to do when — not if — something refuses to load. Budget about thirty minutes for a first-time setup that you will not have to redo. Read the prerequisites before you touch anything; half the support tickets in this hobby are people who skipped them.

What a Core Actually Is

Start with the cleanest available definition, because the rest of the tutorial hangs on it. A 2025 starter guide put it as bluntly as anyone has: a core in RetroArch essentially just means an emulator. That is the right mental model for ninety percent of what you will do. When you load the Genesis Plus GX core, you are loading a Sega emulator. When you load Mesen, you are loading an NES/SNES emulator. RetroArch itself is the chrome around them — the menus, the input handling, the video pipeline, the save-state plumbing, the shader stack.

But "a core is an emulator" is the shorthand, not the whole truth, and an editorial owes you the whole truth. Libretro's own framing is broader: the core library spans game engines, games, multimedia programs and emulators. So a core can be the reimplemented engine for a specific game (think the open-source engine cores), a standalone game compiled to the libretro API, a media player, or — most commonly — an emulator for a console, computer, or arcade board. The libretro API is the contract. Anything that speaks it can be a core, and RetroArch will host it without caring whether it is emulating a Game Boy or rendering a Quake level.

Here is the load-bearing fact for everything below: Libretro's 2025–2026 documentation is explicit that cores are required to run any content. They are not an optional add-on, not a "plugin pack" you grab for extra systems. They are the functional heart of the platform. RetroArch with no cores is a settings menu with delusions of grandeur. This is why a fresh install feeling "empty" is correct behavior, and why the first real task of any setup is acquiring cores.

The second load-bearing fact: cores are distributed, not bundled-and-frozen. The official site notes that cores are published on the project's buildbot for supported systems, which means the ecosystem is continuously compiled and updated rather than shipped once and forgotten. You do not install cores the way you install a desktop application. You pull them from a server that is rebuilding them constantly, and you pull updates the same way. Treat them as living assets. We will come back to that when we talk about keeping them current.

Scale matters here for context. The breadth of this ecosystem is not theoretical. The community WebOS build repository, webosbrew/retroarch-cores, reported over 170 cores built as of a December 2025 rebuild — and that is one platform-specific port target, not the mainline desktop buildbot. People are recompiling this stuff for LG smart TVs. The point is that "over 200 cores" is not marketing puffery; the recompile-it-for-everything energy is real and ongoing into 2026.

Prerequisites: Versions and Hardware

Skip this section and you will pay for it later, usually around step nine. The single most common cause of "the core won't download" or "the core downloaded but won't load" is a mismatch between your RetroArch build, your platform, and your expectations. Get these straight first.

Software:

• RetroArch — latest stable. Use the most recent stable release for your platform rather than a build from two years ago that some forum post recommended. Core info files and the core ABI track the app version; old apps pull stale or incompatible cores. Get it from the official site or, on PC storefronts, the official channel — not a random mirror.
• A working internet connection for the buildbot. The entire normal install path depends on reaching the libretro buildbot. If you are behind a captive portal, a restrictive corporate proxy, or a DNS filter, the Online Updater will simply show empty lists or time out. Confirm you can reach the network before you blame the software.
• Knowledge of your exact build channel. This is not optional trivia. As Libretro's docs spell out, some builds disable the in-app Core Downloader entirely — the Ubuntu PPA package path being the headline example. If you installed via the PPA, you cannot install cores from inside RetroArch at all; you must use the package manager. More on this in the steps and the pitfalls.
• BIOS/system files where required (separately). Cores are emulators; some systems (PS1, certain Sega CD, etc.) need BIOS files that RetroArch does not and will not distribute. The core downloads; the BIOS is your problem. Have the directory ready.

Hardware (realistic 2026 floor, by ambition):

Use case	CPU / SoC	RAM	Notes
8/16-bit (NES, SNES, Genesis, GB/GBC)	Any modern x86, or a Pi-class ARM SoC	2 GB+	Cores like Genesis Plus GX and Mesen are featherweight. A potato runs these.
Accuracy-first SNES (bsnes / higan-derived)	Mid-range desktop CPU (single-thread matters)	4 GB+	Cycle-accurate cores trade CPU for correctness. This is the point of them.
Arcade (MAME)	Varies wildly by romset/year of hardware	4 GB+	A 1980s board is trivial; late-90s 3D arcade hardware is not.
5th/6th-gen 3D (PS1, N64, Saturn, Dreamcast)	Reasonably current desktop CPU + GPU	8 GB+	GPU and driver (Vulkan/GL) start to matter here.
Embedded targets (WebOS TVs, handhelds)	Device-specific ARM SoC	Device-bound	Use platform builds (e.g. the webosbrew repo) — desktop cores will not load.

The honest summary: for the systems most people actually care about — the 8- and 16-bit libraries — hardware is a non-issue in 2026, and your bottleneck is configuration knowledge, not silicon. The hardware question only becomes interesting once you reach the 3D generation, and at that point your core choice and your video driver matter more than raw clock speed.

Picking a Core for Each System

Most systems have more than one core. This is a feature that masquerades as a problem. The recurring guidance across 2025–2026 sources converges on the same three-axis decision, and it is worth internalizing before you download anything: choose a core for accuracy, compatibility, and device performance — in whatever priority order your hardware allows.

• Accuracy means how faithfully the core reproduces the original hardware's behavior, including the timing quirks games relied on. Cycle-accurate cores (the bsnes family for SNES, Mesen for NES) are the gold standard and the most expensive.
• Compatibility means how much of the library runs without breakage. A fast core that mangles half your games is worse than a slow one that runs everything.
• Performance is the device tax. On a weak SoC you may deliberately pick a less accurate, faster core because the accurate one drops frames. That is a legitimate trade, not a sin.

Recent guides point users toward known-good defaults, and these are sane starting points rather than dogma. MAME for arcade (with the caveat that arcade is a romset-versioning minefield), bsnes for accuracy-first SNES, Genesis Plus GX for Sega 8/16-bit, and Mesen for NES are the names that keep coming up, and they keep coming up because they are correct. The libretro wiki maintains per-core documentation; when you are unsure whether a core is the maintained choice for a system, the libretro docs are the authority, not a Reddit thread from 2019.

A practical rule for beginners: install the recommended core, get one game running, and only then start collecting alternates. The temptation is to download every core for a system "just in case." Resist it. Each core is a separate file with separate settings and separate failure modes, and a directory full of cores you have never tested is a directory full of future confusion.

Installing Cores in 12 Steps

This is the core of the tutorial, no pun available. The official install path is built around RetroArch's Online Updater. The official site phrases the canonical route as Main Menu → Online Updater → Update Cores, while Libretro's documentation describes the in-app route as Online Updater → Core Downloader (sometimes labeled "Core Downloader" or reached via Load Core → Download a Core). Both reach the buildbot; the menu labels have drifted slightly across versions and platforms. Follow the path your build actually shows.

Each step below includes the rationale, because doing the steps without understanding them is how you end up unable to fix anything.

1. Launch RetroArch and confirm your build channel first. Rationale: if you are on the Ubuntu PPA, steps 3–7 do not apply to you (jump to the pitfalls section). Everyone else continues. Knowing your channel up front saves you from clicking a menu that does not exist on your build.
2. Open the Main Menu and find Online Updater. Rationale: this is the gateway to the buildbot. If Online Updater is entirely absent, your build was compiled without networking support — that is a build problem, not a settings problem, and no amount of clicking fixes it.
3. Select "Update Core Info Files" before anything else. Rationale: the info files are the metadata that tells RetroArch what each core is, what it emulates, and what extensions it handles. Updating them first means the Core Downloader list renders correctly and your cores get proper names instead of cryptic filenames. People who skip this get a download list that looks broken.
4. Enter the Core Downloader (a.k.a. "Core System Files Downloader" / Load Core → Download a Core). Rationale: this is the live list of cores available from the buildbot for your platform. The list is platform-filtered server-side, which is why your friend's Windows list differs from your handheld's.
5. Scroll to the system you want and read the core names. Rationale: systems with multiple cores list them together. This is where your accuracy/compatibility/performance decision from the previous section pays off. Pick deliberately.
6. Select a core to download it. Rationale: the download is small and fast; cores are compact shared libraries, not multi-gigabyte packages. RetroArch fetches the binary and drops it into your cores directory automatically.
7. Watch for the on-screen confirmation. Rationale: RetroArch reports the download and extraction inline. If you see an error or the notification never appears, the buildbot was unreachable or the platform filter excluded that core — do not assume success.
8. Repeat for each system you actually own ROMs for. Rationale: resist the completionist urge (see the previous section). Download what you will use this week. You can always come back; the buildbot is not going anywhere.
9. Run "Update Cores" / "Update Installed Cores" to confirm everything is current. Rationale: a 2025 Retro Game Corps guide specifically recommended using Update Installed Cores periodically, because cores are maintained assets updated independently from the RetroArch app itself. Running it now establishes a clean baseline.
10. Go to Load Core and verify your cores appear in the list. Rationale: this is the proof step. If the core is in the cores directory and the info file is current, it shows here with a human-readable name. If it does not appear, your info files are stale (go back to step 3) or the file landed in the wrong directory.
11. Load a core, then Load Content, and point it at a known-good ROM. Rationale: loading the core first, content second, is the deterministic path. It removes the "which core should I use" ambiguity for your first test and isolates whether the failure is the core or the content.
12. Confirm the game boots, then save your configuration. Rationale: a booting game proves the whole chain — buildbot, info files, core binary, content, video, input. Saving config (or enabling save-on-exit) means you never repeat steps 1–11.

The menu navigation in shorthand, for reference:

Main Menu
 └─ Online Updater
     ├─ Update Core Info Files        # step 3 — do this FIRST
     ├─ Core Downloader               # step 4 — pick + download cores
     │   └─ [System] ▸ [Core name]    # step 5/6 — accuracy vs perf choice
     └─ Update Installed Cores        # step 9 — keep them current

Main Menu
 └─ Load Core ▸ [your core]           # step 10/11
 └─ Load Content ▸ [your ROM]         # step 11

Expected output when a core download succeeds — RetroArch shows an inline notification of roughly this shape:

Downloading core: Genesis Plus GX
Extracting: genesis_plus_gx_libretro.so
Update complete: Genesis Plus GX

And when you load it and boot content, the log (Settings → Logging at INFO level, or the terminal on a CLI launch) reads roughly:

[INFO] [Core]: Loading dynamic library: "genesis_plus_gx_libretro.so"
[INFO] [Core]: Version of libretro API: 1
[INFO] [Content]: Loading content file: "Sonic The Hedgehog.md".
[INFO] [Core]: Geometry: 320x224, aspect: 1.333.
[INFO] [Video]: Set video size to: 960x672.

That sequence — library loaded, API version reported, content loaded, geometry set — is what success looks like under the hood. Memorize the shape of it. When something breaks, the line where this sequence stops is the line that tells you what broke.

The Support Files Nobody Mentions

Here is where the slick setup videos earn their keep and the lazy ones leave you stranded. Cores do not arrive fully dressed. A 2025 starter guide walked through a whole battery of metadata and support updates that belong in any modern RetroArch setup, and the reason they exist is that the buildbot ships the core while the supporting assets ship separately. Run all of these from Online Updater, ideally right after your cores:

• Update Core Info Files — already covered; the metadata layer. Without it, cores have no names, no extension associations, and no database links.
• Update Assets — the menu graphics, icons, and fonts. Skipping this is why some installs look like a broken website from 2003.
• Update Controller Profiles — autoconfig profiles so your gamepad is recognized and mapped without manual button-binding. This is the difference between "plug in, play" and "why is jump mapped to nothing."
• Update Cheats — the bundled cheat database, per system. Optional, but it is one click and you may as well have it.
• Update Databases — the RDB files that let RetroArch identify your ROMs by hash and build proper playlists with box art and titles. This is what makes the pretty grid view actually work.
• Update Shaders — the shader presets (CRT filters, scanlines, etc.). Without them, the shader menu is empty and you will wonder why everyone else's screenshots look like a Trinitron.

The order is forgiving except for one rule: Update Core Info Files should come before or alongside your core downloads so names and associations resolve. Everything else can be batched. Do all six in one sitting and you will not think about them again for months — and when you do think about them, it is because you ran Update Installed Cores and want the info files to match, which is itself a one-click fix.

A blunt editorial note: the reason this section exists at all is that RetroArch's modularity, which is its great strength, is also its great usability tax. A monolithic emulator ships everything in one binary. RetroArch ships a framework and asks you to assemble the rest. The six updates above are the assembly. Treat them as part of installation, not as optional polish.

Per-Game Core Assignment

Once you have multiple cores installed for overlapping or distinct systems, core selection becomes part of ordinary frontend use rather than a one-time setup chore. A 2026 setup guide demonstrated this directly: after you select a game, RetroArch can prompt you to choose which core to use when more than one installed core can handle that content. This is per-game core assignment, and it is the moment the modular architecture stops being an abstraction and starts being something you click.

There are two ways content gets matched to a core:

1. You picked the core first (Load Core → Load Content). Deterministic. RetroArch uses exactly the core you chose. This is the recommended path for testing and for any system where you have a strong core preference.
2. You launched the content first (or from a playlist). RetroArch looks at the content, checks which installed cores claim that extension/system via their info files, and either uses the single match or — if several cores qualify — prompts you to choose. That prompt is the per-game assignment moment.

Once you choose a core for a specific playlist entry, RetroArch remembers the association for that entry. This is why a well-built playlist eventually stops asking: each game has a remembered core. It is also why, if you ever change your mind about which core a system should use, you may need to clear or reset the per-entry association — the frontend is doing exactly what you told it the first time.

The practical upshot for 2026 users: you can run, say, two different SNES cores side by side — an accurate one for the games that need it and a fast one for the games that do not — and assign each game to the right core individually. That is not an exotic power-user move anymore. It is a documented, prompted, front-and-center part of the UX. The modular design that makes a fresh install feel empty is the same design that makes this granularity trivial.

Core Overrides and Run-Ahead

Per-game core selection is one thing; per-core configuration is another, and this is where overrides come in. RetroArch's settings cascade: global settings sit at the bottom, and you can layer increasingly specific overrides on top — Core Overrides (apply to every game using a given core), Content Directory Overrides, and Game Overrides (a single game). The override system is the correct way to make a setting stick without polluting your global config.

The canonical example, and the one the 2025 Retro Game Corps guide built a whole section around, is latency tuning via Run-Ahead to Reduce Latency. Run-ahead works by running the emulated core one or more frames into the future and presenting that frame now, hiding the inherent input lag of the original hardware plus the emulation pipeline. It is CPU-expensive — you are literally running the core extra times per displayed frame — which is exactly why you want to control where it applies.

The guide's recommendation is the right pattern: tune run-ahead for a core, then save a Core Override so the latency setting applies to all games using that emulator core. You set it once for, say, Genesis Plus GX, save the override, and every Genesis game inherits low-latency behavior without you touching global settings or re-entering it per game. This is the concrete demonstration of why core-level configuration is a distinct, useful layer rather than an afterthought.

To set a core override in practice: load a game with the target core, open the Quick Menu (the in-game RetroArch menu), adjust your settings — run-ahead under Latency, plus whatever else — then go to Overrides and choose Save Core Overrides. RetroArch writes a per-core config file that it loads automatically whenever that core runs. A minimal core override file looks like this:

# config/Genesis Plus GX/Genesis Plus GX.cfg
# Auto-loaded whenever the Genesis Plus GX core runs.

run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"
video_shader_enable = "true"
video_smooth = "false"

A note on run_ahead_secondary_instance: enabling it runs a second core instance for the look-ahead, which is more compatible (it avoids audio/visual glitches from the rewind-and-replay approach) at higher CPU cost. On capable hardware leave it on; on a weak SoC you may turn it off or drop run-ahead frames to keep full speed. This is, again, the accuracy-versus-performance trade reappearing — it never really goes away, it just moves down the stack to per-setting granularity.

Common Pitfalls and Fixes

Five failure modes account for the overwhelming majority of "RetroArch cores don't work" complaints. Each is avoidable once you know it exists.

Pitfall 1 — The Ubuntu PPA build has no Core Downloader. This is the big one, and it is documented. Libretro's docs state that if RetroArch is installed through the Ubuntu PPA, core installation must happen through the package manager instead of the RetroArch interface; the in-app downloader is disabled on that build. Users spend hours hunting for a menu that was deliberately removed.
Fix: install cores via apt instead. The packages are named on a per-core basis. For example:

# Ubuntu PPA build: cores come from the package manager, NOT the app.
sudo apt update
sudo apt install libretro-genesisplusgx
sudo apt install libretro-mesen

# Discover available core packages:
apt search libretro-

If you would rather have the in-app downloader back, the alternative is to install RetroArch through a build channel that ships it — but do not mix the two on one machine and expect sanity.

Pitfall 2 — Stale or missing core info files. Symptom: cores download but show as cryptic filenames, won't associate with content, or the Core Downloader list looks empty or garbled.
Fix: run Online Updater → Update Core Info Files, then restart RetroArch. The info layer is independent of the cores themselves and falls out of sync after app or core updates.

Pitfall 3 — Buildbot unreachable, blamed on the app. Symptom: empty download lists, hanging downloads, "failed" notifications. The entire normal install path depends on reaching the libretro buildbot, and captive portals, proxies, and DNS filters silently break it.
Fix: confirm general internet access, disable restrictive filtering or VPN split-tunneling, and retry. If you genuinely cannot reach the buildbot, manual core installation (advanced section) is your fallback.

Pitfall 4 — Wrong-platform core binary. Symptom: a core that loads on your desktop fails to load on your handheld, TV, or ARM device. Cores are compiled per platform; a Windows .dll, a Linux .so, and an Android core are not interchangeable, and embedded targets need purpose-built binaries.
Fix: only ever use cores from the downloader on the device itself, or from a platform-matched repo. The webosbrew/retroarch-cores rebuild from December 2025 exists precisely because WebOS needs its own compiled cores; desktop binaries will not load there.

Pitfall 5 — Missing BIOS / system files. Symptom: the core loads, the content loads, then the game black-screens or errors. The core is an emulator; some systems require BIOS files RetroArch does not distribute.
Fix: place the required BIOS files in your configured system directory with the exact filenames the core expects (the libretro docs list them per core), then reload. The core was working the whole time — it was waiting on files only you can supply.

A sixth, for good measure: downloading every core "to be safe." Symptom: a cluttered Load Core list, multiple cores claiming the same content, and per-game prompts you cannot make sense of. Fix: install only what you use; delete cores you are not testing. Curation is a feature you apply yourself.

Troubleshooting Table

When the boot log stops before that clean success sequence from the install section, the line it stops on maps to a fix. Use this table as a triage chart.

Symptom	Likely cause	Fix
No "Core Downloader" menu at all	Ubuntu PPA build (downloader disabled) or no-network build	Install cores via apt install libretro-*, or switch to a build that ships the downloader
Download list is empty	Buildbot unreachable (proxy/captive portal/DNS) or platform with no listed cores	Confirm internet, disable filtering/VPN, retry; verify cores exist for your platform
Core downloads but doesn't appear in Load Core	Stale info files or core in wrong directory	Run Update Core Info Files, restart; check Settings → Directory → Cores
Core shows as a cryptic filename	Missing/outdated core info files	Online Updater → Update Core Info Files
Core loads, content fails to boot (black screen)	Missing BIOS / system files	Place exact-named BIOS in system directory (see libretro per-core docs)
Core fails to load: "failed to open dynamic library"	Wrong-platform binary or corrupted download	Re-download on the target device; use platform-matched core (e.g. WebOS repo)
Game runs but feels laggy	No latency tuning	Enable Run-Ahead, save as Core Override for that core
Settings won't stick between sessions	Save-on-exit off, or editing wrong config layer	Enable config save-on-exit; use Core/Game Overrides, not global, for per-core tweaks
Playlist shows no box art / wrong titles	Databases not updated	Online Updater → Update Databases, then rescan content
Multiple cores fight over the same game	Too many overlapping cores installed	Delete unused cores; set deliberate per-game core assignment

The meta-lesson of this table: nearly every "core" problem is actually a metadata, network, platform, or layering problem. The core binary itself is rarely the culprit — it is a compiled, tested artifact from the buildbot. What breaks is the connective tissue around it. Debug the tissue.

Advanced Tips

Keep cores current on a schedule, not a whim. Because cores are maintained assets distributed from a continuously-rebuilding buildbot, "Update Installed Cores" is not a one-time action. The Retro Game Corps guidance to run it periodically is correct. A reasonable cadence is monthly, or whenever you update the RetroArch app itself — and when you do, run Update Core Info Files in the same sitting so metadata tracks the binaries.

Understand the buildbot as your source of truth. The cores you download come from the libretro buildbot, organized by platform. Knowing this lets you reason about availability: if a core is not in your in-app list, check whether it exists for your platform on the buildbot at all. The buildbot is the canonical distribution point and the reason the ecosystem stays current rather than ossifying.

# Conceptual layout of where cores live and come from:
#
#  libretro buildbot  ──(Online Updater)──▶  your device
#       │                                        │
#       ├─ nightly/                              ├─ cores/
#       └─ stable//                    │    genesis_plus_gx_libretro.so
#                                                │    mesen_libretro.so
#                                                └─ info/
#                                                     genesis_plus_gx_libretro.info
#                                                     mesen_libretro.info

Manual installation as a fallback. When the in-app downloader is unavailable (PPA build, no network on the device, or a core only published in a platform repo), you can place the core binary directly into the cores directory and the matching .info file into the info directory. This is exactly what the package-manager path and the platform repos automate. The webosbrew/retroarch-cores repository is the model here: a maintained set of platform-compiled core binaries you deploy to the device when the normal path does not serve you.

Use the override cascade deliberately. Think of configuration as four layers — global, then core, then content-directory, then per-game — each overriding the one below. Put broad preferences (video driver, default audio) in global. Put per-emulator behavior (run-ahead, core-specific options) in Core Overrides. Reserve Game Overrides for the one weird game that needs special treatment. This keeps your global config clean and your per-system behavior predictable, and it means a single global change does not silently undo a setting you tuned for one core.

Run-ahead is a scalpel, not a hammer. One frame of run-ahead removes a large chunk of perceived latency for modest cost. Two or more frames help further but cost more CPU and can occasionally desync games that were not designed for it. Tune per core, verify the specific games you play, and save the override. Do not enable five frames globally and wonder why your weak handheld stutters.

Treat info files as a first-class diagnostic. When anything about core identity or content association looks wrong — names, extensions, which core claims a game — your first move is Update Core Info Files. The info layer is the most common silent point of failure precisely because it is invisible until it desyncs. The libretro documentation and the per-core wiki pages document what each core's info file declares; when in doubt, that is the reference.

Source code is the final authority. For genuinely deep questions — ABI versions, build flags, why a core behaves a certain way on your platform — the RetroArch and core source lives on GitHub. The libretro/RetroArch repository is the canonical app source, and individual cores have their own repos under the libretro organization. When a forum answer and the source disagree, the source wins.

A Complete Working Configuration

Here is a complete, commented configuration that ties the whole tutorial together: a sane global retroarch.cfg foundation plus a representative core override. This is not a maximal config — it is a clean, working baseline you can paste, adjust, and grow from. The global file lives at the root of your RetroArch config directory; the override lives under config/<Core Name>/ and auto-loads with that core.

Global retroarch.cfg (foundation):

# ── retroarch.cfg — global foundation ──────────────────────
# Keep this clean. Put per-core behavior in Core Overrides,
# not here. Global is the bottom of the cascade.

# Directories — where cores, info, system files, and saves live.
libretro_directory = ":\cores"
libretro_info_path = ":\info"
system_directory   = ":\system"          # BIOS files go here
savestate_directory = ":\states"
savefile_directory  = ":\saves"

# Video — pick a driver your platform supports well.
video_driver = "gl"                        # or "vulkan" / "d3d11"
video_fullscreen = "false"
video_vsync = "true"
video_smooth = "false"                     # integer/sharp by default

# Audio.
audio_driver = "alsa"                       # platform-dependent
audio_enable = "true"
audio_sync = "true"

# Config behavior — make settings persist.
config_save_on_exit = "true"
save_file_compression = "true"
savestate_auto_save = "false"

# Updater — keep cores and metadata current from the buildbot.
core_updater_auto_extract_archive = "true"
menu_show_online_updater = "true"

# Latency — global default OFF; enable per-core via overrides.
run_ahead_enabled = "false"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

Core override config/Genesis Plus GX/Genesis Plus GX.cfg (per-core layer):

# ── Core Override: Genesis Plus GX ─────────────────────────
# Auto-loaded whenever this core runs. Overrides the global
# file above for these specific keys only. Saved via:
#   Quick Menu → Overrides → Save Core Overrides

# Low-latency for all Genesis/Master System/Game Gear games
# running on this core (the Retro Game Corps pattern).
run_ahead_enabled = "true"
run_ahead_frames = "1"
run_ahead_secondary_instance = "true"

# Visuals for this core's systems.
video_shader_enable = "true"
video_smooth = "false"

# Core-specific options (exposed by the core's info/options).
genesis_plus_gx_region_detect = "auto"
genesis_plus_gx_no_sprite_limit = "disabled"   # keep authentic flicker

The discipline this configuration encodes is the whole point of the tutorial: global stays neutral and clean, run-ahead is off by default so it never taxes a system that does not need it, and the per-core override turns it on exactly where you want it. Add more core override files as you tune more emulators — one folder per core, one file per core, each overriding only what it needs. That is RetroArch's modularity working for you instead of against you.

Final editorial verdict: RetroArch's reputation for being confusing is earned, but the confusion is almost entirely front-loaded into this one concept — that cores are separate, required, distributed plugins rather than built-in emulators. Internalize that, run the six support-file updates as part of installation rather than as optional polish, learn the override cascade, and the platform stops fighting you. Over 200 cores, continuously rebuilt on a buildbot, spanning emulators and engines and media programs, all hosted by one frontend that ships none of them by default — once you see why that is a design and not an oversight, the rest is just clicking the menus in the right order. Which, conveniently, is what the twelve steps above are for.