GameScope: Support new filtering and scaling parameters

[sonic2kk]

Once complete, this should implement the remainder of #838.

Overview

GameScope is changing how filters and scale modes are passed. These are now passed with a -F and -S option respectively, instead of as individual flags such as -i, -n, -U, or -Y for integer scaling, nearest neighbor, FSR, or NIS respectively. Instead, -nearest, FSR (-U) and NIS (-Y) are passed as flags to the -Filter flag. -integer scaling is passed to the -S flag now. This also means it is no longer possible to use all of these flags at once, so there is no way to pass FSR and NIS.

This PR changes the way we handle passing GameScope filter/scale arguments in preparation for this change. Previously we had checkboxes for each of these options, and these checkboxes controlled which flags were passed. So if the FSR and NIS checkboxes were enabled, we just passed the -U and -Y flags. This will no longer work.

Instead, this PR introduces two new fields to replace the existing filtering checkboxes: Filter and Scale Mode. These two are combobox entry fields with a set of dropdown presets (fsr, nis, integer, etc - the options match the GameScope source), where the default value is none. When none (or empty), the -F or -S flag is not passed at all. But when set to anything that isn't blank or none, we pass -F <value_in_combobox> (or -S for scale). This means to enable FSR, a user will now select fsr from the dropdown.

At the time of writing, this PR works for the latest git release of GameScope. The way the flags are passed match the documentation exactly. The flags are passed correctly and only when not blank or none, and as well as this, the --fsr-sharpness flag is only passed if FSR or NIS is set for the -Filter. This matches the expected behaviour. However, this PR is entirely incompatible with existing GameScope stable versions. So this is only useful currently to users running GameScope git. But before this is merged, support for existing stable versions will be implemented, as discussed below.

Backwards Compatibility

Even though this PR works when running GameScope from the latest bleeding-edge commit, there is a large piece of outstanding work on backwards compatibility.

At time of writing, this feature is only available in GameScope git, with 95% of this change being a part of this GameScope commit: ValveSoftware/gamescope@7a1fe2d - Since this work is only in GameScope-git, existing GameScope versions will not support the new flags. We need to update the logic of how we pass flags to allow for passing -F/-S if these flags are available in the version of GameScope that is currently in use, and otherwise it should fall back to using the old-style flags like -U. So when fsr is selected in the filtering dropdown, this means we should pass the -U flag if a user cannot pass -F fsr (i.e. if that isn't part of the GameScope help screen).

We also need to be able to fetch flags set this way and define them in the new UI. For example if a user has some GameScope arguments with -w 1280 -h 720 -U, the new UI needs to be able to see the -U flag and know that this means we should set the dropdown to have the fsr option.

Since the UI is changing, even though users of older GameScope versions could still theoretically pass -U, -Y and -n in one command, the UI will no longer allow for this. In the next release of GameScope, users will have to deal with this anyway, so it isn't really a big issue. It's just that when using STL they'll have to confront it a bit sooner :-)

In short, we have to account for the new syntax, and we have to find a way to map the existing -U, -Y options to the dropdown menu on the UI.

Considerations

The wiki will need to be updated following this change, probably quite extensively updated. The GameScope wiki here is also used as a reference on the Arch wiki, so extra care should also be taken when updating it.

The change to the UI is a breaking change since some parts of the UI have been removed, so the order of the GSARR has changed. For this reason, users will need to reset their existing GameScope arguments entirely. #844 is in place to help with this, but we also need to communicate this in the changelog. Whether or not users will read this is another story but hey, we need to try :-)

Eventually, the backwards compatibility logic will be irrelevant and will need removed. On a similar note, this change should probably stay on a branch until GameScope has progressed a little bit further, just in case this functionality is changed or removed entirely.

Design Notes

A combobox entry field was chosen so that if more options are added, a user can just enter these options instead of STL needing to update to add these options. A user could just manually edit the GameScope arguments line in the game config, but this adds additional flexibility and doesn't risk potentially breaking the UI (unlikely but better safe than sorry).

These parameters are case-sensitive. This was decided in case any case-senstiive options are passed in the future, or if the casing of existing parameters change. This is extremely unlikely (in my humble opinion) but I still wanted to try and account for it.

TODO

Progress tracker:

• Add "backwards compatibility" with existing/legacy GameScope flags
• Test that backwards compatibility does not break new options
• Update langfiles
• Update wiki

[sonic2kk]

4e7dd71 has added backwards compatibility. Now enabling the options on the new GameScope UI from this PR (such as FSR from the dropdown) will pass -U, if the -F option is not available.

This needs some more testing but in quick tests before pushing, this works. Once this functionality is confirmed working, the bulk of the work for this PR should be done!

[sonic2kk]

There were a couple of issues. Since 0 was set as the default value for the legacy switches if they weren't set (this was previously used to set the checkboxes to False), -n never failed because there were always values, as if a value was always found for the switches. That has been fixed, now legacy GameScope options seem to work as expected!

I'll need to update GameScope to latest git to then check if the new logic works, too. But I suspect it will :-)

[sonic2kk]

Langfiles have been updateed.

[sonic2kk]

In testing with the new GameScope UI, the -F/-S options are passed, but they are not detected correctly from GAMESCOPE_ARGS and so the dropdowns are blank on the GameScope menu. Strange!

[sonic2kk]

The blank values were because of a stupid mistake on my end with setting GSFLTR and GSSCALE to $NON

[sonic2kk]

Okay, after testing, the code seems good. Everything seems to work with the old and new GameScope options, so the mapping is working correctly. I also checked out of interest and -f (fullscreen) and -F (filter) don't seem to conflict in any way, which is great!

As of 84b0095, this PR should be ready to merge. But I will leave it for a bit for two reasons:

• The wiki needs updated, I want to have the edits ready before merging (updated screenshots and documentation)
• We need to be sure there won't be any short-term adjustments to the GameScope functionality upstream

[sonic2kk]

This is probably good soon. Just need to do some very final extra sure checks and then get around to updating the wiki (the main effort)

Note to self: Should be for a separate PR but it might also be worth rechecking some of the HDR and VR-related flags for any potential upstream behaviour/default value changes. I have a feeling I saw before that one of the VR flags changed and that one of the default HDR-related values changed.

[sonic2kk]

The wiki has been updated (https://github.com/sonic2kk/steamtinkerlaunch/wiki/GameScope), this will be good to merge pending a couple of minor tweaks and additional review.

[sonic2kk]

Version bumped, ShellCheck is good, tested with Cookie Clicker and it worked as expected. This is good to merge.