Pixel perfect video in RetroArch

I love pixel perfect video when playing my retro games. If you are like me, then you probably do not like the default setting in RetroArch which adds some blur to the image. Let’s change that.

This is what you get by default (Game Boy Color in this case):

This is what you get when you disable the blur filter. Pretty nice, isn’t it?

And these are the simple steps you have to follow:

  • Start Retroarch
  • go to “Settings”
  • Select “Video”
  • Disable “Bilinear Filtering”
  • Enjoy your pixel perfect games


Lakka 2.2 Christmas Release

Happy new year everyone!

The team over at lakka.tv released their new version 2.2 over the holiday season.  This includes RetroArch 1.75, which comes with the new menu “Ozone” (highly recommendable), a fixed PPSSPP core and many more changes.

To update your Lakka box simply use the online updater, download the new release package, reboot, let it install and enjoy the new release. I updated mine and it worked flawless. Big thanks to the team.

Head over for more Lakka news to the project’s website.

RetroArch 1.7.5 released

The latest article from the libretro team announces a new version of RetroArch: RetroArch 1.7.5 has just been released! Grab it here. or via Google Play Store (32bit) or for users with 64bit capable devices you can grab the new version here.

So what is new in this version?

  • Launch of Nintendo Switch version

This is definitely THE highlight of this release. The libretro team got a dedicated article for this:


In short: Installation instructions and all the feature included in this first release for the Switch like

  • OpenGL support
  • Touchscreen support (for MaterialUI/etc)
  • Full networking support
  • RetroAchievements support
  • Game scanning
  • Split Joy-Con support
  • Core downloader
  • Runahead support
  • and 44(!) cores supported already


Further there are the following improvements in this new version:

  • Menu improvements: dropdown lists
  • Adaptive V-Sync implemented for OpenGL (Windows/Linux)
  • Improved Vulkan performance (especially for Nvidia cards): mailbox emulation: More details in  this blog article.
  • Easy recording/streaming options (for versions with ffmpeg support)
  • UDP Streaming to another RetroArch instance

For all the details and changelog read the full blog post here.


RetroArch 1.7.4 released

New RetroArch 1.7.4 is available for download. Grab it here.

What is new in a nutshell?

  • 64bit version of RetroArch Android
  • Discord integration
  • WIMP Desktop UI massively improved (Windows and Linux)
  • Sync To Exact Content Frame Rate (G-Sync/FreeSync users)
  • Cheat code searching/creation interface with rumble features
  • and many more improvements on the various platforms

Head over to the original article to see all the details on the changes.

Source: https://www.libretro.com/index.php/retroarch-1-7-4-released/


RetroArch: Discord integration coming

The next release of RetroArch, which will be 1.7.4, will come with the integration of Discord. Discord is a free voice and text chat for gamers. Visit their website here on discordapp.com.

Here is what the blog entry from Winneon says:

RetroArch 1.7.4 will have extended Discord RPC integration! Previously before 1.7.4, RetroArch would act as any other game in Discord: as a simple “Playing” status that said you had RetroArch open. It wasn’t very descriptive or helpful other than displaying the name “RetroArch”. With the 1.7.4 update, RetroArch will display more information beyond a simple “Playing” status! Below is the full list of new features this new extended integration brings.

  • A new “In-Menu” and “In-Game” status that displays whether you’re in the standard RetroArch menu, or playing a game in a libretro core.
  • Playing & paused indicators displaying whether or not the currently running core is paused or not.
  • Sleek icons based on the Monochrome XMB theme that display what platform your game is running as. This is dependent on the core, not the individual game/content, so there will be case scenarios where it may be wrong (i.e. showing a GameCube icon when you’re playing Super Mario Galaxy in Dolphin).
  • A text indicator that displays what platform & core you’re playing under when hovering over the platform icon.
  • A text indicator that display what game/content you’re playing. If you chose your game/content from a playlist, it will use the playlist entry’s name instead of the content filename.
  • A counter/stopwatch that shows your current session’s playtime when you’re playing a game/content in a libretro core. The counter will pause when the game/content also pauses along with the new playing/paused indicators.

Source: https://www.libretro.com/index.php/upcoming-retroarch-1-7-4-details-on-discord-integration/

Lakka 2.1.1 with Raspberry Pi 3 B+ support

After quite some time the Lakka team released the new version 2.1.1 which – as you probably guessed from the headline – supports the new raspberry Pi 3 B+. Great news for these owners. Some updated and also some new cores like Higan, nSide, Cannonball, MAME2003 and much more.

Here is the changelog:

  • Important updates
    • RetroArch 1.7.3
    • LibreELEC 8.2 fixes
    • XU4 kernel update to 4.14
    • Rockchip kernel upgrade
    • Allwinner kernel upgrade
  • New cores
    • Higan, the famous SFC emulator from byuu
    • nSide, a fork of higan v106 with additional features
    • Cannonball, an enhanced OutRun engine
    • MAME2003 plus, updated 2018 version of MAME (0.78) for libretro. with added game support and improvements
    • Snes9x 2005 plus, Snes9x 1.43 plus BLARRG APU
    • FreeIntv, Mattel Intellivision emulator
    • Game Music Emu core
  • Core updates
    • Citra, the 3DS emulator
    • ChaiLove, the chaiscript game engine
    • MAME2003, the multi arcade emulator
    • PPSSPP, the PSP emulator
    • Sameboy, the Game Boy emulator
    • Desmume, the Nintendo DS emulator
    • and many more
  • Fixes
    • Keyboard fix for ARM based devices
    • Bluetooth fix for S905/S912
    • H3 boot
  • Bonus
    • Support for more gamepads (Zeroplus based gamepads)
    • Support more Commodore cores
    • Libretro overlays are now exposed in SAMBA
    • Project cleanup
    • XU4 fix display of the partition resize messages

For more information, head over to their blog post.

To update, use the internal update feature of Lakka. Download and reboot.

RetroArch 1.7.2 released

As announced roughly a month ago, the RetroArch team released their new version 1.7.2 with the runahead latency reduction functionality which should provide even a better latency then the original hardware. How it works, which systems are support and more of the release, see libretro’s blogpost.

To download the latest release, go here or Google Play store.

Runahead latency reduction – better latency than the real hardware

