Graphics settings

[scrawl]

This is exactly what a singleton (or, alternatively, a static interface, if we want to avoid singletons) is useful for. It's a pain to pass the individual settings to every instance that needs to access it.

[scrawl]

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.

For what we have now, the editor can use the same settings.

[Zini]

This is exactly what a singleton (or, alternatively, a static interface, if we want to avoid singletons) is useful for. It's a pain to pass the individual settings to every instance that needs to access it.

I was once in this camp too, but finally got convinced that singletons are nearly always more trouble than they are worth and that passing things along is the better option most of the time, even if it is a bit of a pain. Wouldn't call a singleton an anti-pattern, but it is uncomfortable close to it.

For what we have now, the editor can use the same settings.

That remains to be seen.

Anyway, the topic is not important enough to put the task on hold until we have discussed it out. We can also adjusted it later, if needed. So, go ahead.

I guess your game setting manager should be a new component, since components are not allowed to depend on anything in the apps directory

[scrawl]

Settings backend is done and as you can see, it's pretty lightweight.

Should I create the settings and load user/default files in Engine, or in main?

[Zini]

Engine.

[scrawl]

The default settings are now loaded from a file settings-default.cfg. If user settings don't exist, they are copied from default settings, otherwise they are loaded and can override the defaults.

I've already added 3 settings that are in use (enable shaders, number of lights, terrain number of lights)