Thunderforge / scummvm-issues

ScummVM main repository
https://www.scummvm.org
GNU General Public License v3.0
0 stars 0 forks source link

BASE: The -g / --gfx-mode command-line option still handles the old scaler names #24

Open Thunderforge opened 2 years ago

Thunderforge commented 2 years ago

Some time ago, the new command-line options --scaler and --scale-factor were added. At that point, the -g / --gfx-mode option changed and the old scaler names (2x, 3x, etc.) were deprecated.

If I try to launch a game the old way, I'm told I'm using an invalid mode:

$ ./scummvm -g 2x monkey1
WARNING: SDL mixer output buffer size: 512 differs from desired: 1024!
WARNING: Unrecognized graphics mode '2x'. Switching to default mode!
User picked target 'monkey1' (engine ID 'scumm', game ID 'monkey')...
   Looking for a plugin supporting this target... SCUMM [all games]

However, the scaler name still works. And the new scaler is written to the settings file for the game, overriding the default scaler. Even though command-line options usually are not written to the configuration. I think what happens it this:

The scummvm_main() function calls parseCommandLine(). This function will return all the command-line options through one of its parameters, called "settings".

After a bunch of sanity checking, it calls processSettings(), which copies all the command-line options into ConfMan's transient domain.

After that, it checks if gfx-mode is recognize, and if it isn't changes settingsgfx-mode to "default". It should probably use ConfMan.set("gfx-mode", "default", Common::ConfigManager::kTransientDomain) instead.

Worse, though, it has already gone through Scalermanager::updateOldSettings() where it converted the old gfx-mode setting to the new scaler/scale_factor ones. That's probably what gets written to the config file.

So I'm not at all sure how to handle this.

Thunderforge commented 2 years ago

This would be nice to fix before the release.

Thunderforge commented 2 years ago

Not doing anything for it :/