A visual representation by Durante of how the runahead system works in practice.

This might just be our biggest release yet, thanks in no small part to the new runahead latency reduction system. This feature has already been all the rage over the Internet. Well known people like Durante of DSfix fame praised it and the popular site Ars Technica has dedicated an entire article to this game-changing feature.

We ran an article on this new feature before, and since then, several facts have changed on the ground which bears pointing out. First of all, several performance improvements have been made since. Secondly, the feature has now been enabled for the vast majority of the RetroArch platform ports.

The versions that have this feature enabled and exposed now includes:

  • PlayStation3
  • Xbox OG
  • Wii
  • WiiU
  • Nintendo Switch
  • Android
  • PC (Windows)
  • PC (Linux)
  • macOS
  • iOS

Here are some basic things you should know:

  • Every game has a certain built-in amount of lag frames. In order for the runahead system to perform as expected, you should set it to the same amount of frames to read ahead that the game you’re running is working by. So, for example, if a game like Super Mario World for the SNES has a guaranteed 2 frame input lag, for the best results, set Runahead frames to 2.
    You can count the amount of lag frames a game has by using the frame advance feature in RetroArch.
  • For playable performance, your system should be at least capable of running the core at twice its regular speed. These performance demands go up commensurate to the amount of frames you want to run ahead. The higher performance you get with a core, the more frames you can run ahead at fullspeed.
  • While the runahead system is core agnostic and therefore technically we don’t need to patch up cores in order to work with the runahead system, there are several things that can be done in order to improve performance considerably. To this end, Dwedit has submitted several patches to some of the cores in order to make them perform much better. Some of these cores include (but are not limited to) the Snes9x cores, QuickNES, FCEUmm, Nestopia, Gambatte, and even Mednafen/Beetle PSX.
  • There are currently some things you should know about Mednafen/Beetle PSX when it comes to runahead. First of all, in order for this core to work correctly with runahead, you should use the software renderer. The OpenGL and Vulkan renderers are currently buggy with runahead. Second, even after several savestate performance improvements, it is unlikely you will be able to set runahead to higher than 1 frame while still being able to run at fullspeed. This might likely change once our bounty for the Beetle PSX dynarec is finally fulfilled (and on that note, it has already reached $720, and a coder is working on a potential solution)
  • An often heard question that has been asked is – will this work on a Raspberry Pi? There is no straight answer to this since it heavily depends on the core’s performance. Based on our performance tests on the PS3 and Xbox OG, QuickNES and Gambatte should be at least two cores that should run at fullspeed with runahead set to 6 frames or less. Your mileage may vary on any of the other cores. The quick rule of thumb is that the faster the core, the higher chance there is to get it to run at fullspeed with more runahead frames.

How to check the amount of lag frames a game has

RetroArch has the ability to pause a core and advance it frame by frame. Perform the following steps to determine the amount of lag frames of a game:

  • Pause emulation (press ‘p’ button on keyboard).
  • Press and hold the jump button on the controller.
  • Advance emulation frame by frame (press ‘k’ button on keyboard) until the character jumps.

The number of k presses before you get a reaction should be the number of lag frames you can safely remove with run ahead.

Performance, scalability

So, how well does all this scale? Of course, the more expensive hardware you throw at a latency reduction approach like this the better, but how low can we actually go in terms of specs and still obtain good results? To figure out a basic answer to this question, I decided to test the runahead system on two old game consoles that are not exactly powerhouses at this point. The first of the lot is the Xbox OG, powered by a fairly mundane Pentium 3/Celeron 733MHz CPU. The second is the PlayStation3. Its PPU is roughly equivalent to a Pentium 4 2.4GHz CPU in terms of real-world performance, and even that comparison is probably pushing it. So this is not exactly powerful hardware.

Street Fighter Alpha 3 FBAlpha 2012 No runahead 104fps PS3
Street Fighter Alpha 3 FBAlpha 2012 Runahead – 1 frame 57fps PS3
Mega Man 2 QuickNES No runahead 124fps PS3
Mega Man 2 QuickNES runahead – 1 to 6 frames 124fps PS3
Mega Man 2 Nestopia No runahead 124fps PS3
Mega Man 2 Nestopia Runahead – 1 frame 76fps PS3
Mega Man 2 Nestopia Runahead – 2 frames 54fps PS3
Super Mario World Snes9x 2010 No runahead 113fps PS3
Super Mario World Snes9x 2010 Runahead – 1 frame 78fps PS3
Super Mario World Snes9x 2010 Runahead – 2 frames 65fps PS3
Super Mario World Snes9x 2010 Runahead – 3 frames 56fps PS3
Sonic 1 Genesis Plus GX No runahead 116fps PS3
Sonic 1 Genesis Plus GX Runahead – 1 frame 51fps PS3
Bomberman 94 Mednafen PCE Fast No runahead 124fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 1 frame 83fps PS3
Bomberman 94 Mednafen PCE Fast Runahead – 2 frames 66fps PS3
Sonic 1 SMS Gearsystem No runahead 120fps PS3
Sonic 1 SMS Gearsystem Runahead – 1 frame 63fps PS3
Sonic 1 SMS Genesis Plus GX Runahead – 1 to 6 frames 124fps PS3
Mega Man 2 QuickNES Runahead – 1 to 6 frames Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 1 frame Fullspeed Xbox OG
Mega Man 2 FCEUMM Runahead – 2 frames Not fullspeed Xbox OG
Sonic 2 Genesis Plus GX No runahead Fullspeed Xbox OG
Sonic 2 Genesis Plus GX Runahead – 1 frame Not fullspeed Xbox OG

We consider any PC from the year 2005/2006 (whether desktop or laptop) to be significantly more powerful than either of those consoles, so these test results bode quite well for the scalability and feasibility of the runahead method.

Features like the runahead system will also naturally increase the demand for ever faster cores so that people on lower specced hardware can use runahead with more frames in advance.

CRT Switch Res – GroovyMAME-like features for 15KHz capable CRT monitors!

Thanks to forum-user Alphanu, RetroArch now has the ability to query cores for their exact video timing data, which can be used to switch to native-resolution, 15 kHz modelines for use with standard-definition CRT TVs.

This is a big step for retro purists, as RetroArch can now output “pixel-perfect” video with accurate timing to compatible displays, even quickly switching between interlaced and non-interlaced modes on the fly.

