Development Suggestions


Oops……I mean translate the RetroArch itself:smiley:


Oh, in that case, we already have a bunch of translations! Go to settings > user > language, set it to your language of choice and then close and re-open RetroArch (many of the words are translated immediately upon changing the option but closing/re-opening ensures that nothing is missed accidentally).


SRAM Autosave issue:

Assumption: SRAM is held in memory during emulator running.

Test to determine whether it is safe to write SRAM to disk:

  1. Detect change in SRAM
  2. Note timestamp of change
  3. If last SRAM change was greater than T seconds ago (e.g., 10 seconds), write SRAM change to disk. Else, disregard SRAM change and do not write to disk.

I think this is maybe what someone mentioned as heuristics and that it could introduce edge cases, but consider this may be better than current system. Effect of this would be that games that are using the SRAM as working memory would fail the test and never write to disk, because a game that is using SRAM as working memory would be writing more than every T seconds (and any edge case that contradicts would not risk ruining disk or performance anyway because it is only manipulating the SRAM every 10 seconds). Otherwise the game would pass the “safe to write” test and will write SRAM to disk immediately. Adjust T to be appropriate amount of seconds (it seems 1 or 2 seconds is probably fine)

Related bounty:


That wasn’t my point.

The problems: You can’t have a mix of hotkeys and non-hotkeys. I would like a dedicated Escape and Reset button but use a hotkey for Save, Load, Rgui, etc But you can’t do that because the hotkey system is not ideal and limited to only certain features

Would be nice if I could make my Start button also my Select button by holding down the hotkey (shift key) Would be nice if I could hold shift and push up on my joystick for Vol+ and down for Vol- while still having dedicated Esc All buttons should support a “shifted” state. Or maybe a combo state. input_volume_up = shift+a input_volume_down = shift+b

For my setup, I disabled hotkey. This allows me to have dedicated buttons for things like Esc, Reset, Save, and Load. But I did not find a way to map a gamepad control to Esc as a dedicated button. For example, if I wanted to be able to hit the Select button on my gamepad to Esc, and no other buttons… it doesn’t seem to work.

While it might not make sense when you think about a gamepad, I’m referring more to encoders like ZeroDelay and XinMo which can’t be wired up as a dedicated arcade button for Esc or Reset. So my only option is to use a keyboard encoder from


I’d like to see easier/more flexible controller mapping— maybe something similar to MAME or other emulators where you can just select a button or axis on a controller directly. It would make mapping controllers per core a breeze, especially for controllers like the N64, Colecovision, Intellivision, etc.


Can someone help make a image for lakka for the orange pi zero and the orange pi zero 2 plus h3 processor


I’d like to request some sort of relative folder implementation for use in the iOS config files.

Currently iOS configs include what looks like the full path to any folders in the app sandbox files section (“Documents and Data”?). Unfortunately, this path includes the app ID (I’m not sure if that’s the right terminology) which changes every time the app is rebuilt/installed, meaning that you have to go through and manually edit your config files every time you update the app to use the ID.

For example the “system” folder might go from /var/mobile/Containers/Data/Application/ABCD-EFG-1234-5678/Documents/Retroarch/config/system to /var/mobile/Containers/Data/Application/ZYXW-987-451-1451/Documents/Retroarch/config/system

Given that retroarch config setups can be quite complex (for example, if you want the GB shader for gameboy games but a CRT shader for home console games…etc.) it would be a lot easier if the configs did not need to be manually edited with every build. Now, I’ve learned this based off of how the app itself saves configs, so if I missed an easier way of handling this please let me know.


Underlays/in game backgrounds Since so many games have different aspect ratios I think it would be great to have an underlay image option. Overlays sizes have to be changed when sized as borders for different aspects to avoid blackspace between it & the viewport underlays would show in whatever blackspace there is outside of the viewport. It would be great to save per core too.

Right now I have generic Genesis border overlays (the red stripe & the black/grey lines) but on auto aspect I come across games with varied viewport sizes (Such as the ultra wide Adventures of Batman & Robin). Retinkering overlay positioning sucks having a backdrop to fill that 16:9 black bar area in any case would be awesome.


Hi, I know the main thing is to improve the UI, the amount of colors and their quality, but I wanted to install lakka (.iso) for ‘multibootusb’ to open with other distributions, I researched a bit, and I am not the first to try, And I do not know how to program either So even if it is not possible to increment this function, I would like to know of some script that will make this possible. Translated text.


I was working over a custom controller overlay tonight, and ran into some small limitations and a bug/oversight. So, I have a couple overlay-related suggestions to make it more visually-capable.

