Game specific configs

[kalaposfos13]

With this PR, you can create a new config file in userdir/configs/ named CUSAXXXXX.toml, where CUSAXXXXX is the ID of the game you're making the config for, and you can put any option in it that you'd like overwritten for that game only. For example, if you want to have readbacks turned on for every game, but have DMA only for SotC, you can turn on readbacks in the main config (which is still userdir/config.toml), have DMA turned off there, then make the userdir/custom_configs/CUSA08809.toml file and put the following in it:

[GPU]
directMemoryAccess = true

If you have a game running, and update your settings from the GUI by opening settings and clicking save for example, these game-specific changes won't override your main config, however you can't reload them either by doing that.

[Hermiten]

Fix #564

[GHU7924]

This is the first time I've seen this PR and I don't understand everything yet, so I haven't been able to test it.

There was a note about issue 564, which I looked at and I'm not sure we need that many points. I also don't like that every time I launch I have to choose how to launch the game instead of just launching it with the pre-configured configuration.

I didn't see the configs folder, apparently it also needs to be created manually... which is wrong, in my opinion, because it should already exist. Also, as a regular user, I am put off by the lack of a minimal GUI.

I would like to see the menu item - Custom Configuration, which calls up a small window with settings, where you confirm that you want to use a custom profile, and then activate or deactivate the settings you need, like DMA.

I think it would be right if there already exists a custom_configs folder, which contains a config_default.toml file
It will already contain all the necessary options, but in a disabled state:

[GPU]
directMemoryAccess = false
(and everything else)

If you do NOT have a custom configuration set up, a simple config_default.toml will be launched.

If you create a profile to launch a game, for example config_CUSAXXXXX.toml, and you have a check mark Use custom config for CUSAXXXXX, then for this game config_CUSAXXXXX.toml will be launched, if the check mark is not set, then config_default.toml will be launched

[kalaposfos13]

I think it would be right if there already exists a custom_configs folder, which contains a config_default.toml file
It will already contain all the necessary options, but in a disabled state: ...

The issue with your suggestion that a custom config with all settings in it just disabled would face the issue of overriding the base config entirely, as the way it currently works is basically the same as variable shadowing, so if something exists in the custom config, then that value will be used, otherwise it'll be the value from the base config. This issue could be solved by adding all options in the file, but have all of them commented out, and then the user can uncomment whatever they need overridden, although that'd make it harder to write a GUI frontend for it

I didn't see the configs folder, apparently it also needs to be created manually... which is wrong, in my opinion, because it should already exist.

I believe that should be an easy thing to do

If you create a profile to launch a game, for example config_CUSAXXXXX.toml, and you have a check mark Use custom config for CUSAXXXXX, then for this game config_CUSAXXXXX.toml will be launched, if the check mark is not set, then config_default.toml will be launched

This is not the way the feature currently works (see above), and while this is mostly subjective, I prefer having only the changed config values in the custom configs, instead of full copies of the same file with one or two lines changed in some of them. Also, this PR is only for providing the base feature, and I don't plan to add a GUI to this myself

[GHU7924]

I may write something stupid below, but I will still express my thoughts, so please don't get angry and don't swear))

My idea was (if it is possible to do this) that the settings would be split into two parts, i.e. the emulator would read 2 different files to have a general picture so to speak.

The first part is config.toml (contains general settings - tabs and selections made on them),
the second part is Custom Config, which is responsible for all specific options and which in turn is also divided into two files between which the selection occurs:

1. config_default.toml (all specific settings set by default, there will be literally 5 lines or however many there are: DMA and so on)
2. config_CUSAXXXXX.toml (essentially a copy of the file above, but with modified selections for a specific game)

When the emulator is launched, the files config.toml + config_default.toml are read, but when a specific game is launched, a second check will occur; if the game uses a custom configuration, the selection will change to config.toml + config_CUSAXXXXX.toml

In the interface, it is the flag Use custom config for CUSAXXXXX that will decide which second part will be used, config_default.toml or config_CUSAXXXXX.toml

I remember that you are not so friendly with the graphical interface, but @rainmakerv3 can help here if he has time, provided that everything described above is possible.
I think this can also speed up testing, but then you need to add the ability to change config_default.toml

In Help there will be a description of the functions, for example:
DMA (directMemoryAccess) - This option does