This capability is currently Windows-only and requires modelines to be created in advance by CRT_EmuDriver or Custom Resolution Utility with a compatible GPU. Linux support is coming soon.

In case you’d like to learn more, follow these links:

Direct3D improvements, additions, and a new Direct3D10 driver

With RetroArch 1.7.1, we really stepped our game up to finally start treating Windows as a first-class citizen platform. You have seen this in the form of dedicated Direct 3D 11/12 video drivers that had the ability to run the same shaders as Vulkan, our new slang shader spec that is made possible by the impressive Khronos/ARM-backed project SPIRV-Cross.

Increased backwards compatibility

Previously, the Direct3D 11 driver required that your graphics card driver supported at least Shader Model 5.0. We have since downgraded this requirement to Shader Model 4.0. As a result, I am now able to use the Direct3D 11 video driver on an old 2010 laptop GPU that only supports Shader Model 4.0 (it’s an ATI Mobility Radeon HD 4300). We also try to support more D3D11 feature levels instead of just defaulting to 11.0.

New Direct3D 10 video driver

On some systems, though, you won’t be able to make use of the Direct3D 11 driver no matter what. One of those systems happened to be another old laptop I had lying around here. This one has a Geforce 9200M GS, and the specs state that it supports up to Direct X 10 and Shader Model 4.0. Direct3D 11 is a no go on this GPU even with the increased backwards compatibility.

It’s for this purpose that me and aliaspider spent some time to finally make the Direct3D 10 driver feature-complete. Direct3D 10 should be available from Windows Vista and up, whereas Direct3D 11 is available from Windows 7 and up. The Direct 3D 10 driver should be feature complete and identical to the Direct3D 11 driver, with the sole exception of hardware rendering contexts not being available right now with Direct3D 10.

Which brings us to the last Direct3D-related subject…

Direct3D-powered libretro cores are now possible!

This feature is easily worth its own article, but since we already covered this before and because 1.7.2 has so many huge features, we will relegate this to a side note. Nevertheless, it is none the less important.

Up until now, if you wanted to use hardware-accelerated 3D rendering in a libretro core, your options were OpenGL and/or Vulkan. There is now a third option – Direct3D 11, and the first libretro core that supports this is the PPSSPP core!

With all these features, we now have everything in place to really do an UWP version of RetroArch justice.

Input remapping system improvements

The input remapping system (available from Quick Menu -> Controls) had many obvious limitations previously. Some of these included:

  • It was not possible to map keyboard from more than one gamepad (for instance with Dosbox)
  • It was not possible to map more than one button to the same action
  • It was not possible to unmap buttons or analogs
  • It was not possible to map a button to trigger an analog response (for instance, in an N64 emulator, running in Super Mario 64 with the D-pad)
  • It was not possible to map an analog to another analog
  • It was not possible to map an analog to produce a button response

Most of these restrictions have now been lifted at long last thanks to radius, and the visual representation is also much improved now.

To read more about this, also visit the related forum thread here.

Do note that all your existing remap files are now obsolete, and you should start from scratch. This was a necessary evil unfortunately in order to progress.

Various Quality-Of-Life improvements

We have tried to do various consequential Quality-of-Life improvements for this release:

    • XMB and MaterialUI menus should scale much better now depending on the output resolution. Previously, the XMB and MaterialUI menu elements were too small if you were running at a resolution of 1440p or 4K.
    • Boxart / thumbnails now react better to other elements on the screen and can resize or adjust themselves accordingly. There are also new ways of showing a thumbnail on the left and right side of the screen in XMB. It is also possible to determine what ‘type’ of thumbnails get shown on the left and right, respectively.
    • There are two layout modes now for XMB – you can choose between Desktop and Handheld. Desktop is the default look of the XMB as it was now, mirroring the PS3 layout, while Handheld goes for an XMB look that is more in line with how it looked like on PSP. Previously, the default layout was ‘automatic’, where it would default to the PSP layout if you were running at a resolution of 320×240.
    • Shaders should work again with the Vulkan video driver on the Android version.
    • When you select a shader preset now, it should only show you the supported shader presets based on the video driver that is currently selected. In other words, it will no longer show you GLSL shaders and/or presets when you have selected the Vulkan video driver, just as an example.
    • Certain video features were never implemented for some platforms. We now hide features like Black Frame Insertion, GPU Hard Sync and Swapchain images if the video driver in question doesn’t implement them. It is conceivable that for some of these drivers, these features might be implemented later, but overall we feel it declutters the menu considerably by simply not showing settings that have no effect at all when toggled due to them being unimplemented.
    • We now expose certain convenience features on the Quick Menu, such as Latency, Rewind and Overlay settings. You can also hide these settings respectively by going to User Interface -> Views -> Quick Menu and disabling these categories.
    • The shader next/previous hotkeys are more intelligent now and deliberately skip over shaders that are not supported by the current video driver.
    • (For Linux users) Wayland should now have proper scaling with XMB menu driver.
    • (For Linux users) Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR.
    • On platforms where this is supported, ‘Set Display-Reported Refresh Rate’ is a convenient way of setting the exact refresh rate that the OS/video driver has reported to the application. This might be more accurate than measuring the refresh rate yourself by waiting for 2048 samples or more before hitting the Action button on ‘Estimated Screen Framerate’.
    • Display Framerate is now moved to ‘Onscreen Display – Notifications’. A handy feature showing all sorts of statistics is now exposed in this submenu as well.

RetroAchievements updates

The future is now. Arcade achievements using the FB Alpha core are fully supported in this version. This brings support for Neo Geo and Capcom arcade boards (Metal Slug, Marvel Super Heroes).

– Capture your greatest moments with the automatic screenshot feature! Look back fondly on the time you grinded your RPG character to level 99 for internet points.

– RetroAchievements on a retro computer?! Windows XP builds of RetroArch now support achievements!

General changelog

