[Request] per game core option storage

[barbudreadmon]

I've been thinking about this for a long time.

Did you ever take a look at your retroarch-core-options.cfg file after playing at a lot of fbalpha games ? Every game add some entries to it (dipswitches, macro mapping, etc... can be more than 30 entries for one game sometimes), and at some point the content of this file becomes a nightmare to read/edit, and you need to be able to read/edit it sometimes, because some bug may appear with some games if you don't reset dipswitches from time to time after a major update.

So is there a way to make use of the core option mechanics in the ui, while storing some specific settings (let's say all those which start with "fba-macro" or "fba-dipswitch") to an alternate file (let's say SYSTEM_DIRECTORY/fba/config/gamename.ini ) ? Kinda like mame or fba standalone store some settings to a gamename.ini file. It would also allow me to add more entries to this file, like a full customizable mapping for a specific game (again, like mame or fba standalone), accessible from the retroarch ui, without fearing that the retroarch-core-options.cfg file will grow even larger.

[barbudreadmon]

In case i wasn't clear, my issue is that "RETRO_ENVIRONMENT_SET_VARIABLES" handle both presenting variables to the user, and saving them to the retroarch-core-options.cfg file. And what i would love is having a way to present variables to the user, while using some custom logic (possibly just a file destination) to save them.

[barbudreadmon]

It would be really nice if someone working on the libretro API answered. The current limitations basically prevent me from fixing all input mappings issues in fba :

• We need a way to customize all input mappings for a game, the way things are now, people will keep complaining about weird layout or missing inputs, core remapping is nice for console emulators, but too narrow for arcade emulators. That's why things like the mame osd exists.
• The only mean available to fba is through the retroarch ui (core options, or potentially something new), because unlike mame there is no osd in fba.
• Storing all those settings in retroarch-core-options.cfg seems like a really really bad thing, some arithmetics : dipswitches + macros + inputs would mean between 30 and 100 entries per game, with up to 10k+ games it would mean fbalpha would potentially generate between 300000 and 1 million entries in this file.

My idea would be to leave untouched current "RETRO_ENVIRONMENT_SET_VARIABLES" behavior, and add some new calls (or whatever you call them) :

• RETRO_ENVIRONMENT_SET_VARIABLES_ALT_DEST to set a destination file
• RETRO_ENVIRONMENT_SET_VARIABLES_ALT to present variables to the retroarch ui
• RETRO_ENVIRONMENT_GET_VARIABLES_ALT to get the variables

Of course the call names i used are just for reference

[andres-asm]

Wouldn't it be better to expand core input remapping? to cover your use cases? What are you missing?

That said there's an issue about the limitations I've found, it's been there for two years, and no traction.

Honestly the core options system is terrible IMHO, only supports pre defined values, and it's always a string list, doesn't support integer or float ranges, and doesn't sync values over netplay, that's why there was a extension talked in libretro-arb but that project is DOA.

Also hear in mind that core input remapping is front-end based unlike core options that change the core internal state which means that changing stuff in remaps on one side (talking netplay here) doesn't affect the other and it works as expected.

Everything input related should move to be front-end based on my opinion, macros, turbo, keyboard remapping should be possible without a single line of code in the cores.

On Tue, Aug 29, 2017, 9:25 AM barbudreadmon notifications@github.com wrote:

It would be really nice if someone working on the libretro API answered. The current limitations basically prevent me from fixing all input mappings issues in fba :

• We need a way to customize all input mappings for a game, the way things are now, people will keep complaining about weird layout or missing inputs, core remapping is nice for console emulators, but too narrow for arcade emulators. That's why things like the mame osd exists.
• The only mean available to fba is through the retroarch ui (core options, or potentially something new), because unlike mame there is no osd in fba.
• Storing all those settings in retroarch-core-options.cfg seems like a really really bad thing, some arithmetics : dipswitches + macros + inputs would mean between 30 and 100 entries per game, with up to 10k+ games it would mean fbalpha would potentially generate between 300000 and 1 million entries in this file.

