Custom configuration for each game

[Goodfeat]

Now you can make a separate configuration (independent file) for each game. All emulator settings are available except for control. The configuration file can be changed and deleted from a separate menu. The user configuration menu is available through the context menu

Pull request is in beta. may require revision

[github-actions]

Download the artifacts for this pull request:

• ryujinx-Release-1.2.0+fc39650-linux_arm64
• ryujinx-Release-1.2.0+fc39650-linux_arm64-AppImage
• ryujinx-Release-1.2.0+fc39650-linux_x64
• ryujinx-Release-1.2.0+fc39650-linux_x64-AppImage
• ryujinx-Release-1.2.0+fc39650-macos_universal
• ryujinx-Release-1.2.0+fc39650-win_x64

Only for Developers

• ryujinx-Debug-1.2.0+fc39650-linux_arm64
• ryujinx-Debug-1.2.0+fc39650-linux_arm64-AppImage
• ryujinx-Debug-1.2.0+fc39650-macos_universal
• ryujinx-Debug-1.2.0+fc39650-linux_x64
• ryujinx-Debug-1.2.0+fc39650-linux_x64-AppImage
• ryujinx-Debug-1.2.0+fc39650-win_x64

[Goodfeat]

Gamepad settings added for user config

[LotP1]

could the game title be added to the settings window title if it's a game specific configuration?
e.g. Ryujinx 1.2.x - Settings - The Legend of Zelda: Tears of the Kingdom

[Goodfeat]

could the game title be added to the settings window title if it's a game specific configuration?

Yes, no problem.

[LotP1]

just for your information the bot message with builds auto-updates with new builds after all checks have completed :-)
you do not need to provide your own builds.

[Goodfeat]

just for your information the bot message with builds auto-updates with new builds after all checks have completed :-)
you do not need to provide your own builds.

I didn't know, thanks for the information.

Changes implemented

[AkazaRenn]

Correct if I'm wrong, are we always saving the whole config for per game - meaning changing one entry into per game would result in all the other entries unable to update following the global changes?

[Goodfeat]

Yes, that's exactly how it works, absolutely the entire configuration is saved, even if one value was changed. This is how it works in the original, this is how it works for a separate configuration. If you need it to work differently, you need to rewrite the save system and do additional checks for the original ryuujinx.
To simplify, the global configuration is also saved in a custom setting, but it will never be used, because some of the settings will not be rewritten upon loading. which settings exactly will not be rewritten are set in the ConfigurationState.Migration.cs configuration file

If you need the settings to be taken from the global configuration, just delete the custom configuration file and create it again

[AkazaRenn]

Thanks for the reply! It feels a bit costly to use the per game settings in that way. Indeed to avoid that the saving mechanism may need to be rewritten, so I'm just sharing my thoughts here.

If we want to implement that, on saving we can compare the game settings with the global one and skip all identical entries, so only the difference is saved. On loading we always load the global config first then update fields with entries existing in the game config.

[Goodfeat]

Yes, I was adjusting the code in the process and at one point I made it so that the setting would only load once, but then I came to the conclusion that it is better to reload the settings twice so that the global configuration would also load. This solved the problem with updating the settings.
I do not argue, the current implementation is resource-intensive, but this only happens when loading the user configuration, and only at the moment of initializing the settings or saving them. In addition, not all games need user configurations.

But this solves the main problem, you do not need to go into the configuration file every time if one or two games ask for special settings for it to work

[AkazaRenn]

Yeah I agree, overall it would work well and I quite like this change. The improvement can be saved for the future once we get a chance for it 😊

[ChthonVII]

Thanks for the reply! It feels a bit costly to use the per game settings in that way. Indeed to avoid that the saving mechanism may need to be rewritten, so I'm just sharing my thoughts here.

If we want to implement that, on saving we can compare the game settings with the global one and skip all identical entries, so only the difference is saved. On loading we always load the global config first then update fields with entries existing in the game config.

This doesn't work because the user might affirmatively want a per-game setting that's presently the same as a global setting, but may want to change the global setting in the future without changing the per-game setting.

There is no unambiguous way to imply when you want the per-game setting to follow the system setting. It needs to be explicit. So, to make this sort of thing work, we'd need one of the choices for each per-game setting to be something like "follow global setting." Explicitly save "follow global setting" to the per-game config file. Then, when loading, load the global config first, then load the per-game config, skipping items in the per-game config that say "follow global setting" while clobbering everything else.

[Goodfeat]

This is a feature of the function, when creating a custom setting, you create your custom configuration based on the current global configuration and untie from the global except for a few settings. At the moment, this is how it works.

Other implementations require rewriting the save system and rewriting the entire settings menu. This may break compatibility with the current implementation.

Do you have special scenarios in which some setting of the global configuration needs to be applied to user configurations?

user settings are needed mostly for problematic games, other games if they launch and play well, there is no point in configuring them individually

[ChthonVII]

I would favor merging this commit with the current implementation -- the per-game config is a complete config, with no falling back to the global config. Occasionally having to manually change multiple per-game configs is a hassle, but not a huge one.

I was just pointing out that the floated idea for how to potentially implement falling back to the global config by omitting unchanged elements from the per-game config wouldn't work. When the user leaves a value unchanged, it's ambiguous whether the user means "follow the global config" or "I affirmatively want the same value that the global config has right now." If you want to go down the path of having a way to fall back to the global config, then "follow the global config for this setting" needs to be explicitly saved to the per-game config. But you don't seem inclined to go down that path right now, and I don't think you need to.

[Goodfeat]

I understand you. I am very sorry that this innovation does not work as you want at the moment. But the original implementation requires radical changes in order to do exactly as you want.

Here you have correctly noted that this innovation has a fundamentally different approach (it was chosen for a reason). First of all, to maintain compatibility with the old implementation of saving and loading the configuration. You can safely run another version of the emulator without this function and the emulator will load without errors

The original code was simply not designed for user configurations.

[bozis92]

i tested in a few games and works perfects!
any idea when this will be on canary version?