ANDROID/OPENSL: Prevent crashes when setting audio latency too low (buffer count can never be lower than 2 now).
CRT: Added CRT SwitchRes.
COMMON: Hide the ‘Core delete’ option if the ‘Core updater’ is also hidden.
COMMON: Add way to reset core association for playlist entry.
COMMON: Fix invalid long command line options causing infinite loop on Windows
COMMON: Add OSD statistics for video/audio/core.
COMMON: Added runahead system; allows you to drive down latency even further.
COMMON: Fix buggy behavior that could happen with ZIP file reading on some platforms as a result of not initializing struct.
CHEEVOS: Support Atari 2600, Virtual Boy, and Arcade (only Neo Geo, CPS-1, CPS-2 and CPS-3 and only with fbalpha core).
CHEEVOS: Add option to automatically take a screenshot when an achievement is triggered.
CHEEVOS: Fixed incompatibilities with Neo Geo Pocket achievement sets.
CHEEVOS: Store only login token, not password.
D3D10: Added D3D10 driver to release build. Has working shaders (Slang), overlay, and menu display driver support. Should be on par capabilities wise with D3D11 driver except for there being no hardware rendering right now.
D3D11: Experimental hardware renderer. Allows for libretro cores to use D3D11 for hardware rendering. First core to use this is PPSSPP.
D3D11: Increase backwards compatibility, shaders compile with Shader Model 4.0 now, added support for more feature levels.
D3D10/D3D11/D3D12: Fix crashes with completely black or white thumbnail textures in XMB.
GUI: Support disabling window decorations on Windows and Linux.
LIBRETRO: Addition – Functions to enable and disable audio and video, and an environment function to query status of audio and video enables.
LOCALIZATION: Update Italian translation.
LOCALIZATION: Update Polish translation.
MENU: Add Rewind/Latency/Overlay settings to Quick Menu, add options to show/hide them (User Interface -> Views -> Quick Menu)
MENU/RGUI: Only show Menu Linear Filter for RGUI and only show it for video drivers that implement it (D3D8/9/10/11/12/GL)
MENU/RGUI: Add User Interface -> Appearance options.
MENU/RGUI: D3D8/D3D9: Hookup Menu Linear Filter
MENU/XMB: Disable XMB shadow icons by default for PowerPC and ARM for performance reasons.
MENU/XMB: Left/right thumbnails are now automatically scaled according to layout.
MENU/XMB: Add Left Thumbnails (additional to the right).
MENU/XMB: Fixed left/right tab regression.
MENU/XMB: Fix scaling of tall images that were cut on bottom previously.
MENU/XMB: Menu scale factor setting now changes texts length, image scaling and margins.
MENU/XMB: Mouse cursor scales correctly now.
MENU/XMB: Add toggle to show/hide Playlist tabs.
MENU/XMB: Add menu layout – can switch between Desktop, Handheld and Auto.
MENU/XMB: Don’t load menu pipeline shaders unless XMB is selected (D3D10/D3D11/D3D12/GL/Vulkan)
MENU/VIDEO: Only show black frame insertion for the video drivers/context drivers that support it (so far this includes – D3D8/D3D9, OpenGL, Vulkan)
MENU/VIDEO: Only show max swapchain images if supported by video driver and/or context driver (so far this includes – DRM EGL context driver, VideoCore EGL context driver, Vulkan)
MENU/MaterialUI: Automatic DPI Scaling should be much improved now, now scales as expected at 1440p and 4K resolutions.
MENU/MaterialUI: Fix wrong calculation of an entry height causing long playlists to end up outside of screen range. This also could cause crashes on low DPI screens.
IOS: Fixed crash when opening downloaded roms from Safari or using the “Open in..” functionality. Added the compiler flag to support keyboard remapping to controls.
IOS: Fixed buffer overlap that caused a crash while trying to download GLSL shaders from the buildbot.
PS3: fix URLS
REMAPS: Mapping keyboard keys from more than one gamepad (works with dosbox)
REMAPS: Mapping more than one button to the same action
REMAPS: Unmapping buttons
REMAPS: Unmapping analogs
REMAPS: Mapping a button to trigger an analog response (tested with mupen, can run on SM64 with the d-pad now, triggers a full analog tilt)
REMAPS: Mapping an analog to another analog (having more than one analog mapped to the same output causes issues)
REMAPS: Mapping an analog to produce a button response
SCANNER: Should be able to scan dual-layer Wii disc images now, filestream code now supports files larger than 4GB.
SHADERS/SLANG: Slang shaders should work again on Android version and MSVC versions (basically all the Griffin-based versions).
SHADERS: If GL context is GLES2/3/Core context, Cg shaders are unavailable. Applies to shader list too.
SHADERS: Hide cg/glsl shaders from being able to be selected if D3D8/9/10/11/Vulkan video drivers are selected.
SHADERS: Hide slang shaders from being able to be selected if D3D8/9/OpenGL video drivers are selected.
SHADERS: Prevent crashes from occurring if we have the GL video driver in use and we try to skip to a slang shader through next/previous hotkeys
SHADERS: Fix shader parameter increase / decrease functions
SUBSYSTEM: handle savestates properly (cart1 + cart2.state0)
VULKAN/X11: Fix X11 Vulkan bug from Wayland driver.
VULKAN: Fix multi-line text spacing in menus with Vulkan driver.
WINDOWS XP: Add Cheevos support.
WINDOWS/MSVC 2003/2005/2010/2013/2015/2017: Add Cheevos support.
VITA: Bugfix for ‘PS Vita takes many time to start to accept input’ issue.
X11: Allow compositor disabling on X11 fullscreen through _NET_WM_BYPASS_COMPOSITOR
X11: Prioritize NET_WM_STATE_FULLSCREEN in true fullscreen mode
WIIU: Fix OOB read/write in keyboard driver.

What’s coming next for RetroArch

So, RetroArch 1.7.2 had some pretty major new features, right? By all indications, it looks like RetroArch 1.7.3 will be no different. So let us give you some sneak peek at what might be arriving down the road for the next version…

A Qt-powered WIMP desktop UI!

Ever since RetroArch’s inception in 2012 (and even way before that when it was just known as SSNES), we have stuck to our guns and insisted on a uniform menu experience that obviously took its design cues from mainstream gaming consoles like the PlayStation.

While this lends itself very well to game consoles and the like, there is also a very vocal minority (or majority, depending on how you look at it) that has definitely made it well known that they would really prefer a native WIMP UI at times to be able to do mundane tasks like select/load a ROM, or browse through a playlist easily with the mouse, etc. And certainly, an argument can be made that on a traditional desktop PC, it might not be ideal at all times to be confined to the same kind of input limitations as say a traditional gamepad.

