{"id":34,"date":"2022-08-03T05:41:46","date_gmt":"2022-08-03T05:41:46","guid":{"rendered":"https:\/\/www.cstroik.com\/?p=34"},"modified":"2023-03-27T05:32:52","modified_gmt":"2023-03-27T05:32:52","slug":"retroarch-slowstart-guide","status":"publish","type":"post","link":"https:\/\/www.cstroik.com\/index.php\/2022\/08\/03\/retroarch-slowstart-guide\/","title":{"rendered":"RetroArch Slowstart Guide"},"content":{"rendered":"\n

Part 1: Background<\/strong><\/h3>\n\n\n\n

RetroArch is a frontend for the the libretro API. The idea behind libretro was to separate the higher level tasks of an emulator such as the video drivers, the configuration, input, etc. from the actual emulator itself. A libretro core will, for the most part, only handle actual emulation.<\/p>\n\n\n\n

Before libretro every emulator needed to handle everything on its own. This overcomplicates things because it means every single emulator would need its own implementation of everything and they were almost guaranteed to be different, it was unlikely that your NES emulator would handle input the same way as your SNES emulator. It was possible that your GBA emulator would support a graphics API that worked well with your GPU but possible or even likely that your n64 emulator would not. Your GameCube emulator might have a great UI that is easy to use with a controller, but your PSX emulator would need a keyboard and mouse. Your SNES emulator is likely very mature and feature rich, but your Sega Genesis emulator could be barebones and lack quality of life features other emulators have.

Libretro cores have, except in special circumstances, none of these features. They are all equally dumb. Instead these features are handled by the frontend. Since all libretro cores are equally dumb, any frontend that can use one libretro core can use them all. And so, if your frontend has one feature, that means that all of your libretro cores have that feature and that that feature can be set once in the frontend and apply to every core.<\/p>\n\n\n\n

There are several libretro frontends but the main, most common, and most used frontend is RetroArch. RetroArch has been developed alongside libretro from nearly the beginning. For most people libretro is RetroArch and RetroArch is libretro. RetroArch is by far the most feature complete frontend. <\/p>\n\n\n\n

RetroArch and libretro, as a result of being developed together by mostly the same developers, both follow the same design philosophies. They are free, open source software. The vast majority of both are written in highly portable C, with the goal of having them run on all kinds of hardware and software. RetroArch and libretro cores can be built and run on Windows as well as Linux, but they can also run on x86, ARM, or even more exotic hardware. They can be built for Windows 98, Android or iOS, or even more obscure operating systems like QNX. <\/p>\n\n\n\n

This guide though is for a standard x86-64 install on a modern Windows machine.<\/p>\n\n\n\n

Part 2: Initial Preparation<\/h3>\n\n\n\n

First download <\/strong>the current stable Windows build of RetroArch from https:\/\/www.retroarch.com\/?page=platforms<\/a><\/p>\n\n\n\n

On a modern Windows computer you will want the Windows Installer (64 bit)
Run the installer, the default install location is C:\\RetroArch-Win64, you can change this but do not put it in Program Files, Program Files (x86) or any other protected folder on Windows. Modern Windows (since Vista), limits write permissions in these folders which can cause a problem later when RetroArch needs to be able to write to its own folder.<\/p>\n\n\n\n

Now that RetroArch is installed we need to add bios files<\/strong> to it. Some emulators need a bios from the original console to run. These are not included with RetroArch for copyright reasons.<\/p>\n\n\n\n

Download<\/strong> bios files here<\/p>\n\n\n\n

Retroarch Bios system<\/a><\/a><\/div>\n\n\n\n

Open the directory you installed RetroArch to. For the sake of this guide we will assume C:\\RetroArch<\/p>\n\n\n\n

Open the subfolder in C:\\RetroArch\\system and copy<\/strong> the extracted contents of the rar file we just downloaded to it<\/p>\n\n\n\n

First Run<\/strong><\/p>\n\n\n\n

Now we’re ready to run RetroArch for the first time. run retroarch.exe<\/strong> it will load RetroArch with the default UI “ozone – black basic” which is likely what you’ll want to use on PC anyway.<\/p>\n\n\n\n

At this point RetroArch will generate the default configuration, this will be a file called retroarch.cfg, this file is very important and, technically, can be edited manually to change almost anything about the way RetroArch runs. You’ll know this was successful because RetroArch will notify you of it. The only way this could fail is if we installed RetroArch to a folder it does not have permission to write to.<\/p>\n\n\n\n

\"\"
Successfully written configuration<\/figcaption><\/figure>\n\n\n\n

Almost every setting you change in RetroArch will write to this file. Importantly, RetroArch does NOT automatically save configuration changes to this file<\/strong>, by default we will have to manually save. This is not ideal, luckily we can change this behavior to save configuration on exit. Though it is a good habit to manually save changes, especially when you are changing many things, in case RetroArch does not shut down properly for some reason. So we will set that first in the “Settings” panel<\/p>\n\n\n\n

Right now we are using keyboard controls, Enter moves forward a menu and confirms changes, backspace goes back, esc twice will close the program.<\/p>\n\n\n\n

\"\"
RetroArch Settings Panel<\/figcaption><\/figure>\n\n\n\n

Navigate to Settings > Configuration<\/strong> and set the following two options;<\/p>\n\n\n\n

Configuration > Save Configuration on Quit \u2013 On
Configuration > Save Remap Files on Quit \u2013 On<\/strong><\/p>\n\n\n\n

Return to Main Menu > Configuration File<\/strong> and select Save Current Configuration<\/strong><\/p>\n\n\n\n

Part 3: Basic Configuration<\/h3>\n\n\n\n

Joypad controls <\/strong><\/p>\n\n\n\n

Plug in your controller and go to Settings > Input<\/strong><\/p>\n\n\n\n

For joypads RetroArch will use the X Input controller driver by default. Input type can be changed in Settings > Drivers > Controller<\/strong> but the only two relevant input drivers for Windows are xinput and dinput. Xinput recognizes all controllers as xbox 360 controllers. This likely does not have to be changed at all. Xinput has far better compatibility and is the newer standard. Xinput maps triggers as axis though which can matter. This is more useful to know for other emulators that handle this poorly like some standalone builds of Snes9x which have trouble with L+R mapped as axis.<\/p>\n\n\n\n

dinput is still used by default for keyboards though.<\/p>\n\n\n\n

First setup player 1’s controller in Settings > Input > Port 1 Controls<\/strong><\/p>\n\n\n\n

\"\"
Input Menu<\/figcaption><\/figure>\n\n\n\n

Hopefully the controller is automatically detected, though if you have more than one controller connected you may need to specify the device to use with the “Device Index<\/strong>” option. Left and Right on the keyboard to find the device, then we move onto setting each key. The controller may automatically “work” with an autoconfig profile, though manually setting everything doesn’t take long and is a good habit to be sure things work the way you expect them to.<\/p>\n\n\n\n

It’s important to note RetroArch buttons may not<\/strong> match the button layout of your controller. With RetroArch you are configuring an abstracted, virtual controller called the “RetroPad.” This generally follows the Nintendo controller layout, not xbox. What this means is, to the RetroPad, the B button will always represent the bottom left button to the emulator core regardless of what the B button is on your controller. If you configure B to be the actual B on an xbox controller your buttons will be in the wrong place.<\/p>\n\n\n\n

This configuration will not be completely universal for all cores though, later we will reassign some keys with Remaps for consoles where this control scheme doesn’t work very well.<\/p>\n\n\n\n

Next we will set up controller hotkeys<\/strong> in Settings > Input > Hotkeys<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"
Hotkey menu<\/figcaption><\/figure>\n\n\n\n

We can now navigate with just the controller, from this point on we probably won’t need to use the keyboard anymore except for very specific situations, especially after we finish configuring hotkeys.<\/p>\n\n\n\n

For hotkeys, not all of these will need to be set. It will depend on which games you want to play and which features you need. Rarely used buttons like “Next Disc” are better set with keyboard inputs<\/p>\n\n\n\n

First set Menu Toggle Controller Combo <\/strong>– When we’re in a game we’ll need to go back to the menu to do some things like save state, load state, switch games, etc. To do this we’ll use the button combination you select here<\/p>\n\n\n\n

Hotkey enable<\/strong> \u2013 This is the button that must be pressed for hotkeys to work (so you can use hotkeys on a controller), I usually use \u201cselect.\u201d What this means is, if it’s set to select, and you set fast forward to the right trigger you will need to press select and right trigger in order to fast forward<\/p>\n\n\n\n

Fast-Forward <\/strong>– There are two types of fast forward, hold and toggle. Should be pretty self explanatory, hold will fast forward as long as the button is held down, but toggle will fast forward until the button is hit a 2nd time.<\/p>\n\n\n\n

Rewind<\/strong> – I use the left shoulder button<\/p>\n\n\n\n

Make a note of what Menu (Toggle)<\/strong> is set to in case the controller becomes disconnected at some point and we need to get back to the menu, the default is F1<\/strong>.<\/p>\n\n\n\n

Settings > Input > Menu Controls<\/strong><\/p>\n\n\n\n

\"\"
Menu Controls<\/figcaption><\/figure>\n\n\n\n

Here we want to set All Users Control Menu<\/strong>, this is so player 2 can adjust things on the menu too. Other options are usually fine as is and self explanatory. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Video Settings<\/strong><\/p>\n\n\n\n

\"\"
Video Settings Menu<\/figcaption><\/figure>\n\n\n\n

Settings > Video<\/strong><\/p>\n\n\n\n

The majority of the most important performance related settings will be here, they\u2019re also some of the hardest to understand. If you have performance problems you will spend most of your time here.<\/p>\n\n\n\n

CRT SwitchRes<\/strong> \u2013 This tells RetroArch to take the exact video timing from a core and use that to output with native resolution 15KHz modelines for a standard or arcade CRT. This is how actual retro consoles worked and, on a real CRT from the 90s will look like a real console.
On a modern display this will display broken garbage, it is only useful if you have an old CRT.<\/p>\n\n\n\n

Threaded Video<\/strong> – Runs the video driver on its own thread to avoid video driver overhead. This is useful if your video driver has terrible performance and you cannot get better performance otherwise but will make frame synchronization impossible and increases latency (which will both be discussed shortly.) It should not be enabled unless absolutely necessary, which it wont likely be.
<\/p>\n\n\n\n

Bilinear Filtering<\/strong> \u2013 As described, slight anti-aliasing. Very little impact but inconsequential on remotely modern hardware. Personal preference, but I set to on<\/p>\n\n\n\n


Video Filter<\/strong> \u2013 Personal preference, but if you want filters, these filters run on the CPU which is not as efficient as running shaders on the GPU. Except in particular hardware configurations with a fast CPU but terrible GPU, ignore.<\/p>\n\n\n\n

Video > Output<\/strong><\/p>\n\n\n\n

\"\"
Output Menu<\/figcaption><\/figure>\n\n\n\n

Many of the settings here involve properly configuring vsync and other video settings related to synchronization. The goal here (and with most video settings) is to maintain performance but also avoid choppiness. It’s very easy to incorrectly set something and, even running at full speed, have choppy animations. Settings we will adjust next in the Synchronization<\/strong> menu are also important for maintaining smooth gameplay.<\/p>\n\n\n\n

Video<\/strong> \u2013 This is the video API you will use, not all cores support all drivers but the majority do. OpenGL and Vulkan support are by far the best supported in RetroArch, and while RetroArch does have support for DirectX there are very few situations where you would actually want to use it. The following 3 are the ones that actually matter here<\/p>\n\n\n\n


gl <\/strong>\u2013 The OpenGL 2.0+ driver (will actually run OpenGL Compatibility on modern GPUs), default because high compatibility, but not best for performance
glcore<\/strong> \u2013 The OpenGL 3.1+ driver, still high compatibility, generally a much better option than gl
Vulkan<\/strong> \u2013 Not all emulators have Vulkan support and will force glcore. Much better option on AMD gpus than gl due to AMDs poor track record of updating GL. Still generally a better setting on nvidia GPUs. Allows free \u201cHard GPU Sync\u201d lowering latency. <\/p>\n\n\n\n


Vertical Refresh Rate<\/strong> \u2013 RetroArch will sample the display to try and figure out the refresh rate on its own, vsync must be enabled while this is running. This should be very close to the Display Reported Refresh Rate. You can manually set the Vertical Refresh Rate or let Estimated Screen Refresh Rate run long enough to stabilize, then select that option in the menu to set Vertical Refresh Rate to it.
This is very important for avoiding stuttery gameplay, especially with Variable Refresh Rate screens (G-Sync, Freesync, etc.) You definitely want to do this if you do not want choppy Mario.
<\/p>\n\n\n\n

Monitor index<\/strong> \u2013 This has nothing to do with performance, if you have multiple monitors hooked up you can choose which monitor RetroArch displays on while in fullscreen mode. Actually useful especially if you got a long HDMI cable and a TV you wanna play on. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Video > Scaling<\/strong><\/p>\n\n\n\n

\"\"
Scaling Menu<\/figcaption><\/figure>\n\n\n\n

There are few important options here, unless you want to force widescreen by stretching the image.<\/p>\n\n\n\n

Aspect Ratio<\/strong> \u2013 Useful for forcing widescreen globally if that\u2019s how you like to play, usually best set to Core Provided<\/strong><\/p>\n\n\n\n


Crop Overscan<\/strong> \u2013 If you\u2019ve ever played Mario 3 in an emulator and seen junk off to the side, this is why. Leave \u201cOn<\/strong>\u201d unless you really wanna see the junk off to the side of the screen. More just an interesting thing because of how old games were designed.<\/p>\n\n\n\n

Video > Synchronization<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"
Synchronization Menu<\/figcaption><\/figure>\n\n\n\n

A lot of these settings might be worth messing around with if things just \u201cdon\u2019t seem right.\u201d If even easy to emulate games feel choppy compared to real hardware. The most common cause of this on modern hardware is the emulator core and the display\u2019s refresh rate not matching up perfectly. Because of this, many of these recommended settings may not be completely ideal on any other machine.<\/p>\n\n\n\n

On displays with Variable Refresh Rate (Freesync, etc) this is usually pretty easy to work with because of one recent setting (Sync to Exact Content Framerate.)
<\/p>\n\n\n\n

Many of these settings also affect latency, within the past few years RetroArch has gotten to a point where it is possible to reliably match or even sometimes beat latency on original hardware. Many of the settings though have downsides and are not usually worth it unless you really need incredibly low latency gaming (Kaizo Mario guys and stuff.)
<\/p>\n\n\n\n

Sync to Exact Content Framerate \u2013 On<\/strong>
If this is set to \u201con\u201d Retroarch will double, triple, whatever is necessary the actual framerate to match the core\u2019s timing with the screen\u2019s timing as reported by VRR.
<\/p>\n\n\n\n

VSync \u2013 On<\/strong>
Even with VRR this should still be set on. The only time dropping VSync is a real solution is with ancient\/low power hardware, a bad GPU, an OS with bad OpenGL support (not Windows or Linux) or serious driver bugs (this is possibly going to be an issue with Intel\u2019s new GPUs.)<\/p>\n\n\n\n

Black Frame Insertion<\/strong> \u2013 Probably keep at 0<\/strong> unless you notice blur
CRTs would draw a black screen in between each frame, this reduced motion blur (which is very obvious on older LCDs.) Sometimes on very high refresh rate screens you can still see motion blur when running low refresh rate content at a higher refresh rate. For example, no matter what you do N64 will always run at less than 60fps. In Mario 3, Mario will never have 120fps of movement. RetroArch can insert an empty, black frame (or multiple black frames) in between every frame to reduce this.<\/p>\n\n\n\n

Sometimes this is very effective, but often on good displays it\u2019s either no difference or better done by the actual display itself if it has the feature. If you notice blurry animation, it might be able to be helped by this setting, otherwise leave as is and let the actual high refresh rate do its job. <\/p>\n\n\n\n

Adaptive VSync<\/strong> \u2013 Not necessary except on weak hardware.
<\/p>\n\n\n\n

Frame Delay<\/strong> \u2013 Not worth manually adjusting because the ideal number will be different depending on the core and refresh rate.
<\/p>\n\n\n\n

Automatic Frame Delay<\/strong> \u2013 Before a frame gets to the display, the core itself has to actually generate the frame. This is true for all graphical computing, not just emulation. Once the frame is generated user input cannot affect it since it already exists, any input in between an old frame and a generated new frame is latency which on a 60hz display generally comes out to around 17ms. Frame Delay will force the core to generate the frame at a later point, meaning there is less of a gap between user input and the frame being generated and so lower latency. If the frame is generated too late it will cause sound crackling and performance issues, the gpu does not have enough time to generate the frame before it\u2019s expected to be displayed. This isn\u2019t too much of a problem though with retro emulation on newer hardware.
<\/p>\n\n\n\n

Automatic Frame Delay will aim for generating the frame at half the time the refresh rate allows for, meaning the normal 17ms will be cut in half, if it detects frame hiccups it will reduce it until the framerate becomes stable. This helps with only a minor source of latency but it also costs very little now. Usually this is best turned on, but after all other things are setup and it can be guaranteed that things otherwise run smoothly.
<\/p>\n\n\n\n

Hard GPU Sync<\/strong> \u2013 Set to On if using the Vulkan driver<\/strong>, it\u2019s a free reduction in latency.
<\/p>\n\n\n\n

Hard GPU Sync Frames<\/strong> \u2013 You want this at either 0<\/strong> or 1 if 0 does end up causing issues (performance problems, unlikely if using Vulkan)
<\/p>\n\n\n\n

VSync Swap Interval<\/strong> \u2013 This should be set to the closest number to your screens refresh rate divided by 60 <\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n

Video > Fullscreen Mode<\/strong><\/p>\n\n\n\n

\"\"
Fullscreen Mode Menu<\/figcaption><\/figure>\n\n\n\n

Most of these are pretty self-explanatory, on a modern Windows machine you will want Windowed Fullscreen Mode<\/strong> set to \u201cOn<\/strong>.\u201d Windows under most display drivers will run it in Windowed mode no matter what you have it set to anyway.<\/p>\n\n\n\n

Audio<\/strong><\/p>\n\n\n\n

Settings > Audio<\/strong><\/p>\n\n\n\n

\"\"
Audio Menu<\/figcaption><\/figure>\n\n\n\n

There\u2019s nothing to change here usually. The Audio driver is not likely to matter on Windows, Audio Latency can matter if you have audio crackling (not common on modern hardware that can emulate at fullspeed) or to get small improvements in latency not likely to matter for most people.<\/p>\n\n\n\n

You can force an audio device here which can be useful if you have different sound cards that do different things but this doesn\u2019t work with many Windows audio drivers and it\u2019s usually better to have Windows do it itself instead of RetroArch<\/p>\n\n\n\n

Latency<\/strong><\/p>\n\n\n\n

Settings > Latency<\/strong><\/p>\n\n\n\n

\"\"
Latency Menu<\/figcaption><\/figure>\n\n\n\n

The settings here are mostly the settings from other sections that also affect latency. It doesn\u2019t matter whether they\u2019re set here or in the other sections.<\/p>\n\n\n\n

The exception is \u201cRun-Ahead to Reduce Latency<\/strong>.\u201d Run ahead is a technique designed to deal with latency inherent in the actual games themselves, is by far the most extreme way to reduce latency and is necessary to achieve latency below playing most games on their consoles natively.<\/p>\n\n\n\n

The configuration for run-ahead needs to be game specific, what works on one game may break another even on the same console. A very simplified explanation of how run-ahead works is, the emulator will run the game twice. One copy of the game runs ahead of the other by a certain number of frames. There are a couple ways to do this and which one is best depends on the emulator core.<\/p>\n\n\n\n

The main idea for both is that a state is saved after every frame, when the emulator receives an input it will load the early state to roll back to the 2nd, earlier version of the game to enter the input as if there had been no latency. <\/p>\n\n\n\n

For example, if you were really into Kaizo Mario hacks and you played on original hardware there would always be 2 frames of latency between when you press jump and when Mario jumps. This is built into the game\u2019s logic and can\u2019t be changed on original hardware. With run-ahead properly configured we can get to effectively 0 frames of latency even when the game otherwise would refuse it.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

This can cause the game\u2019s logic to break though, the frames can disagree with each-other in other ways and weird things can happen. The more frames you\u2019re running ahead the more likely the two are to differ and cause the game to be unplayable. Run-ahead is an incredibly cool feature that you should probably never need to use. Especially if the game relies on randomly generated numbers for anything there is no guarantee they will remain the same between instances with run-ahead.<\/p>\n\n\n\n

<\/p>\n\n\n\n

AI Service<\/strong><\/p>\n\n\n\n

Settings > AI Service<\/strong><\/p>\n\n\n\n

\"\"
AI Service Menu<\/figcaption><\/figure>\n\n\n\n

I\u2019m not gonna write a guide to this now because it gets complicated and is only useful if you want to play Japanese games that have not been translated yet, but it\u2019s a really cool feature. AI Service can overlay machine translations of text detected in games, or generate a text-to-speech translation.<\/p>\n\n\n\n

I\u2019ll write something about it later<\/p>\n\n\n\n

Achievements<\/strong><\/p>\n\n\n\n

Settings > Achievements<\/strong><\/p>\n\n\n\n

\"\"
Achievements Menu<\/figcaption><\/figure>\n\n\n\n

Retroachievements.org has added a whole bunch of user made achievements to retro games that can be tracked with an account on their website. Setup is pretty self-explanatory, but requires registering on their website. The password itself is NOT saved in RetroArch, only the login token.<\/p>\n\n\n\n

Frame Throttle<\/strong><\/p>\n\n\n\n

Settings > Frame Throttle<\/strong><\/p>\n\n\n\n

\"\"
Frame Throttle Menu<\/figcaption><\/figure>\n\n\n\n

The most important settings here are enabling Rewind and setting the Fast-Forward Rate.
Frame Throttle > Rewind
Rewind Support \u2013 On<\/strong>
Setting this to on enables the Rewind feature, obviously. Rewind works by keeping a buffer of automatic savestates (an \u201coops\u201d file.) This does have a performance impact because this means constant writing to the drive.<\/p>\n\n\n\n

Every emulator handles savestates differently, they are not standardized. For most consoles savestates will be very small and the performance impact will be negligible enough to not matter. The biggest exception to this is N64 savestates. All current N64 emulator cores are variants of mupen64plus which handle savestates in roughly the same way, they are very large compared to nearly every other core. Having Rewind enabled for N64 is one of the most common causes of poor framerates in N64 games, so it\u2019s usually not a good idea to have it enabled for any N64 core.<\/p>\n\n\n\n

(as a side note, battery saves are different from savestates and are standardized. The emulator has to handle savestates in its own way since they are not a part of how the original consoles worked. Battery saves are handled by the game itself, they are kept separately from the rom since roms are, like the name implies, read only. Emulators just dump that data into a file, that\u2019s all a battery save is. Because of this an SNES battery save, an SRM file, will be the same whether Snes9x made it or bsnes made it.)<\/p>\n\n\n\n

We can enable it here if we want mostly-global rewind and create an override for N64 with Rewind disabled later to account for this<\/p>\n\n\n\n

Rewind Frames<\/strong> \u2013 This sets how granular each \u201crewind\u201d is. The default of \u201c1\u201d is usually too slow, it will rewind at the same speed the game normally runs forward. I think 5-10 frames is good for most games<\/strong>. Too high and you\u2019ll overshoot the point you\u2019re trying to rewind to.<\/p>\n\n\n\n

Rewind Buffer Size (MB)<\/strong> \u2013 This affects how far back you\u2019ll be able to rewind. Each savestate rewind makes takes up filespace, eventually the buffer will fill and the oldest will get deleted. 20MB is a very safe, small number but you\u2019ll probably want to increase this to whatever you feel comfortable dedicating for this feature. For reference, a SNES savestate is usually about 400-600KB<\/strong>. To adjust this in different increments you need to adjust the next option \u201cRewind Buffer Size Step<\/strong>.\u201d<\/p>\n\n\n\n

Fast-Forward Rate<\/strong> \u2013 0.0x is usually way too fast, it will just run as fast as your computer is capable of running it when fast-forward is enabled. It\u2019s personal preference what this should be set to, but 3.0x is comfortable<\/strong> for many games. Sometimes 0.0x is useful if you\u2019re grinding in RPGs I guess, but you should just grind at normal speed like a man.<\/p>\n\n\n\n

Network<\/strong><\/p>\n\n\n\n

Settings > Network<\/strong><\/p>\n\n\n\n

\"\"
Network Menu<\/figcaption><\/figure>\n\n\n\n

Netplay is complicated, depends on what cores you are using and what the other player is using. It requires its own guide. RetroArch\u2019s current netcode does use rollback<\/strong> though.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Directory<\/strong><\/p>\n\n\n\n

Settings > Directory<\/strong><\/p>\n\n\n\n

\"\"
Directory Menu<\/figcaption><\/figure>\n\n\n\n

Here we set where RetroArch looks for different kinds of files. There are only two that are likely to matter
<\/p>\n\n\n\n

System\/BIOS<\/strong> \u2013 Make sure this is set to C:\\Retroarch\\system (or wherever that folder is wherever you installed RetroArch)
This needs to match the folder we extracted BIOSes to earlier<\/strong><\/p>\n\n\n\n

File Browser<\/strong> \u2013 Set this to the folder containing the folders that your roms are in. This isn\u2019t necessary, but will make scanning for roms later much easier.<\/p>\n\n\n\n

Thumbnails<\/strong> can be set to another directory if you want to download Box Art or other media for all your games but keep it on another drive, like if you had RetroArch on a small, fast SSD you didn\u2019t want to fill up, but had a bigger, slow HDD you could put it all on. The same is true for Recordings and possibly Cache in exotic configurations (computers which use a ramdrive for cache. This is actually a very cool thing to do if you have a lot of ram and a lot of time, but is way outside the scope of RetroArch configuration.)<\/p>\n\n\n\n

If you want to download thumbnails for your game you can use the thumbnail downloader in Retroarch. This is pretty slow and sometimes inaccurate if you have a lot of games, especially full sets.
You can manually download them all from https:\/\/thumbnails.libretro.com\/packs\/ <\/a>though much faster. Download the archives for the systems you want, extract them, and move the the directories for the console over to the thumbnails directory or whichever directory you set thumbnails for.
<\/p>\n\n\n\n

<\/p>\n\n\n\n

Saving Configuration Again<\/strong><\/p>\n\n\n\n

Now that everything is configured it is important to make\nsure the configuration is saved, it is NOT automatically written whenever a\nchange is made, only when forced or (if we configured it to like the guide said\nto earlier) on exit.<\/p>\n\n\n\n

Main Menu > Configuration File > Save Current Configuration<\/strong><\/p>\n\n\n\n

The main configuration file, the one we wrote here, is loaded first. There are other types of configuration files we\u2019ll use later; core overrides, directory overrides, and game overrides. They are loaded in that order, so this means the main configuration will never overwrite anything, but the other configurations will overwrite it and every override before it in the configuration hierarchy. <\/p>\n\n\n\n

Outside of this hierarchy there are \u201ccore options\u201d (retroarch-core-options.cfg and .opt files) which include settings specific to a core that don\u2019t need to exist in the main RetroArch configuration. Non-arcade emulators don\u2019t need an option for what to do with a coin-insert, 2d systems don\u2019t need 3d rendering options, etc.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Part 4: Adding Cores and Creating Playlists<\/h3>\n\n\n\n

At this point RetroArch is hopefully configured properly to at least play games at full speed, but it has no emulator cores and it\u2019s pointing to no games. We\u2019re going to install the cores first and then scan our rom folders, creating playlists for each console. Then, we should be able to easily choose a game with a controller-oriented UI and jump quickly into it with a specific emulator. First, we need the emulator cores.<\/p>\n\n\n\n

The emulator cores are maintained and stored on libretro servers, all of this can be done manually if the servers go down (has happened recently after dweeby hackers emptied the github), twinaphex runs out of money and no one can pay for hosting, we all die, or if you want to build the cores yourself to either implement custom changes, optimize performance to an insane degree, diagnose problems, have too much time etc. But, the easy way is to just trust that the servers are up and download everything through RetroArch\u2019s built in updater and core downloader.<\/p>\n\n\n\n

Adding Cores<\/strong><\/p>\n\n\n\n

Main Menu > Online Updater<\/strong><\/p>\n\n\n\n

\"\"
Online Updater Menu<\/figcaption><\/figure>\n\n\n\n

While you\u2019re here first run the basic updates;
Update Assets, Update Controller Profiles, Update Cheats, Update Databases, Update GLSL Shaders<\/strong>
<\/p>\n\n\n\n

Overlays are unnecessary for most people playing on a normal screen unless you really like the Super Gameboy art surrounding your game aesthetic. When that\u2019s all done we\u2019ll move onto the actual emulator cores.<\/p>\n\n\n\n

Online Updater > Core Downloader<\/strong>
<\/p>\n\n\n\n

Wait for it to fetch the corelist, and download at least one core for every system you want to emulate. I recommend cores that are easiest to work with and most compatible, not necessarily \u201cbest.\u201d The conventional wisdom is “there is no best core for a console” and, even though this sounds like a platitude, is actually true.
Cores, on Windows, are just dll files. They are not portable, these dll files are Windows specific executables and will not run on another operating system. Cores for Linux are built from the same source tree but end up being a different binary, and that\u2019s true with every other OS. This wont matter to you if you use RetroArch\u2019s built-in core downloader, it will always match your system, but will if you try to do it manually.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Arcade <\/strong>\u2013 Some version on FinalBurn might work, depending on your game. Honestly though, you are better off using standalone MAME if you want to emulate arcade games. MAME does not play nice as a libretro core and the MAME guys suck.<\/p>\n\n\n\n

Atari <\/strong>(most Atari systems) \u2013 Stella
PC Engine<\/strong> \u2013 Beetle PCE FAST
Nintendo 3DS<\/strong> \u2013 You\u2019re better off using standalone Citra, but the libretro cores are getting there
Nintendo DS<\/strong> \u2013 DeSmuME
Gameboy<\/strong> \u2013 Gambatte (TGB Dual has some use for netplay)
Gameboy Advance<\/strong> \u2013 mGBA
Gamecube\/Wii<\/strong> \u2013 You can use the Dolphin core, but because Dolphin really has its own, very specific settings Dolphin standalone is still the best choice.
NES <\/strong>\u2013 Nestopia UE is reliable, I generally use it. But all the NES emulators are very mature, some people really like FCEUmm, Mesen is the newcomer with some wild features to play with.
Nintendo 64<\/strong> \u2013 install BOTH Mupen64Plus-Next and ParaLLEl. You will usually want to use Mupen64Plus-Next, and will likely get the best performance out of it. ParaLLEl aims for more resource intensive, lower-level emulation. They are actually both the same emulator (Mupen64Plus) but with different baked in plugins. At this point Mupen64Plus-Next can be configured to use the same Low Level RDP plugin as ParaLLEl, but ParaLLEl can be configured to use a wider variety of plugins (mostly useful for compatibility.) N64 emulation, because of bad decisions made in the late 90s, is just built this way and it\u2019s too late to go back.
SNES<\/strong> \u2013 A can of worms. Snes9x \u2013 Current is the standard, up to date version of Snes9x that works for everything, runs easily, has all the features Snes9X has gotten over the years. But then there\u2019s bsnes, byuu\/near\u2019s emulator that aims for accuracy above all else, at the expense of performance. It has its own set of features that Snes9x doesn\u2019t have (the coolest being high-res mode7, when it works) and a complicated\/hostile history with RetroArch.
<\/p>\n\n\n\n

I use Snes9x, it\u2019s accurate enough for actually playing games, it has the highest compatibility with romhacks which sometimes wont work on an emulator that\u2019s too accurate, and it runs very well.<\/p>\n\n\n\n

The other variants of Snes9x are specifically built for lower power machines like a Raspberry Pi or a weak phone. They don\u2019t matter here.<\/p>\n\n\n\n


Sega basically everything 2d<\/strong> \u2013 Genesis Plus GX
Sony Playstation<\/strong> \u2013 SwanStation generally performs better, but Beetle PSX HW plays some games better. Both are probably about equal. PCSX ReARMed is mostly for very low end hardware.<\/p>\n\n\n\n

You should randomly go back into the Online Updater sometimes and select \u201cUpdate Installed Cores<\/strong>\u201d which will do exactly what it says and update every core that you have installed. Some cores move fast, especially the N64 emulators. <\/p>\n\n\n\n

<\/p>\n\n\n\n

Creating Playlists<\/strong>
Since the RetroArch UI is mostly meant to be used with a controller, browsing through directories every time you want to play a game wouldn\u2019t work very well. RetroArch can be used this way but it\u2019s really not the best or intended way to do things. Instead, RetroArch has a built in scanner that will scan the files in a directory, compare each file’s checksum to a list of all known games in RetroArch\u2019s databases stored in rdb files, and write a pointer to it in a playlist file. The databases are based around the popular fullsets for each console and should be compatible with nearly every commercial release of a game on a known system, they\u2019re updated regularly<\/p>\n\n\n\n

The playlists have the file extension \u201clpl\u201d but are really just simple text files. An entry in an lpl playlist looks like this;
“path”: “G:\\Roms\\Nintendo – Nintendo Entertainment System\\Super Mario Bros. 3 (USA).zip#Super Mario Bros. 3 (USA).nes”,
“entry_slot”: 359057152,
“label”: “Super Mario Bros. 3 (USA)”,
“core_path”: “DETECT”,
“core_name”: “DETECT”,
“crc32”: “85A79D9C|crc”,
“db_name”: “Nintendo – Nintendo Entertainment System.lpl”<\/em>
If you needed to, you could manually add a game to a playlist by recreating this structure. This isn\u2019t necessary very often anymore because RetroArch has the ability to create playlists from files that don\u2019t match anything in the database but it used to be a thing people had to do.
This rom here exists inside a zip file, and so the playlist contains an extra bit for the path that specifies which file in the zip file to actually use. When the game is played it will be temporarily extracted, put in cache, and then deleted afterwards. Not every core supports this, but most do.
<\/p>\n\n\n\n

crc32 is the checksum used to identify the rom
<\/p>\n\n\n\n

core_name is not set for this rom yet (or for the playlist) but, after a cores been selected for it, that core will be written to the playlist and will become the default for it from then on.<\/p>\n\n\n\n

Your roms should be arranged like this. <\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

One main folder containing a subfolder for each console. Any roms that will not have a matching database entry (prototypes, hacks, translations) should be put in another folder for that console separate from the console\u2019s main folder. I choose the naming scheme \u201cconsole (etc)\u201d for these roms. This is because we don\u2019t want the scanner picking up already scanned roms when making playlists for the translations, hacks, etc.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Scan a console by going to Import Content > Scan a Directory<\/strong> and navigating to the console\u2019s directory. This is NOT for the \u201cetc\u201d folders, but only for the directory full of roms that will have a matching database entry. Once you find the directory select \u201cScan This Directory<\/strong>\u201d<\/p>\n\n\n\n

\"\"
Import Content Menu<\/figcaption><\/figure>\n\n\n\n
\"\"
Scanning a Directory<\/figcaption><\/figure>\n\n\n\n

You should see the progress indicator on the bottom left of the screen. The scanner is not very fast, there are other ways to do it, but this way is accurate and compatible with all kinds of hardware. You can scan another console while one is currently being scanned but if you end up scanning more than 3 consoles at a time things will slow down by a lot. Once it\u2019s done the indicator will go away and you should have a new menu option for that console.<\/p>\n\n\n\n

The entry for the system will be back in the root menu on the left. Now, to finish, play a game on each scanned system. You will get an option window like this, select \u201cRun\u201d<\/p>\n\n\n\n

\"\"
Run Menu<\/figcaption><\/figure>\n\n\n\n


Now you\u2019ll be asked to select a core. Choose the core you want to use and run it. If everything went well the game should start. Press the menu hotkey you assigned (or the default F1 on your keyboard) to bring up the options menu for this core. <\/p>\n\n\n\n

To streamline selecting a game though, we\u2019re going to want to associate a specific core with each playlist, otherwise we\u2019ll be asked which core to use every time we go to play a game. We want to do this for every console where we\u2019re sure we only want to use one core (so don\u2019t do this with N64, we wanna manage the cores for that on a game by game basis) To do this go to;<\/p>\n\n\n\n

Settings > Playlists > Manage Playlists<\/strong><\/p>\n\n\n\n

\"\"
Manage Playlists Menu<\/figcaption><\/figure>\n\n\n\n

Select the playlist you want to assign a core to. There are a few options in this window but the important ones for us now are \u201cDefault Core<\/strong>\u201d and \u201cReset Core Associations<\/strong>\u201d (if we want to undo something we did)
Select \u201cDefault Core<\/strong>\u201d and choose the core that matches this system
This sets a bit at the top of the lpl file for that playlist, for example what was
“default_core_path”: “”,
“default_core_name”: “”,<\/em>
Becomes
“default_core_path”: “C:\\Retroarch\\cores\\nestopia_libretro.dll”,
“default_core_name”: “Nintendo – NES \/ Famicom (Nestopia UE)”,<\/em>
Now if we select a game and then press \u201crun\u201d it will jump right into the game.<\/p>\n\n\n\n

For consoles with no default core, the core we select to run a game with will be set as the default core for that game only. So if we run Mario 64 with Mupen64Plus-Next, the next time we run Mario 64 it will use that core. If that core doesn\u2019t end up working we can change the core by selection \u201cSet Core Association<\/strong>\u201d or \u201cReset Core Association<\/strong>\u201d and then running it again.<\/p>\n\n\n\n

\u201cSet Core Association<\/strong>\u201d will also work for a game in a playlist with a default core, in case there we want to, for example, run every SNES game with Snes9x-Current except Mario Kart because we want that high-res mode7 in bsnes.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Manual Scan<\/strong><\/p>\n\n\n\n

Import Content > Manual Scan<\/strong><\/p>\n\n\n\n

For folders with files that do not match a database we need\nto do a manual scan<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Point \u201cContent Directory<\/strong>\u201d to the folder with the roms we want to scan
<\/p>\n\n\n\n

If we set System Name<\/strong>, the scanner will merge these roms in with the other playlists we have for this console. I don\u2019t usually do this, I think it\u2019s best to keep database roms and non-database roms separated. To do that, set System Name to \u201cCustom<\/strong>\u201d<\/p>\n\n\n\n

Custom System Name<\/strong> can be anything, whatever we want it to be called. It will not affect which cores we can use.<\/p>\n\n\n\n


If we leave the Default Core blank we\u2019ll have to associate a core with the games later. We\u2019ll also have to explicitly tell RetroArch which files to scan for. It\u2019s much easier to just set a core that matches the type of roms we\u2019re scanning and let it do the rest, even if we want to change core associations later.
<\/p>\n\n\n\n

Once that\u2019s done scroll to the bottom and select \u201cStart Scan<\/strong>.\u201d That\u2019s it, you should now have another playlist that functions like every other playlist.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Part 5: Core Configuration<\/h3>\n\n\n\n

This section will not be complete. Every single core has some of its own specific settings and behavior that is handled in the core because there are some things that are very specific to an N64 emulator that are completely irrelevant to an NES emulator. Most emulators will run fine without any extra configuration, though, and the emulator specific configurations are mostly extra things like high res texture packs, CPU overclock or overclocking specific chips that only that system uses (like SuperFX chip overclocking on SNES, which actually makes StarFox play better emulated than on original hardware.)<\/p>\n\n\n\n

N64 emulation is an exception and each N64 core has many core specific options that might be necessary to get certain games working. This is one of the reasons it\u2019s usually better to play the Virtual Console version in Dolphin if that exists.<\/p>\n\n\n\n

PSX emulation can get a little complicated too.<\/p>\n\n\n\n

But for all that, I think it\u2019s better to write separate core specific guides, which I might end up doing but I won\u2019t do now because all in all it would be 10 times longer than this guide just for that. Instead, we\u2019ll cover the few core specific options that apply to all cores and that we\u2019re going to want to do anyway.<\/p>\n\n\n\n

Accessing Core Specific Options<\/strong>
<\/p>\n\n\n\n

Start a game with the core you want to set options for. Press the menu button. You are now at the screen for all game and core specific options. This is also where you save and load states or restart the game without a hotkey.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n
\"\"
Core Options Menu<\/figcaption><\/figure>\n\n\n\n

Control Remaps<\/strong><\/p>\n\n\n\n

Core Options Menu > Controls<\/strong><\/p>\n\n\n\n

\"\"
Controls Menu<\/figcaption><\/figure>\n\n\n\n

We originally set up our controller as if it was an SNES controller. This control scheme sucks though for some consoles, especially NES and GB with their 2 button setups. B and A are going to be the bottom two buttons on the controller, with A being to the right and slightly above B on most controllers. Remember though, that RetroArch uses the Nintendo layout, if you\u2019re using an xbox controller your \u201cB\u201d will be RetroArch\u2019s \u201cA.\u201d
<\/p>\n\n\n\n

With this control scheme, imagine you\u2019re playing Mario. You\u2019ve got B held down to run because you\u2019ve been playing this game for 30 years and you never need to not be running. You gotta jump, so you have to contort your thumb over to the right to hit A every time. This was easier to do on an actual NES controller where the buttons were close and directly horizontal to each other but is awful on a modern controller.
<\/p>\n\n\n\n

What works really well though is to set Y to be B, and then B to be A. That way the top of your thumb is B, the bottom is A. To do a running jump you just gotta rock your thumb down a little bit. But if we set RetroArch to that control scheme then SNES games will all be weird.<\/p>\n\n\n\n

Easy solution though, controller remaps per core<\/strong>. Load up an NES game<\/strong>, back out into the menu and scroll down until you find \u201cControls<\/strong>.\u201d
<\/p>\n\n\n\n

Go down to \u201cPort 1 Controls<\/strong>\u201d to setup player 1 (we\u2019ll have to repeat this for player 2 if we want) and you\u2019ll get a list of every single button on the controller.
<\/p>\n\n\n\n

We are not assigning buttons to functions here for the most part. We\u2019re assigning buttons to other buttons. So, for the NES controller example, go find \u201cB Button (Down)\u201d and set that to \u201cA.\u201d<\/strong> Do the same thing for Y, and maybe set the other 2 face buttons to turbo buttons for NES or any other changes you want.
<\/p>\n\n\n\n

Go back one screen when you\u2019re done and select \u201cManage Remap Files<\/strong>\u201d
<\/p>\n\n\n\n

If we select \u201cSave Core Remap File<\/strong>\u201d it will make what we just did the default control scheme for every game that uses this core. If we select \u201cSave Game Remap File<\/strong>\u201d then, just this game. \u201cSave Content Directory Remap File<\/strong>\u201d is the less used option and will set it to just this directory, useful if we organize RPGs into one directory or something and set a one handed control scheme for just those games but want to play all other games with a different control scheme or if we’re using an emulator that emulates multiple consoles with different button layouts (common for Sega emulators.)
<\/p>\n\n\n\n

Do the same for GB, GameGear, Master System, Atari, whatever console you want to configure and that\u2019s done.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Shaders<\/strong><\/p>\n\n\n\n

Core Options Menu > Shaders<\/strong><\/p>\n\n\n\n

\"\"
Shaders Menu with Video Shaders set to “On”<\/figcaption><\/figure>\n\n\n\n

A shader is essentially a list of functions that affect the way the GPU draws something on a screen, in emulation these shaders are applied as a filter over the original image to various effect. It\u2019s very hard to write this explanation without sounding vague and that\u2019s because what shaders do for a game, practically, has grown a lot over the past 20 years.<\/p>\n\n\n\n


Long ago, even in early emulators like ZSNES, shaders like Eagle and 2xSaI were around. The shaders would interpolate an upscaled image from the game as a kind of anti-aliasing. So, blocky NES or SNES games would look smooth. But they\u2019d also look very different, and sometimes just a little wrong.<\/p>\n\n\n\n

These shaders still exist, and the main idea behind them (making a low-resolution image look smooth or some kind of \u201cbetter\u201d at a higher resolution) is still probably the most popular reason for using shaders. It\u2019s also the most controversial reason for using them.
<\/p>\n\n\n\n

Other shaders attempt to accommodate for the differences in modern screens and whatever screen the original hardware was played on back in the day. Often this means emulating scanlines that you\u2019d get on an old CRT (the black lines in between the actual image lines) or the pixel layout of a CRT. There are also shaders that, for example, cover the screen in that faded green so it looks like an original Gameboy.
<\/p>\n\n\n\n

Then some shaders do more general effects like mirroring the entire image so you can play some backwards Mario, or make the image look like it\u2019s a VHS recording, etc.<\/p>\n\n\n\n

Some people hate shaders because they feel like they change the game too much, ruining the intended art style. That retro games were made with the limitations of the hardware in mind. But then other people argue that these games don\u2019t look how they were intended anyway, most of these consoles existed when CRTs were the main or only kind of display. A modern LCD will never look like a CRT, CRTs blurred the image, generated colors differently, had scanlines, etc. And some people just like smooth Mario. It\u2019s personal preference, but the one thing that objectively might matter is that using a shader does have a performance hit which can matter when emulating more modern consoles at higher than original resolution.<\/p>\n\n\n\n

\"\"
Mario with No Shaders<\/strong><\/figcaption><\/figure>\n\n\n\n
\"\"
Mario with an original Game Boy Shader<\/strong><\/figcaption><\/figure>\n\n\n\n
\"\"
Mario with the common CRT scanline shader CRT – Royale<\/strong><\/figcaption><\/figure>\n\n\n\n
\"\"
Mario with the scaling and smoothing shader xBR<\/strong><\/figcaption><\/figure>\n\n\n\n

There are 3 shader formats RetroArch has support for;
CG <\/strong>\u2013 \u201cC for Graphics\u201d Deprecated, RetroArch can still be built to support this format but your copy likely won\u2019t be. There\u2019s no reason to use this anymore.
GLSL <\/strong>\u2013 OpenGL Shading Language, this is the shader format that supports older OpenGL. If you are using any of the OpenGL video drivers this shader format will work.
Slang <\/strong>\u2013 The newest format which, if you can use it, you should use it. This works with OpenGL Core (but not older OpenGL), the Direct3D video plugins, and most importantly this is the shader format that works with Vulkan.<\/p>\n\n\n\n

To use shaders, start the game you want to apply a shader to. Return to the menu while the game is running.
Main Menu > Quick Menu > Shaders<\/strong> (it\u2019s near the bottom)
Set \u201cVideo Shaders<\/strong>\u201d to \u201cOn<\/strong>\u201d
Select a shader preset by pressing \u201cLoad<\/strong>\u201d then select the folder for the shader type you want to use. If you choose a type that the video driver you\u2019re using does not support all the folders will be empty.<\/p>\n\n\n\n

Choose your preset, go back to the Shader menu, press \u201cApply Changes<\/strong>\u201d
<\/p>\n\n\n\n

You can fine tune the shader options (how many passes, what kind of filter you want to apply) with the options at the bottom, but there should be a preset that does what you want without having to mess with this too much.<\/p>\n\n\n\n

\"\"
Shader Menu with Shader Preset loaded<\/figcaption><\/figure>\n\n\n\n

If you find a shader you like that you want to make default for that game, or every game that uses that core, or even every game in every core (you probably don\u2019t want to do that last one. Shaders that look good on SNES don\u2019t usually look good on n64) from the shader menu<\/strong> press;
Save > Save Core Preset<\/strong> (or Game Preset<\/strong>, or Global Preset<\/strong>)<\/p>\n\n\n\n

<\/p>\n\n\n\n

Core Options<\/strong><\/p>\n\n\n\n

From the Quick Menu (the same place we were to apply shaders and control remaps) there is an option called \u201cOptions<\/strong>\u201d<\/p>\n\n\n\n

This contains all core specific options<\/strong> for the current running core<\/strong>. It will be different for every core, it\u2019s a good idea to look around here though, especially for 3d systems. For example, with PSX and N64 emulators this is where you\u2019ll find the options to adjust the internal resolution the game runs at, most of these games look like garbage at their original resolution and can be easily run at higher resolutions.<\/p>\n\n\n\n

Whatever core though, you can choose to set options for a specific directory or game by going to Options > Manage Core Options > Save Game Options<\/strong> or Save Content Directory Options<\/strong><\/p>\n\n\n\n

<\/p>\n\n\n\n


Conclusion<\/strong>
<\/p>\n\n\n\n

At this point, assuming I didn\u2019t forget anything (which I probably did) almost everything should be playable and RetroArch should be configured well enough. There\u2019s still more; netplay, the AI Service, Core specific options, but the important stuff is done.
<\/p>\n\n\n\n

What this means is that you can start RetroArch with a controller in hand, you\u2019ll have all of your roms right there. All games will be configured in the same way. Nothing will require using a mouse, and if your hotkeys are set up properly you won\u2019t need a keyboard either. You can jump from game to game easily even on different consoles without having to take your hands off your controller.
<\/p>\n\n\n\n

If you wanted to you could fine-tune the way you emulate games to an insane degree, you can do this with all emulators at once or individually. All of your emulators should have mostly the same features and the same UI.<\/p>\n","protected":false},"excerpt":{"rendered":"

Part 1: Background RetroArch is a frontend for the the libretro API. The idea behind libretro was to separate the higher level tasks of an emulator such as the video drivers, the configuration, input, etc. from the actual emulator itself. A libretro core will, for the most part, only handle actual emulation. Before libretro every … Read More<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,3],"tags":[6,7,4,5],"class_list":["post-34","post","type-post","status-publish","format-standard","hentry","category-emulation","category-tech","tag-emulation","tag-guides","tag-retroarch","tag-tech"],"_links":{"self":[{"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/posts\/34","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/comments?post=34"}],"version-history":[{"count":16,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/posts\/34\/revisions"}],"predecessor-version":[{"id":167,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/posts\/34\/revisions\/167"}],"wp:attachment":[{"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/media?parent=34"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/categories?post=34"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cstroik.com\/index.php\/wp-json\/wp\/v2\/tags?post=34"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}