My idea would be to leave untouched current "RETRO_ENVIRONMENT_SET_VARIABLES" behavior, and add some new calls (or whatever you call them) :

• RETRO_ENVIRONMENT_SET_VARIABLES_ALT_DEST to set a destination file
• RETRO_ENVIRONMENT_SET_VARIABLES_ALT to present variables to the retroarch ui
• RETRO_ENVIRONMENT_GET_VARIABLES_ALT to get the variables

Of course the call names i used are just for reference

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/5375#issuecomment-325680710, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0PNgcz4NI5TYloYlBotLAKLKpz77ks5sdB88gaJpZM4PDaN5 .

[barbudreadmon]

What i need is a way to customize input mapping per game, there is just too many different input layouts in a multi system emulator to have a "working for every player and every game" input mapping set by default and without the possibility of customization, and iirc someone ( probably @twinaphex ) told a few months ago there won't be such a feature implemented in core input remapping.

Also, having such a feature in the core input remapping wouldn't solve the issue with retroarch-core-options.cfg growing for every launched game (because of macro and dipswitches).

From what you told me about the difference between front-end related stuff and core options, it indeed would make sense to have the same dispswitches on both sides, and different input/macro on both sides.

Since allowing core input remapping on a per game basis is (or was) not an option, and wouldn't solve the whole issue, i can only see improving core options system as a solution :

• having a way to declare which variables need sync and which doesn't
• possibility to set alternative file name
• support for more types would be nice indeed (integer, float, ranges, and perhaps some kind of on press input detection).
• perhaps having a way to create submenu in core options

We could probably set all of those informations to a new and more complex type of retro_variable struct, let's call it the retro_variable_advanced struct, and have the front-end apply different logic depending on the kind of struct passed as a parameter to the RETRO_ENVIRONMENT_SET_VARIABLES call.

[barbudreadmon]

The new struct could probably look like this :