For 1.7.3, the way we will try to reach for a concession with these users will be through the way of this companion UI. What you see in these screenshots will be a WIMP (Windows, Icons, Menus, Pointers) GUI powered by Qt. It will be available for RetroArch versions that run on PC Operating Systems like Linux, Windows and macOS.

The way we envision this UI to work is a bit like how it is possible in Steam to switch between Big Picture mode and the traditional desktop UI. We still want the console-style menus to be RetroArch’s main user interface and we believe this scales fairly well onto game consoles, mobile devices and handhelds. But there is no denying, as Windows 8 all taught us, that there is no such thing as one true universal UI that can scale well across every potential device, so the user should definitely have his/her options.

The two screenshots you see here are not just mockups, they are already operational in bparker’s branch. What you see here is the result of about one solid month of work, and it’s already reaching quite satisfactory levels.

We have kept a tight lid on it until now, but felt the time was right to reveal more details about it. We are doing this primarily for the users, and we hope that they will like it, and through designing this we are also trying to be more receptive to user feedback than we might have been in the past.

Despite all this, as with anything in our codebase, we do insist that from a programming point of view, that this will not impose any huge dependencies, and that all of these individual coding parts are modular in nature and can be easily compiled in or out of any build. With RetroArch we always have to walk a fine line between staying lightweight and not becoming perceived of being too bloated yet also trying to meet increasing user expectations, and it’s not necessarily always possible to be in the middle of these two opposing camps. So we try to do our best to satisfy both groups this way, and stay true to our design goals while also making sure that we keep the users happy who don’t care about the underlying codebase but just care about the results from an enduser perspective of what they can do with the program. It’s a big challenge and definitely a balancing act but we feel we have become better over the years in terms of finding the right balance.

2018 The Year Of The Libretro Frontend

Libretro, the underlying platform and ecosystem that powers most of what you see in RetroArch, will see an explosive growth throughout the rest of this year, both by our efforts and outside forces also only tangentially related to our project. You will see the Libretro logo not only in more places, but you will also see popular programs like Kodi finally adopting the API wholesale.

While it was never our direct intent to have our API be synonomous with retro gaming and emulators, we do not mind this being the biggest driver of growth in this emerging ecosystem and are grateful for the developments there.

RetroArch 1.7.2: Achieving better latency than original hardware through new runahead method

A new feature is coming RetroArchs version 1.7.2: Is it called “runahead”, which can be enabled within the usual settings. The idea is to literally get rid of the input latency. Which would even be an improvement – probably depends on the perspective – of the real hardware.

From their blogpost:

Even though sub-frame latency in software emulators has been achieved, some developers kept pushing beyond, and found a way to surpass even real hardware in response time. We have Dwedit to thank for this particular method.

Most systems more complex than the Atari 2600 will display a reaction to input after one or two frames have already been shown. For example, Super Mario Bros on the NES always has one frame of input latency on real hardware. Super Mario World on SNES has two frames of latency.

The Libretro forum post linked above provided patches to RetroArch that can effectively “remove” this baked-in latency by running multiple instances of a core simultaneously, and quickly emulating multiple frames at a time if input changes.

This strategy has some analogs to frame rollback, similar to how GGPO handles high-lag connections. And in fact, if you set the “read ahead” frames on the experimental builds ridiculously high, you can get a feeling for what’s going on behind the scenes.

Here’s another article from a few years ago illustrating the basic concept.

Accurate? No way. Fascinating? You betcha. Mere “same latency as real hardware” is SO last month…

This feature has since been incorporated into RetroArch and will make its first proper debut in the upcoming RetroArch 1.7.2. Users who want to get a sneak peek at this feature can already experiment with it by downloading the latest nightly version of RetroArch, and downloading the latest version of the Snes9x core.

Once the game is running, go to Settings -> Frame Throttle.

The setting ‘Run-Ahead to Reduce Latency’ is what you want to enable. From there on out, you can specify the amount of frames that you want to run ahead. Be advised that how well this will work with the game in question will depend on the game’s built-in amount of lag frames, so experimentation is key here.

Be aware that this method is highly resource intensive. The higher the number of frames you are going to run ahead of emulation, the higher demands it places on your CPU. For instance, Snes9x on a Core i7 7700k CPU would normally run at 1500fps with Super Mario World. With runahead set to 2 frames, we get 440fps. With runahead set to 4 frames, it will be lowered even further to 250fps. So fast cores are key for making this latency reduction approach feasible.

Right now, we are going to be enabling this feature for the Windows, Linux, macOS, and Android versions. Console ports that depend on static linking won’t be able to take advantage of this feature.

We hope you will look forward to this feature and tons of other exciting changes that will be packed into RetroArch 1.7.2! Playing Super Mario World and other SNES games with their built-in 2/3 frames of latency removed is definitely a game changer and will hopefully breath fresh air into these old games.

If you would like a technical breakdown of this method, read this post here by Dwedit, the author of this method (incidentally, he also made PocketNES a long time ago, a NES emulator for the Game Boy Advance which was a big breakthrough back in its day).

Source: RetroArch blog

RetroArch 1.7.0 Released

Merry Christmas everyone. Hope you are enjoying the days with your family.

Big Christmas release from the RetroArch release: RetroArch 1.7.0. Grab the latest release from here or from the Google Play Store.

From their blog post:

General changelog

