Spring Settings and the simple options

[Master-Athmos]

In my opinion we should rethink / re-evaluate the "simple options" in Springsettings. In its current state it in my opinion is contraproductive. My main complaints are that it seems to have minor outdated settings, gives a wrong idea, even uses some bad settings and is too general...

Outdated settings:
I didn't try all the settings possible yet but I think it doesn't know that there's a bump mapped water type and just applies the former types...

Wrong idea:
With just settings for quality and detail people will think that it's just like in any other game where it's about reduced effects on the one hand and reduced polycounts or texturesizes on the other hand...

Bad settings:
It seems like the highest settings just make all the sliders go to the very right (except for AA which stays at 1). Apart from that being crippling settings it's highly contraproductive to have the icon distance set to a max value which pretty much eradicates any radar feature of the game played...

It also might get critical if you have a graphics card that currently doesn't work with e.g. a specific water type. The user will just get crashes and doesn't know why (don't expect someone who sticks to such a simple way of doing his settings to look up his infolog or things like that)...

Too general:
In my opinion those two settings simply are far too general and as said misleading in their meaning (and very vague too). So if such a simplified setting should stay there imo have to be more sliders / options. Why not doing a slider for AA, a slider for shadow quality, a slider for particle details just as sliders for water and for terrain detail and abandon the current two settings. That's not too many things to set and it's way more obvious what things will do...

A box to give one's GPU vendor might be an option too so when there's a new Spring version with a known incompatibility things can be adapted immediately without frustrating the user...

[koshi]

Simple mode is for people who do know jack of what you're suggesting to add to it.

As for diff settings per step, if anyone finds a more reasonable set of presets, make a patch against http://github.com/springlobby/springlob ... /presets.h

A box to give one's GPU vendor might be an option too so when there's a new Spring version with a known incompatibility things can be adapted immediately without frustrating the user...

That will simply not happen unless someone that is not me takes it up to a) implement what's necessary in SS and b) keep some kind of list current with every release, commit or whatever

In general, patches are more than welcome, I have enough stuff to do as is.
See also http://springlobby.info/projects/spring ... uery_id=10

[Master-Athmos]

Simple mode is for people who do no jack of what you're suggesting to add to it.

The settings might cause crashes though and make Spring run unnecessarily slow. When marking things like shadows & AA as very performance consuming people could get way more performance or visual quality...

I mean you have just three options for graphics detail where "high" pretty much is unusable and should be called "ultra" or something. When switching to medium again though you get more moderate settings (while particles imo still are too high) but ground decals are turned off. So you just have two settings left which are "playable". The medium one give you a so so setting which frankly leaves out the quite appealing and not very performance demanding ground decals (which in the end nobody with simple settings and a demand for average fps will ever see) and a low option which really has abysmally low settings...

While there definitely has to be something done on the predefined settings (and maybe some more steps get added) the system imo should be revamped to a system with like 5 or 6 options which clearly say what they do just as what will actually eat your performance...

Oh and with sliders I of course didn't mean one like for the particle numbers. I just meant an option with like three options or maybe up to five if appropiate. The perfect way than of course would be to do a color code of a performance eating tendency of the option. If that's too "difficult" to do I guess an option to choose like it's done right now (-> no slider but a textbox) with different colored text backgrounds should be pretty easy to do...

EDIT:

That will simply not happen unless someone that is not me takes it up to a) implement what's necessary in SS and b) keep some kind of list current with every release, commit or whatever

Doesn't get Spring Settings get recompiled every release? If during beta testing a dev notices that a certain feature is broken it should be a piece of cake to go into the preset options and change a value there...

[koshi]

Preset system is already flexible enough to support any number of presets per category and adding new categories.

Doesn't get Spring Settings get recompiled every release? If during beta testing a dev notices that a certain feature is broken it should be a piece of cake to go into the preset options and change a value there...

SS gets recompiled with every SL release even, that is not the point. Thing is someone has to do it, most likely inquiring with testers and devs. Then there's the matter of backwards compatiblity, meaning anything added there needs to be mapped to a fixed engine rev and re-checked on every release.

The bottom line is, most of your ideas are programatically easy to implement, but either tedious to maintain or simply not important to me enough to spend time on them. Devising new presets and stuff however is easy, even for non prgrammers.

[Master-Athmos]

So could I go here and add not just new options (by of course adapting the presets defined afterwards) but also add a category for a new "box" one could choose an option from?

Code: Select all

const int levels_low_To_High_size = 3;
const int levels_vlow_To_vHigh_size =5;
const wxString levels_low_To_High[levels_low_To_High_size] = { _("low"),_("medium"),_("high")};
const wxString levels_vlow_To_vHigh[levels_vlow_To_vHigh_size] = { _("very low"),_("low"),_("medium"),_("high"),_("very high")};

Or in other words if I write something like this with the respective presets (i.e. values / variables) would that add a box automatically?

Code: Select all

const int prVal_RenderDetail_size = 9;
const presetValues<int, 3> prVal_RenderDetail[prVal_RenderDetail_size] = {pr_ShadowMapSize, pr_TreeRadius, pr_GroundDetail,
pr_UnitLodDist, pr_GrassDetail, pr_GroundDecals,
pr_UnitIconDist, pr_MaxParticles,pr_MaxNanoParticles};

I might redo that if it's that easy...

Thing is someone has to do it, most likely inquiring with testers and devs. Then there's the matter of backwards compatiblity, meaning anything added there needs to be mapped to a fixed engine rev and re-checked on every release.

Well my opinion simply is that it really is piece of cake to change i.e. adapt the settings when a certain feature is known to be broken. I mean it's not like certain particle numbers are broken or things like that - it's just some features (like a water type) that's easy to track...

[koshi]

Or in other words if I write something like this with the respective presets (i.e. values / variables) would that add a box automatically?

automatically, no -- easily, yes

I mean it's not like certain particle numbers are broken or things like that - it's just some features (like a water type) that's easy to track...

Bumpwater for example was a bitch to track tbh and I simply do not have the motivation to grep for new uses of the Settingshandler before each release, ask around what ranges there and so forth. (the grepping could be ofc automated, possibly even with automatic diff to prev git tag)