|Platforms||Linux, Windows, OS X, iOS, Android, Haiku, Blackberry PlayBook, Blackberry 10, PlayStation3, PlayStation Portable, Xbox, Xbox 360, GameCube, Wii|
|Year of Inception||2012|
RetroArch is the official reference frontend for the Libretro API.
- 1 Compilation
- 2 Configuration
- 2.1 Video Driver
- 2.2 Input Driver
- 2.3 BIOS Configuration
- 2.4 Autosave not working
Main article: RetroArch Compilation
Getting optimal VSync Performance - Dynamic Rate Control
RetroArch uses Dynamic Rate Control to synchronize both video and audio at the same time. Synchronizing like this is a very demanding task timing-wise and dynamic rate control helps smooth out imperfections in timing which are guaranteed to arise.
It can be disabled, but be aware that proper video/audio sync is nearly impossible to obtain in that case.
While using RetroArch, the default settings might not be adequate, and you might experience video stuttering and/or audio crackling. For correct synchronization, video_refresh_rate must be configured for your monitor. It cannot be detected accuractely enough by OS-provided APIs (i.e. they tend to blatantly lie). For proper behavior, an accuracy of roughly ~0.1% is needed for dynamic rate control to smooth out the drifting. This is trivial to obtain by measuring manually under normal conditions. Without dynamic rate control one would need a "perfect" measurement which obviously isn't possible without special hardware.
RetroArch can give you an estimate of your monitors refresh rate in RGUI under video settings, which is updated in real-time using a running average over frame times. Make sure VSync is enabled and working. Also make sure you're running in full-screen for more accurate results (compositors can easily interfere with timing). Press accept button on the estimated refresh rate to configure RetroArch with the estimated rate. If the running average isn't drifting much anymore, it's probably a good result.
You can also have RetroArch log the output at the end and configure things more manually. Start RetroArch directly in RGUI with retroarch --verbose --menu. Let it run uninterrupted for at least 4096 frames (displayed in title bar), and exit. In the log, you should see something like:
RetroArch: Average monitor Hz: 59.869485 Hz. (1.347 % frame time deviation, based on 2048 last samples).
If you're unsure about the result, run this test several times and see if the results are consistent. Some systems tend to have very unreliable VSync behavior and this result will wildly fluctuate. You can use this value in video_refresh_rate and the video and audio should ideally be butter smooth if the game's FPS and monitor FPS are relatively close to each other (playing a PAL game on 60 Hz monitor won't be perfect no matter what you do ...)
There have been cases reported on excessive input lag in Windows for some users. It's not really input latency, but video driver latency. Some video drivers tend to buffer way too much in the name of increased performance. This problem is explained by Carmack here.
RetroArch recently got an option to use a swap/fence sync method in OpenGL driver, which is reported to greatly lower input latency (thread). To enable it, set video_hard_sync = true in config or enable it from RGUI. To ensure that this sync method is actually used, make sure that you see this in the log:
RetroArch: Querying GL extension: ARB_sync => exists RetroArch: [GL]: Using ARB_sync to reduce latency.
Do note that this sync method can greatly reduce performance, and can turn smooth 60 fps into crawling 30 fps if there was not enough headroom in the performance.
If you use KMS mode, using video_hard_sync won't help as it already does something like this.
If your video driver has very bad performance, it is possible to run it on a thread to avoid almost all video driver overhead. Set video_threaded = true in config. Butter smooth VSync behavior in this case is impossible however, and latency might increase slighly. Use only if you cannot obtain full speed otherwise.
Windows Vista and up problems
Windows Vista and up suffer problems with OpenGL in windowed mode where it appears to be impossible to obtain proper, smooth VSync behavior no matter what you do. If you are annoyed by this problem, and still want to play in windowed mode, you should use the D3D9 driver which doesn't have this problem. Disabling Aero sometimes helps OpenGL VSync behavior.
Input drivers in Linux without Xorg
When not in Xorg, using input devices can be more finicky than in X. The main way to access input directly is using the evdev interface found in /dev/input, and optionally the legacy joystick interface in /dev/input/js*. To discover devices and support hotplugging, libudev is used.
Requirements for udev/evdev drivers
To use udev/evdev drivers, RetroArch depends on the libudev package. To support keyboard callback interface in udev, the libxkbcommon package (version 0.3 and up) is required. It is used to translate raw evdev events to printable characters. It does not depend on Xorg, but it depends on X11 keyboard layout files being installed.
Setting up udev permissions
By default in most distros, /dev/input nodes are root-only (mode 600). You can set up a udev rule which makes these accessible to non-root. Add to
KERNEL=="event*", NAME="input/%k", MODE="666"
Then reload rules with
sudo udevadm control --reload-rules. Until next reboot (or replugging devices), you can force permissions with
sudo chmod 666 /dev/input/event*.
RetroArch has two drivers for keyboard which can run without X. udev is a newer driver which reads evdev events directly. It also supports keyboard callback, mice and touchpads. The older linuxraw driver requires an active TTY. Keyboard events are read directly from the TTY which makes it simpler, but not as flexible. Mice, etc, are not supported at all.
udev is preferred over linuxraw when applicable.
Configuring keyboard layout for udev/evdev keyboard
When using udev driver, you have to set the keyboard layout/variant yourself. Set the input_keyboard_layout setting for this. See default retroarch.cfg for syntax.
RetroArch has three drivers for joypads on Linux. udev is a newer driver which uses the recent evdev joypad API. It supports hotplugging and force feedback (if supported by device). An older linuxraw driver is also supported, which uses the older joystick API (/dev/input/js*). Finally, SDL driver can be used.
udev is the default driver for joypads.
A BIOS (Basic Input Output System) is the startup code of a system and is required for certain emulators to work.
Where do I place the BIOS files?
You’ll need to place them into the System Directory.
Alternatively, you can place the into your Content Directory next to the game you are going to play.
Why isn’t my BIOS working?
1: Make sure the BIOS files are placed into the correct directory (see above).
2: Make sure they are named correctly so the core can identify them.
3: Make sure it’s the correct version/region of a BIOS.
4: Make sure your files are not corrupted (bad source, broken download, etc.).
5: Make sure to check the log for any errors.
Autosave not working
Autosave state function not working with ALT+F4 combination.