– CHEEVOS: Add badges for achievements, shows thumbnail images of achievements.
– CHEEVOS: Leaderboard support.
– CHEEVOS: Only disable savestates on hardcore mode if achievements are not available.
– COMMANDLINE: Fix fullscreen toggle switch.
– COMMON: Add ‘Automatically Load Content To Playlist’ feature, enabled by default.
– COMMON: Fix slowmotion ratio always being reset back to 1.
– COMMON: Optimized NBIO implementations now for Apple, Windows, and Linux. Uses mmap for Linux/Windows/BSD if/when available. File I/O should now be much faster for loading images inside the menu.
– COMMON: Native Blissbox support now for latest firmware as of writing (2.0). Implementation through libusb and/or native Windows HID.
– COMMON: New lightgun API.
– COMMON: New VFS (Virtual File System) API.
– COMMON: Fixed some playlist bugs.
– COMMON: New snow shader.
– COMMON: Fix Quick Menu title, no longer shows ‘Select File’.
– COMMON: Fix loading cores that require no content one after another.
– COMMON: Map Delete key to Y button for non-unified menu keyboard controls.
– COMMON: Fix for relative paths being normalised and generating a duplicate history entry.
– EMSCRIPTEN: Fix references to browserfs.
– FREEBSD: Support libusb HID input driver.
– HAIKU: Buildfix.
– INPUT: Map clear button to DEL key.
– LINUX/X11: Add RetroArch logo to window title bar.
– LINUX/X11: Input driver now supports new lightgun code.
– LINUX/X11: Support window transparency (requires a compositing window manager).
– LOBBIES: Fix for crash on join netplay rooms via touch / glui.
– LOCALIZATION: Update Italian translation.
– LOCALIZATION: Update Japanese translation.
– LOCALIZATION: Update Portuguese-Brazilian translation.
– LOCALIZATION: Update Polish translation.
– LOCALIZATION: Update Russian translation.
– MENU: Snowflake menu shader effect.
– OSX/PPC: Fix the GL2 renderchain, had to use EXT versions of framebuffer/renderbuffer functions.
– PS3: HTTP requests / downloads should now work.
– PS3: Core Updater now works.
– PS3: Improved font rendering, enable STB Unicode font renderer.
– PSP: Make it work with Vita’s Adrenaline.
– PSP: Fix audio sync.
– PSP: Fix content loading, port should be functional again.
– PSP: Use 64MB when available.
– SCANNER: Fix crash from Windows-incompatible format string.
– VITA: Improve packaging, installation times.
– WIIU: Disabled the controller patcher for now since it was the source of many stability issues.
– VULKAN: Various stability fixes for WSI.
– WINDOWS: Add MSVC 2017 solution.
– WINDOWS: Get rid of the empty console window in MSVC 2010 builds.
– WINDOWS: Raw input driver now supports new lightgun code.
– WINDOWS: Use configured OSD/text message color on GDI driver.
– WINDOWS/XINPUT: Populate XInput VID/PID from DInput so autoconfig doesn’t rely solely on joypad names
– WINDOWS/XINPUT: Fix crash that occurs in some situations with Steam running and a Steam Controller plugged in.
– WINDOWS: Improve version reporting under System Information.
– WINDOWS: Support window transparency.
– WINDOWS: Correct usage of GetWindowPlacement per MS docs, fixes game window position on Win95/98.
– WINDOWS: Added Visual Studio 2017 support.


Integrated Bliss-box support

Grab the newest firmware for this device and you can enjoy out-of-the-box Blissbox support with RetroArch on the following platforms:

  • Linux
  • Windows

For more information, read this separate article here.

This is a legit game changer. This peripheral will allow you to use real physical gamepads from all sorts of different game consoles through one interface.

Right now, only one of these devices is supported.

Badges for achievements

Improved lightgun support

Lightgun and mouse support has been added to both Beetle PSX and Beetle/Mednafen Saturn.

In other input-related news, mouse support has also been added to Beetle/Mednafen PCFX.

Windows 95/Windows 98 (non-SE) support

In a time and era where big companies get lazy and just throw away 32bit support for anything from drivers to operating systems, we have gone to the complete opposite side of the spectrum and started adding even more ancient/obsolete systems instead.

We already had a Windows 98 Second Edition/Millennium Edition/Windows 2000 version of RetroArch. But now, we go back even further in time! The MSVC 2003 version is a version of RetroArch that works on Windows 95 and Windows 98 (the First Version, before Second Edition).

Some things you should know about this version:

  • Rough around the edges, has been mainly tested so far on VMs (Virtual Machines) instead of real hardware.
  • Uses GDI as the default video driver. Our Direct3D driver so far requires DirectX 9 and Cg. It will take some work to make it backwards compatible with DirectX8.
  • We omitted the Windows NT 3.51/4 versions for now. The main issue with these versions is that they do not support DirectInput, so we have no real input drivers available for them.

Right out of the gate, there are 21 cores available for the Windows 95/98 version. Not too shabby, eh?

For more information, read this separate article here.

Improved PlayStation3 port

So many important improvements that have been made to the PlayStation3 port as a result of our newfound friendly collaboration with an RPCS3 dev:

    • Downloads now work
    • Netplay now works. You can netplay between two PS3s, or with another system that is also of the big-endian architecture. For instance – netplay between RetroArch PS3 and RetroArch Wii U works. NOTE: There might still be some endian-specific code in certain cores that can cause bugs.
    • Content Downloader works. You can download many demos and freeware homebrew games from this.
    • Thumbnail Downloader works. You can download boxarts and titles/snaps for your games from here.
    • Core Updater works. Now you can directly download freshly updated cores directly through the built-in Core Updater. New cores will be added over time, and best of all, you don’t need to install a new RetroArch version in order to obtain these new cores either.
    • Improved font rendering inside the menu. Non-Western languages are now also supported by this improved font rendering, including Japanese, Korean, Chinese, Russian, etc.

New menu shader effects

PSP port works again

Wii U port works again

Wii U port should work fine again after some issues in previous versions.

Automatic scanning of content

This new option, when enabled, will add any new content you load from the file browser (Load Content) to your playlists. If a playlist does not already exist for the specific core and/or game, one will be created on-the-fly. This option is disabled by default, so watch the video if you’d like to learn how to enable it.

There’s more

There’s a ton more that we have properly not covered in this blog article, but we leave it up to the user to discover that for themselves.

What’s coming next for RetroArch

We will have a separate blog post on this soon, as well as more separate blog articles detailing some of the other progress that has been made on the cores front.

If you’d like to show your support for RetroArch, consider donating to them. Check here in order to learn more.

Appeal to game journalists – about Retro-Bit and about the new ‘retro emulation industry’ in general

From RetroArch blog, nothing more to say. Except, ignore who is disrespect creative work and does not respect the open source licenses.  Please read for yourself:


Dear game journalists and other members of the press,

We are beyond the point of desperation at this point, and we ask you dearly for your help in this ongoing problem. Independent entrepreneurs are playing loose and fast with the laws and licenses surrounding open source code, and we have found ourselves the victim of multiple copyright and license violations ever since Hyperkin started selling its Retron5 product back in 2014.