P.S. These are just my thoughts and I am not saying that this is right or anything like that, this information is for you to think about (if it is not stupidity) and maybe it will prompt you to improve this PR in some way.

[GHU7924]

I tested the latest commit and everything seems to work fine, the only thing I didn't like was that I can't quickly create a custom configuration file.

If you don't want to make a GUI because you think it's unnecessary, then I can even understand that, but there should at least be an option for the average user to quickly create such a file via the right-click menu. I think that it is possible to even create a copy of file config.toml with the name as you have now by serial number (for example, CUSA03745). The copy weighs very little and not every game requires specific settings, so I think that we can afford it.

I also have an idea, which is that in config.toml we can separate all these settings into a separate section, let it be called Game specific configs, and it will contain the same parameters that can be changed.

[Game specific configs]
directMemoryAccess = false
fenceDetection = 0
readbackAccuracy = 1
readbackLinearImages = false
readbacks = true

Therefore, if there is no GUI, then we need comments directly in the file describing these options.

[squidbus]

I don't think it's a good approach to duplicate all the settings fields like this, it's more maintenance burden whenever something changes. Would be cleaner if instead you just had one set of config fields that used a wrapper type to be able to pull from the right config.

[kalaposfos13]

I updated the PR to main, fixed/changed the two things mentioned in the review comments, and rewrote the code to get rid of duplication.

[squidbus]

Why are only some of these using base_value? Maybe I'm missing something

[kalaposfos13]

It's a stupid thing but for integer types not having that there results in the below error, and I couldn't figure out what to do with it, so I just manually specified base_value to force it to build

/media/kalaposfos/Shared/shadps4/repos/shadps4-dev/src/common/config.cpp:959:37: error: use of overloaded operator '=' is ambiguous (with operand types 'value_type' (aka 'basic_value<toml::ordered_type_config>') and 'ConfigEntry<int>')
  959 |     data["General"]["volumeSlider"] = volumeSlider;
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
/media/kalaposfos/Shared/shadps4/repos/shadps4-dev/externals/toml11/include/toml11/value.hpp:403:18: note: candidate function
  403 |     basic_value& operator=(boolean_type x)
      |                  ^
/media/kalaposfos/Shared/shadps4/repos/shadps4-dev/externals/toml11/include/toml11/value.hpp:443:18: note: candidate function
  443 |     basic_value& operator=(integer_type x)
      |                  ^
/media/kalaposfos/Shared/shadps4/repos/shadps4-dev/externals/toml11/include/toml11/value.hpp:536:18: note: candidate function
  536 |     basic_value& operator=(floating_type x)
      |                  ^
1 error generated.

[squidbus]

It does seem a bit unintuitive to me for the default conversion operator to be the base value. For example if I write some code that accesses a ConfigEntry typed field it will compile without any indication you are ignoring the game-specific config value. It would make more sense to me if the default access would convert to the correct config value, and if you need specifically the base value or override value you would do that explicitly.

[kalaposfos13]

I chose to make accessing the base value as the default behaviour so that I only had to modify parts that needed the optional game specific value, and didn't have to rewrite the setters that should only set the base value, but if you think it's better to rewrite that and make accessing a config entry give the game specific value as well, I can do that

[squidbus]

I am thinking maybe we should be more explicit with handling the ConfigEntry values, so that it’s clear what a given piece of code is accessing or setting, whether its base value, game-specific value, or either

[kalaposfos13]

I am thinking maybe we should be more explicit with handling the ConfigEntry values, so that it’s clear what a given piece of code is accessing or setting, whether its base value, game-specific value, or either

I removed the automatic type conversion operator, and made everything explicit in my latest commit

[GHU7924]

Tested the latest commit, everything is fine.

As a regular user I would like to see improvements, not necessarily in this PR and maybe it will be done by someone else, but I will repeat myself a little:

1. Add a Create / Edit Custom Config menu item (for example) for quickly creating and editing a specific configuration file for the game.
   Note: that is, the emulator determines the presence or absence of such a file for the game, then creates and opens it if such a file is missing or simply opens it if the file already exists.

Next 2 options:

a) Opens a graphical window similar to what I showed above with help, which of course would be great for a regular user

b) Opens the configuration file itself as is (but then it is worth doing point 2 )

2. Group all specific settings in one place, for example, create a Game specific configs section for this

P.S. It is necessary to edit the first comment after making the last changes.