Bug/oversight: If you use an overlay to target multiple buttons (eg: overlay0_desc4 = “left|down, 0.0, etc…”), there doesn’t seem to be any way to make the appropriate buttons on the overlay light up. Maybe this could be solved with something like “overlay0_desc4_proxy = desc0,desc1”, to tell the appropriate overlay elements to light up.

"alpha_rest" and “alpha_press” with normalized alpha values. (0.0 to 1.0 = 0% to 100% opacity)

This would be useful for overlays with decorative elements, and allows for tighter control over how overlay elements are displayed. The example image above uses a single transparent overlay image for the line art/button names, and two simple images shared across four per-button overlays.

By using normalized alpha values, overall overlay opacity could be controlled via Onscreen Overlay > Overlay Opacity. So for example: If an overlay features the lines “overlay0_desc0_alpha_rest = 0.5”, but RetroArch’s Overlay Opacity is set to 0.70, “overlay0” would end up displaying at 0.35 opacity.

(If “alpha_mod” is defined, “alpha_press” could be used to determine how bright a button should display.)

"overlay_rest" and “overlay_press”, allowing different images to be used for rest/press states.

The example image above is styled to be simple - All essential buttons have two states, and feature transparent markings when pressed. Additional examples: buttons that “physically” push in, or a D-Pad represented by an arcade stick that “snaps” between directions using an image for each directional input (instead of using analog controls and a moveable overlay to approximate the effect).

I’d also suggest allowing “nul” as a valid option for rest/press states, so that an overlay can be told to display literally nothing while in a specific state.


There’s already a trick you can do with the alpha mod setting to achieve something similar, though you can’t get the nice reverse-print effect: save a second set of filled buttons that have identical coordinates to the button outlines. Take those filled buttons into photoshop/gimp/whatever and set the opacity to 1% and then in your overlay.cfg, set your alpha_mod setting to 100.0. Most overlays use 2.0 for that, which represents a doubling of the opacity, so setting it to 100 makes it multiply the opacity value by 100x, taking your 1% opaque images up to fully opaque.

The rest of the stuff would have to be added and the question becomes whether it’s better to shoehorn it into the overlay system or have another system that’s specifically designed for this sort of thing (ditto for the overlay borders that people like to make).


Oh shoot. I almost stumbled across that trick myself, I just hadn’t thought to alter the filled button images themselves. Works rather nicely, thank you! I can live without the reverse-print effect (or use the same alpha-mod trick to fake it), but figured there’s no harm in making a suggestion.

I noticed that border overlays tend to be created more often than controller overlays. Admittedly, having both types of overlays being referred to as just “overlays” has made searches a little confusing.


Quick suggestion, hope this gets added soon since we really need it!

Is there any way you can add touch controls, or have them be enabled straight away on Windows? I’m using the linx vision which has windows 10, but it’s a tablet, and retroarch doesn’t have touch controls so I can’t use it in anyway.


touch controls are already there, you’re just going to need to do a little cfg editing if you can’t hook up a keyboard.

Open your retroarch.cfg in a text editor and change “menu_driver” to “glui” and “menu_pointer_enable” to “true”. You’ll also probably want to set “menu_unified_controls” to “true”. This will give you the same menu and behavior we have on mobile devices. You’ll probably want to use a nightly build if you do this, though, as 1.6.3 had some unfortunate touch-related bugs.

Once you can move around in the menus with touch, go to settings > onscreen display > onscreen overlay and use the ‘overlay preset’ option to find a gamepad overlay. I suggest gamepads > flat > retropad.cfg. Then use the “display overlay” option to enable it.

If the touch menu is getting on your nerves and you would rather navigate with the touch gamepad, just disable “hide overlay in menu” and it will show up and cancel out the touch input. Once that’s done, you can also switch over to the fancy xmb menu–which doesn’t support touch on its own without the gamepad overlay–in settings > driver > menu if you like.


While you’re on that subject, is there any possible trick when designing an overlay to define an area where the touchscreen would not react to fingers?
Like described in that issue, both interfering prevents using an overlay gamepad + touchscreen as a mouse simultaneously in Doom.


Not that I can think of, no :frowning:



I don’t know how to create a new thread here, so i’m posting here…

I’d like to create a 20$ bounty for a Solarus Engine core. I really like solarus engine, and i think it’d be a great fit for retroarch. And i’m sure it’d also help the solarus engine project to get more people to create zelda games.

Would it be possible, to port solarus engine to libretro?

I’ve created a bounty source account, but i don’t know who to create a new bounty. Thx


@Talantyyr : you should post in Bounty discussion category. First you need to create an issue on RA github issue tracker then it will get the bounty label.


Thank you. Done. And the bounty is up already :slight_smile:


No problem you are welcome, cool !