struct retro_variable_advanced { const char key; const char value; // some kind of json encoded value to keep type ? can be null if "input' is set as type const char need_sync; // true or false const char type; // "input" if it should detect key pressed, or "choice" if it should make use of the value above const char submenu; // Null if not in a submenu, otherwise the name of the submenu const char filename; // Null if default retroarch-core-options.cfg };

[andres-asm]

Edit: sorry for the long-ass post. This kinda frustrates me too since I've wanted to fix many of these things for a long time

What i need is a way to customize input mapping per game, there is just too many different input layouts in a multi system emulator to have a "working for every player and every game" input mapping set by default and without the possibility of customization, and iirc someone ( probably @twinaphex ) told a few months ago there won't be such a feature implemented in core input remapping.

Well I think there are still some things that should be leveraged by core input remapping. Yes it's impossible to provide defaults that will make happy everyone but you have already achieved a lot.

One thing I would change is how neogeo "classic / newgen" is implemented, right now it's a core option. Simply making each of these two a "controller"

https://github.com/libretro/RetroArch/blob/master/libretro-common/include/libretro.h#L1184

That is one less core option at least, basically you would have a "NeoGeo Classic" and a "Neogeo Newgen" controller and that would be fully transparent on netplay and handled properly by core input remapping.

I think macros (3 punches mapped to a button) and stuff like that should be fully handled by the frontend. It's after all similar to what remapping does, what we need is something added to the API, virtual buttons, macro buttons, or something like that and of course help implementing it in the frontend. The same for "turbo buttons" that are becoming prevalent in so many cores... We need an universal frontend solution.

https://github.com/libretro/RetroArch/issues/3671

Of course in the meantime having them as core options is the only sane viable option.

As for dipswitches, yes I guess core options are the only alternative ATM other than having a small OSD, we could make a soft rendered OSD with nuklear and include the DIP switch values on the savestate I guess. That way stuff that doesn't touch the internal state (preferred aspect ratio for instance) could remain as a core option, and DIPS, BIOS choice, etc could belong on this small GUI. If you're interested I could try to come up with something.

Sadly as I said before API improvement has stagnated, we're kinda stuck, No-one is really looking over for what's best in the long run for the API, there are already issues that have already been that would require an extension, and if you check them up, basically I think we've covered all the bases.

https://github.com/libretro/RetroArch/issues/4516 https://github.com/libretro/libretro-arb/issues/35 https://github.com/libretro/libretro-arb/issues/29 https://github.com/libretro/libretro-arb/issues/18 https://github.com/libretro/libretro-arb/issues/12 https://github.com/libretro/libretro-arb/issues/6

I'm personally ok with whatever you come up since the API doesn't really provide any way around the issues. If it's only for the core options file size though I wouldn't worry, users aren't meant to see the file anyway :p. That said I introduced an option you may not be aware of:

Once that is enabled you have this option that you can select to have a core options file just for that content:

Maybe we could extend that somehow (without anything big happening on the API side) Make the core request the core option storage in scenarios were it makes sense.

The problem with this feature is that it uses the same instance of core options manager we have already so sometimes options "leak" from one file to another but that's something we should fix anyhow.

I think leveraging core options for anything that affects the internal core state is bad but it seems to be just my personal opinion.

[dankcushions]

Well I think there are still some things that should be leveraged by core input remapping. Yes it's impossible to provide defaults that will make happy everyone but you have already achieved a lot. One thing I would change is how neogeo "classic / newgen" is implemented, right now it's a core option. Simply making each of these two a "controller"

this is a cool idea that would make sense for other situations. for example: madcatz/hori arcade stick layouts. in the arcade cores it's impossible to provide sensible retropad bindings that apply to ALL arcade controllers, as they have different layouts, which makes fighting games all messed up, but there are a few common types that could be implemented in the above way I think?

i need to look into this!

[barbudreadmon]

Well, if i implement a way to set all mappings in core options, i intend to remove all the actual controller scheme stuff, otherwise it would be confusing

[andres-asm]

That would be worse than the current solution from an ecosystem standpoint. It's your call of course but I think improving the API and having cores behave "properly" within what the API allows would be better.

[barbudreadmon]

Basically, i want something closer to fba standalone and mame, the current controller scheme stuff is just some kind of hack to get around the fact there is no mame-like osd in fba. Some games have weird default inputs upstream, or use tons of buttons, so they are hard to handle in libretro without this mame-like osd, that's especially true for majhong games, twin stick games, collecovision, or some shooters.

[andres-asm]

Well, in my opinion you have the best arcade core, because it works like a proper libretro core. You change stuff in libretro menus.

I understand you point of view but in my personal opinion it would be bad.

You are mantaining the core so I think it's up to you.

[inactive123]

I honestly think this would be bad yeah, and I definitely wouldn't want to see default input mappings getting removed like this.

The last thing I want is for it to be necessary for the user to hand config all sorts of control schemes, convenience should be the number one priority right out of the box, and the RetroPad is always a given, it is always available in any libretro front.

[andres-asm]

he doesn't plan to remove it but move it to core options since input remapping is limited.

[inactive123]

You could look into making alternative control schemes for FBA like what was done here for Tyrquake -

https://github.com/libretro/tyrquake/blob/master/common/libretro.c#L473

I truly don't se what the issue here is. You have more than enough flexibility and customization at your fingertips with the API as is already.

If the issue is that you aren't able to hook up macros, well, the original games never featured any macros to begin with. Not sure what you want us to do here. I am generally fairly negative on any changes to the libretro API unless it is

1) absolutely necessary and there exists more than one use case for it that is not completely niche, and 2) it doesn't break backwards compatibility and it doesn't break ABI.

Also, RA already has turbo button features. What about them is not good enough as of right now? I'd rather we explore these options on the frontend instead of overburdening the API itself.

[inactive123]

I agree with radius in so far as that frontend solutions should be considered before we even begin to think of adding all sorts of superfluous hooks and interfaces to the libretro API to accomodate for more advanced input control options.