Since then, there has been an explosion of these products all opting for the same approach – take from opensource code, bundle it up in numerous incompatibly licensed ways, then to add insult to injury, strike up licensing deals with established players in the games industry and make it appear as if your product is ‘legitimate’.

Read up on our previous articles here for more information –

CyberGadget’s RetroFreak proven to use Snes9x Next/2010 code, non-commercial code being sold

RetroArch, Libretro core license violations by Hyperkin’s Retron5

To recap and to also add to it a new recent example of this (as in the case of Retro-Bit) –

2014 – Hyperkin Retron 5

Uses Snes9x (non-commercial emulator) and Genesis Plus GX (non-commercial emulator) together with various GPL-licensed emulators. The individual source code was a direct copy of our libretro repos. This is not the issue however – the issue is quite clearly that they are selling non commercially licensed emulators which obviously, as the license entails, cannot be sold.

Did they ever do anything about this, though? Nope. It is still being sold. They recently striked up a license with byuu to use his product Higan in the future, but this does not pertain to the Retron 5 as the hardware it is based on is obviously incapable of running Higan at fullspeed. That the same product is still being sold to this day is a clear-as-day license violation of Snes9x and multiple other parties involved. I hold copyright over portions of Snes9x these days too, and the forked emulator sourcecode that the ‘contractor’ has admitted to using (and which can be seen in the sourcecode archive they published, Snes9x 2010/Next) was all written by me. They have never bothered to rectify these issues.

2015 – Cybergadget Retro Freak

Cybergadget Retro Freak – uses an identical copy of Retron5’s sources. Cyber Gadget has admitted to us in e-mails that they did not write the software themselves but got it from a ‘contractor company’ (probably the same company that did the software for Hyperkin Retron5. As far as I am informed, this comes from a Hong Kong company whose identity is still unknown). So, the same problems apply here – uses Snes9x (non-commercial emulator) and Genesis Plus GX (non-commercial emulator) together with various GPL-licensed emulators.

After waiting for over two weeks on a reply back from them, I got an e-mail back where their anonymous developer (not them) had this to say about our grievances

“We used two versions of Snes emulator. One was Snes9x 2010, which was in turn taken from Snes9x, which had some speed increases added. The second was Verbatim snes9x. From both of these we only use the emulators and not their core code. As far as the file msvc_compat.h Mr Matteis himself says that he took this file and pasted it into many other projects. No doubt this is how this file containing RetroArchtext appeared in the archive on Cyber’s web site. As Mr. Matteis’s name does not exist anywhere in this source code we assume Mr. Mattheis is inferring that because we have this one file containing the word RetroArch posted on the web site then we must have used other files which are authored by Mr. Matteius’s. This is not true. We do not in fact use any core files merely use the emulator code as a library.”

Therefore, we believe we are not infringing on your copyright.

Also, these software are “GPL”, and we believe there is no problem for us.

This reply is obviously nonsensical, and betrays a complete lack of understanding of Snes9x’s licensing terms.

Snes9x is not licensed as GPL. It is licensed under a non-commercial, proprietary license. The entire emulator is licensed as non-commercial. Whether you use ‘core files’ or whether you use the emulator code as a library has no bearing on it. You cannot use this in a commercial product. Their product is illegal right now as it is currently being sold, and they’d have to do a complete recall and remove the infringing SNES emulator parts in order for it to become legal.

I have given them a reasonable amount of time to rectify their obvious mistakes and missteps. Will they choose to do the right thing though? Probably not. bearoso from snes9x meanwhile has taken it upon himself to try to get the product removed from Amazon, however, Amazon has been pushing back –


2016 – NostalGames RetroPac (defunct)

Here we had two college students who took it upon themselves to set up a crowdfunding campaign with Kissbank in France to try to setup a business around their ‘Retropac’ product. This product turned out to be just a derivative of Lakka, our turnkey RetroArch based solution.

The problem with this was that Lakka is non-commercial and comes bundled with various non-commercially licensed emulators, hence it cannot be sold. They did not care about this, and decided to carry on anyway.

We managed to successfully shut down their crowdfunding campaign, and that appeared to have been the end of this venture.

Unfortunately, we did not dedicate an article to this, so you will have to make do with our Twitter posts instead –




2017 – TekSyndicate Notice Me Sen-Pi

A popular Youtuber who goes by the name of TekSyndicate wanted to start selling a product based on Lakka. He was quite audacious about this and made a blog post about it full of hubris as to why he should be able to do this.

You can read our statement on this here –



We contacted Amazon and we were able to get this product taken down. Tek Syndicate has agreed to no longer bundle Lakka with his hardware device, and now resorts to a Do It Yourself video which explains to people how to install it on the hardware.

2017 – Retro-Bit Super Retro Cade

The latest situation.

Just recently, we have been contacted by Retro-Bit. To be more precise, one of our team members Andres Suarez was contacted in the past.

This is the latest e-mail we have received back from Retro-Bit – just mere weeks before they started selling their latest product Super Retrocade

I hope all is well. A quick E-Introduction, I am the marketing manager for Innex and our house brand Retro-Bit. In the past you were in contact with Andres Quiros regarding the possibly usage of Retroarch for our plug and play consoles with the caveat that when using “open source” software we would need to give credit then share any updates done to t he original code back to the community in the event they want to build upon it.

Since then, Andres had left the company and we recently released the Super Retro-Cade which I believe operates off Retroarch. We would like to provide the rightful credit to Retroarch and disclose the emulator and request the source code. They can retrieve it through a customer service page on Retro-bit with proof of purchase and waiver of liability forms.

As I mentioned in my previous email, our former Product Development Manager (Andres Q.) left the company in the middle of development, leaving Ron (copied) and myself to finish the product with a very aggressive timeline to launch. We were not aware of this situation, but want to work with you to find a successful solution.

We are a small company that competes directly with Hyperkin and like you, we want to expand the retro gaming to its fullest potential and support the community.

So, all we know in this instance is that they are using RetroArch. As long as sourcecode is being provided and as long as the license is being followed (GPLv3, that means no TIVOization), that would be no issue. HOWEVER, and here is where it gets troubling – they do not know themselves what emulators it uses. So, again, which contractor company was responsible for this cobbled together software again? Why does this keep happening? How come none of the licensees (Capcom/Data East/etc) were aware of this?

