Graphics settings

[scrawl]

With all the new graphics features that have been implemented in the past, and also new stuff on the horizon, it is time to introduce graphics settings.

From what I've seen our configuration manager is very limited and doesn't seem appropriate for this. I would suggest to use Ogre::ConfigFile for that matter, you can basically load it in 1 line and then check the value of a setting in 1 line.

Also, I would like to make the interface for this config file static, because it has to be accessed from NIFLoader and other places.

Do you agree with this?

[Zini]

Nope. I definitely want to keep the current configuration system. Its way too convenient to give up on it.

We need to distinguish between two things here:

a) configuration settings
b) game options

a) These are determined at startup and can't be changed later. The less technical settings of this category are set in the launcher

b) These can be adjusted at any time from an in-game menu. We don't have anything of this kind yet (including the in-game menu to manipulate them or a file format to store them). At least a few of the current configuration settings probably should be moved over to the game options eventually.

I would expect that most of the graphics settings are actually of type b. We are only implementing them as type a right now, because type b isn't available yet.

[scrawl]

In that case I'd prefer if someone else took that task.

And it would be good if we have this sorted out until 0.14, since some people are having problems with shaders that can be solved by introducing settings for them.

[Zini]

Stuff it into the configuration settings for now. We can move it over later.

I assume we are only talking about a small number of settings here. If there are a lot, we could implement the game options without an GUI for now. I don't have a strong opinion on what kind of backend we should use, but boost program_options are obviously not suitable.

[scrawl]

Yeah, the thing is that it's going to be a lot of options.

That's why I wanted to avoid using the configuration manager. I find it inconvenient to add a member and other stuff for every new setting. I would love a configuration interface where I could just getString("setting1") or getFloat("setting2")

I don't have a strong opinion on what kind of backend we should use, but boost program_options are obviously not suitable.

A backend based on Ogre::ConfigFile can be made in a couple of lines. We also need a seperate "default config file" that gets read when there's no user config yet (or the launcher just copies the default cfg to user dir)

[psi29a]

It would be nice to eventually do a sort of 'auto tune' where a few benchmarks are run on particular things and it scales and sets graphical options to a good balance of fps and eye-candy.

I know i'm already hitting 20fps~ exterior on both my nvidia 8400 and radeon hd 3640.

[Zini]

Better let OpenMW do the copying on startup (should look first in global and then in local location for the default file).

That's why I wanted to avoid using the configuration manager. I find it inconvenient to add a member and other stuff for every new setting. I would love a configuration interface where I could just getString("setting1") or getFloat("setting2")

Can we stick to the terminology given above? Calling the game options configuration will only cause confusion.

[Zini]

It would be nice to eventually do a sort of 'auto tune' where a few benchmarks are run on particular things and it scales and sets graphical options to a good balance of fps and eye-candy.

I know i'm already hitting 20fps~ exterior on both my nvidia 8400 and radeon hd 3640.

That's better done with performance profiles (probably not only affecting graphics). The game option UI could offer several defaults and we could add some algorithms for guessing the most suitable profiles, which the UI would then propose to the player.

[scrawl]

Okay. So this is what the GameOptionsManager should do, IMO

• getSingleton()
  load(string file)
  save(string file)
  getInt(string option)
  getFloat(string option)
  getBool(string option)
  getString(string option)

[Zini]

Ideally we should also consider the performance profile idea mentioned above. But we could also address that later.

Not too keen on using singletons. We have so far successfully avoided them (except when interacting with OGRE). Sounds unclean (and inconsistent). Any chance we can make it a regular class, add it to MWWorld::Environment and just pass along the relevant settings when calling functions in the components? (like the NIF loader)

It should be considered that many of the components will also be used by the editor, which might utilise a completely different method of graphics configuration.