batocera-linux / batocera.linux

batocera.linux
https://batocera.org
Other
2.03k stars 522 forks source link

Conflicting batocera.conf setting names #4936

Open Hew-ux opened 3 years ago

Hew-ux commented 3 years ago

Multiple emulators have similar settings in their PER SYSTEM ADVANCED SETTINGS such as internal resolution, anti-aliasing, etc. Internally, Batocera typically stores these settings as <system short name>.<setting>=<value>, which is fine for the most part as setting this within ES as an advanced system setting will force it to only apply to that system.

The problem arises from when multiple different emulators use the same internal name for a setting, but use a different syntax for the setting itself. For example, Dolphin uses values 0, 1, 2, 3 etc. for its anti-aliasing setting, but Mupen64Plus may use 1x, 2x, 4x, 8x, etc. for that same setting. If both of these emulators are using anti-aliasing as their key name for this setting, and the user sets global.anti-aliasing=2 as a setting, then that's a setting that will be valid for Dolphin but not for Mupen64Plus. This is a theoretical example, as Mupen64Plus actually uses mupen64plus_AntiAliasing for example as its keys (I assume as a workaround to this very issue).

But for a real, actually-in-Batocera-right-now example, PPSSPP, PCSX2 and Dolphin all share the internal_resolution name despite using different syntaxes for them. If the user tries a global.internal_resolution=2 setting in batocera.conf, they will get invalid settings for at least one of these emulators.

Right now, internal resolution of 2 sometimes doubles, sometimes triples, sometimes is completely invalid (depending on the emulator's literature). It should not be assumed that you can just take the value as it is as the user could set something you did not expect.

There are three general fixes to this: A.) Treat emulators with shared setting names but unique values like this universally as other emulators have, like how mupen64plus handles its settings right now eg. mupen64plus_AntiAliasing=2. In this case, we would have a dolphin_internal_resolution, pcsx2_internal_resolution and ppsspp_internal_resolution using each of their own syntaxes respectively instead of internal_resolution for all. I want to be clear, right now, mupen64plus is the exception, as it already has its settings stored uniquely as mupen64plus_AntiAliasing despite there being other emulators that also have anti-aliasing settings. Implemented: https://github.com/batocera-linux/batocera.linux/commit/02b6d2c335c911f9aeefb8efae6c6bfa2fa8bb48#diff-4a7d34bdca13d04a298149dbca7a7e849dffbe64acf6846cac3069776252069fR94

B.) Edit the config generators to convert the values from batocera.conf's internal_resolution line to the one appropriate to the emulator. eg. global.internal_resolution=2 to be converted to always equal a doubling of the internal resolution no matter the emulator's own setting syntax. This would require editing the way the setting value is interpreted for every emulator that has been set up such that it simply "grabs" the value as-is from batocera.conf and implements it into the emulator's configuration files. This would be the most understandable to the user.

C.) Add common settings like "internal resolution" (which pretty much every 3D game emulator has) to the common Game Settings menu, and treat it like all the other common game settings (ie. it has to be mentioned in the es_features.yml as an available setting, just like ratio, shaders, pad2keyboard, etc.) This option would by far be the most work to implement, as every generator that uses internal resolution would have to be fixed and batocera-emulationstation would need to also incorporate these settings, but this would be objectively the best for the user experience.

I am not experienced enough with Batocera to implement this myself, but may look into this in the future when I am.

Alternatively, as a "quick fix", we could just change the already existing lines like mupen64plus_AntiAliasing to just antialiasing, so that way it's at least consistent.

nadenislamarre commented 3 years ago

option A is good. common options are not so easy, while there are not always really common. for example all emulators doesn't support the same list of value.

Hew-ux commented 3 years ago

Please read it again. I address this.