Here is where this gets troubling – it is yet again a cheap ARM SoC (System on a Chip). They admit to us over e-mail it is using RetroArch. But they cannot tell us which cores are being used because they “do not know”. ALL of the emulator cores available through RetroArch which provide SNES, arcade and Genesis emulation and which could conceivably run on this hardware, are all distinctly non-commercial. We are talking about Snes9x here for SNES emulation, Final Burn Alpha or older versions of MAME (MAME 2000/2003/etc) for arcade, and Genesis Plus GX for Genesis. They cannot be sold, period. So, again, we have the very same issue here as we have had with Hyperkin and Cybergadget. But instead of waiting until they have determined with us that this is not an issue, they start selling it anyway.

We are beyond demoralized and pissed off at this point. Ever since the NES/SNES Mini, this kind of activity has been going on and has been accelerating. Entrepreneurs and certain publishers are having dollar signs in their eyes. Games are being played with us and other members of the emulation scene by various parties (in this blog post I have probably left out a fair few other companies as well), and we are simply getting sick and tired of this abuse. This is hugely demoralizing and demotivating and makes us almost unwilling anymore to continue with it.

Stuff like this is hugely damaging to the goodwill of the open source community. If open source authors continue to find their licenses and rights trampled upon by a couple of entrepreneurs with the sole intent just to make money and these same entrepreneurs and their business partners don’t care about doing due diligence and making sure they are in the clear, opensource authors are going to stop contributing to open source projects altogether. The knowledge economy dies in doing so, leaving us all with yet more products cobbled together from various disparate sources with no greater aspirations beyond just making a buck.

External examples

Let us cite some other examples how open source emulator authors have been taken advantage of in recent months. I refer you to byuu’s tweets on the subject –

This same small-time game publisher tried buttering us up to do business with him too over e-mail, until we informed him that we did not like how byuu had been mistreated in the past previously. In response, he launched into an angry tirade against byuu. A few hours later, byuu sends me an e-mail message imploring me not to involve or associate myself with Piko Interactive in any shape or way.

To which the founder of Piko Interactive responded to byuu in this way –


Dude Nobody asked you to drain your 401k and max out credit card to spend on super famicom stuff or projects. Thats you own decision. If you are looking for sympathy and/or praise you are not going to get them from me. You did it for the love of the console? Then great, don’t complain. Im pretty sure you are old enough to make your own financial decisions.

As I told Daniel, why would I pay you for something that you offer no support and it is hard for a regular programmer to compile? The whole 6 months (which I think it was far less) shiru spent all his time and effort trying to understand the spagetti code that higan was. He just couldn’t get it to work the way you provide it, sorry, Im not going to pay for something I cannot use. That is like me going to buy a car for my communte but the salesman is giving me all the engine in parts that I have to assemble; I can look into assembling the engine, but if doesn’t work out, Im not going to buy it, And I am expecting the salesman to undersatnd that I am not going to buy something I cannot use.

If you are too concern about making money off your emulator (which is a good product) why do it GPL? Why not just sell a license and not offer it for free? Like flying tigers, digital eclipse, nintendo, and others?

We posted instructions online on how to get the source code, which was by request. I could even made it difficult and do it by mail only and charge a mailing fee and would be still ok. Also, Im pretty sure that there is credit to mednafen there somewhere on the steam page, at least on the listings we control. Bubsy I dont control, and we gave instructions on what to write in regards the mednafen licensing and instructions to post on how to get the source code. If Tommo didn’t posted them, that is not my problem.

Also, why would I give credit to byuu if we are using mednafen? If someone is curious what emulator is using, then they go to the page where it gives that information, and then they read up on mednafen, and see it uses bsnes core.

Call me what you want, (worst than hyperkin, yada yada) at least I don’t talk behind people’s back, specially the ones that make me money ;).

Take a couple of business classes, may come in handy. Or may I suggest to partner up with someone that understand basics in business.

Is this the way we as developers should be treated? As less than human? Byuu personally drained his 401K out of a passion to preserve the Super Nintendo forever. Everybody, including Nintendo themselves, is forever indebted to him for taking the time to document the Super Nintendo where nobody else cared, including its entire software library, to the point where people can now use this documentation to their own advantage even to make themselves some money with re-releases of new classic consoles. And what does he get back in return? Openly spit in his face like this? Needless to say, we refuse to associate with Piko Interactive after having read these very disrespectful comments.

Basically, we find it to be a grave injustice how all of us as a scene and as individual independent authors are being treated and manhandled by industry forces that only care about respecting licenses and copyrights when it suits their products, but don’t care a whit when it involves the little guy, the guys who can’t hire an army of lawyers to combat misuse of their software. This is a disgrace and we find it similarly interesting how this same games industry continues to keep up this pretense that emulators are this ‘grey area/non-legit’ subsector of videogames and how no attention should be paid to it, yet they have no problem doing these kind of licensing deals with companies that just crib from those same emulators and even disrespecting their licenses at the same time.

We are being treated abysmally, by people whom feel themselves to be in positions of power so that they are able to do this and get away with it.

We are also completely bogged down by this mess. Each and every month a new contender comes along, doing the very same thing, that we then need to either respond to or deal with. This is hugely demoralizing and demotivating to my team members, and there is not a surplus of developers around to keep working on these projects to begin with. There becomes a point when honestly the undying passion we have for our project to keep going is being outdrowned out by these cynical and deplorable attempts to make a quick buck off our hard work at our expense and violating the licenses in question. We don’t know where to go from here quite frankly, we just felt it was worth a final last-ditch attempt to bring this to your attention. Where we go from here, is not decided yet. We never even intended RetroArch or Libretro to be a purely emulator-focused experience, we intended it to be a great ecosystem where software could be made modular and run in various frontends. That it instead has amounted to a nostalgia cash grab by various companies who are at great pains to delegitimize our efforts yet have no qualms with doing business deals with companies whom don’t hold any of the rights for the software they are exploiting – for its various disparate emulator cores to be manhandled and abused and misappropriated like this, pains us greatly to see happening. This is end-stage capitalism, pure and simple, and we are the unwitting victims of it.