[andres-asm]

I think we should figure macros and turbo on a frontend level. BIOS, DIP switches, etc should remain in core options for now in my opinion.

[inactive123]

I definitely would like macros in RetroArch, having certain actions/buttons be triggerable by certain button combinations has been an oft requested feature.

[barbudreadmon]

So, let's ignore majhong games and other games with weird inputs... How would you proceed to map inputs for coleco without adding something to set all mappings ?

This system controller had a stick + 14 buttons, and from what i understood, games used different buttons depending on an overlay you put on the joystick.

On mame and fba standalone, if you don't want to play with the default keyboard settings, you are supposed to map every needed input for a specific game to your controller (which mean on a per game basis). I don't see how i can deal with that in fbalpha-libretro without adding either a mame-like osd or something in the retroarch ui to fully customize mapping for a specific game : the retropad doesn't have enough button and, even if it had, having the same mapping for every game would probably be weird.

[andres-asm]

Yes in cases were there is a keypad or keyboard the only way now is core options, that's why I linked that input remapping limitations issue. I've been thinking about a keymapper environment call for a while which if enabled would override the normal controller and allow you to map buttons to arbitrary keyboard keys. It would use all RETRO_KBD keys by default but there should be a way to specify a subset.

If I ever manage to implement this you could set the device to keymapper and the RA front-end would do the rest..

But for regular arcade (which is fba's specialty). Using the controllers API should be better.

The same should apply for Genesis/PCE.

On jue., 31 de ago. de 2017 5:02 a.m. barbudreadmon < notifications@github.com> wrote:

So, let's ignore majhong games and other games with weird inputs... How would you proceed to map inputs for coleco without adding something to set all mappings ?

This system controller had a stick + 14 buttons, and from what i understood, games used different buttons depending on an overlay you put on the joystick.

On mame and fba standalone, if you don't want to play with the default keyboard settings, you are supposed to map every needed input for a specific game to your controller (which mean on a per game basis). I don't see how i can deal with that in fbalpha-libretro without adding either a mame-like osd or something in the retroarch ui to fully customize mapping for a game : the retropad doesn't have enough button and, even if it had, having the same mapping for every game would probably be weird.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/5375#issuecomment-326250265, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0Nq1Ua5_klJnb2cgfTUKtrW4M79mks5sdoTMgaJpZM4PDaN5 .

[barbudreadmon]

But for regular arcade (which is fba's specialty). Using the controllers API should be better.

I agree with that, except there doesn't seem to be a lot of alternative for coleco emulation in libretro, except mame which is a little painful to setup, and doesn't run really well on embedded. People have been asking me for some time to fix coleco inputs.

[Tatsuya79]

I added some missing things in bluemsx recently to play coleco games. But yeah, I left some keys on the keyboard when I mapped the gamepad and I'm not sure you can change the buttons.

[barbudreadmon]

I tried to implement retro_controller_description/retro_controller_info stuff to fbalpha, it seems to work, let me know if you see anything weird : https://github.com/libretro/fbalpha/commit/d6247cb2b7cf63cda91b2d9f3ec4237cd7eebfa0

[andres-asm]

Btw I'm working on a keymapper for the front-end, and it may work for macros and better GamePad remapping in the future too.

Hopefully it won't be too long

On Sep 8, 2017 8:04 PM, "barbudreadmon" notifications@github.com wrote:

I tried to implement retro_controller_description/retro_controller_info stuff to fbalpha, it seems to work, let me know if you see anything weird : libretro/fbalpha@d6247cb https://github.com/libretro/fbalpha/commit/d6247cb2b7cf63cda91b2d9f3ec4237cd7eebfa0

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/5375#issuecomment-328244437, or mute the thread https://github.com/notifications/unsubscribe-auth/ABpC0AM7hcYc0T9CU_QTffgVeOgcUyfEks5sgeQTgaJpZM4PDaN5 .

[barbudreadmon]

closing, nowaday per game core option are available