I created drafts for new in-game menus containing options and controls that have been available so far through our config file only. I didn't add all values since I didn't want to clutter the interface and I already barely found enough space to fit-in what I propose.
I don't know how hard or easy it is to actually program all this as something you could adjust in-game. I tried to keep things as simple and basic as possible. If a slide control is hard to code just using numbers would still be more user friendly than the need to alter it in the configuration file.
The range of some options has been between 0 and 1 in the config file. I suspect for most users 0 to 10 would be more intuitive and it shouldn't be hard to convert this number for the actual calculations.
I also merged options like "enablecodriversigns" and "codriversigns". By adding the option "off" this could be easily done. (I didn't include a "weather" toggle because I figured if "snowflakes" is set to "off" we could assume that the person also doesn't want to display rain.)
And I actually don't get what the "next" option under the key controls is supposed to do. Therefore, I left it out.
Of course we could add all config options if we would use more than just one screen for the options. But then we would need to re-organise it to make it less confusing. I think the options I left out aren't as important to have in-game.
Should all options stay in the configuration file or should we remove the in-game-adjustable options in order to avoid confusion what might take precedence? And do you think we should even make such specialised things like codriver sign scaling and positioning or application widow configuration into the options? I feel hardly anyone would want to run the game in windowed mode these days. But I may be wrong.
If you think it would be easy to do create drop down fields we could save some horizontal space by not having to print out all options after another in a single line. I didn't propose them because I wanted to keep it simple. Just let me know what you think would be best!
I altered the last options draft to use the same way of offering options on all values.
I committed a first version of the options menu to SVN yesterday. I basically followed your second screenshot of the options menu, because it is easier to implement. I did not add the option to change the player name, because I have to develop a text input box for that which is quite an effort. Drop down fields would be very difficult to realize, because they would hide other items below them, so I would keep them a low priority for now. I like the idea with the sliders though.
I think I will continue to work on the remaining features in the following order.
1. Controls menu
2. Options menu text edit
3. Options menu sliders
In the current implementation I did not add the "max" option for texture quality, because as the "config" file suggests the option does not work on both my GPUs. I had to re-structure some of the code for the options menu, so if you find some odd behavior in completely unrelated parts of the game, it might be due to that. Please let me know, I will look into it. Nevertheless, in my next commit I will first improve the documentation of the code before adding new features.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fantastic. I cherish how quickly you perfectly implemented the new options screen. Everything seems to work flawlessly. I just discovered that the image quality option doesn't change the performance (frame rate) even on my rather weak system at all. I wonder if this option does still make sense nowadays. Can we expect people using systems where lowering the value would actually make a real difference? Maybe we should just hard code this value instead of having an option to configure at all.
And in general I would love to have reasonable keyboard commands on all menu screens instead of sometimes having to rely on the mouse. Paging and escaping the screens seems to work like expected everywhere already. It would be more consistent if up and down for navigating options and return for selecting items would work everywhere. (Only in the options screen left and right would be more sensible to navigate values since they are available in a horizontal line.)
Is that a request you can fulfil easily during working on the menus?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also cannot see any difference for the setting texture quality even though it t is definitely forwarded to the OpenGL texturing functions. You are correct, even on my Intel GPU the game runs at its maximum frame rate. Do you know any map that has higher demands? Maybe it can be used to check, whether the option has an effect.
I implemented a first version of the control settings menu and committed it to SVN. Feedback is always welcome.
I have also noticed, that navigating the menu is inconsistent. I will add the possibility to navigate the menu via left and right arrow, enter and escape keys before looking into the next feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Not really. But it is always possible to increase the amount of vegetation in the map files easily by removing zeros from the "density" values in the "foliageband" tags. (What is the highest possible frame rate?) I never get more than about 25 frames. If it drops much lower I normally reduce the amount of vegetation.
An other option would be to double the "tilesize" value in the "terrain" tag.
I discovered that you can't fill in any new key in the menu if you once tried using a key that isn't recognised because then the field is empty and you can't make it active any more afterwards since without text in the field there is no active area to click at. (I only could overcome the problem by actually editing the configuration file.)
I will add the possibility to navigate the menu via left and right arrow, enter and escape keys before looking into the next feature.
Thank you, that is fantastic.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I constantly get 60 FPS. I guess this is the maximum due to the limitation of the vertical sync of the display.
Great testing from your side. I observed the same issue with non-displayable keys after checking your hint. I committed a change to SVN to fix this issue. I mainly had the problem with Umlaute and the French accents.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I created drafts for new in-game menus containing options and controls that have been available so far through our config file only. I didn't add all values since I didn't want to clutter the interface and I already barely found enough space to fit-in what I propose.
I don't know how hard or easy it is to actually program all this as something you could adjust in-game. I tried to keep things as simple and basic as possible. If a slide control is hard to code just using numbers would still be more user friendly than the need to alter it in the configuration file.
The range of some options has been between 0 and 1 in the config file. I suspect for most users 0 to 10 would be more intuitive and it shouldn't be hard to convert this number for the actual calculations.
I also merged options like "enablecodriversigns" and "codriversigns". By adding the option "off" this could be easily done. (I didn't include a "weather" toggle because I figured if "snowflakes" is set to "off" we could assume that the person also doesn't want to display rain.)
And I actually don't get what the "next" option under the key controls is supposed to do. Therefore, I left it out.
Of course we could add all config options if we would use more than just one screen for the options. But then we would need to re-organise it to make it less confusing. I think the options I left out aren't as important to have in-game.
Should all options stay in the configuration file or should we remove the in-game-adjustable options in order to avoid confusion what might take precedence? And do you think we should even make such specialised things like codriver sign scaling and positioning or application widow configuration into the options? I feel hardly anyone would want to run the game in windowed mode these days. But I may be wrong.
Last edit: Onsemeliot 2021-01-01
If you think it would be easy to do create drop down fields we could save some horizontal space by not having to print out all options after another in a single line. I didn't propose them because I wanted to keep it simple. Just let me know what you think would be best!
I altered the last options draft to use the same way of offering options on all values.
Last edit: Onsemeliot 2021-01-02
I committed a first version of the options menu to SVN yesterday. I basically followed your second screenshot of the options menu, because it is easier to implement. I did not add the option to change the player name, because I have to develop a text input box for that which is quite an effort. Drop down fields would be very difficult to realize, because they would hide other items below them, so I would keep them a low priority for now. I like the idea with the sliders though.
I think I will continue to work on the remaining features in the following order.
1. Controls menu
2. Options menu text edit
3. Options menu sliders
In the current implementation I did not add the "max" option for texture quality, because as the "config" file suggests the option does not work on both my GPUs. I had to re-structure some of the code for the options menu, so if you find some odd behavior in completely unrelated parts of the game, it might be due to that. Please let me know, I will look into it. Nevertheless, in my next commit I will first improve the documentation of the code before adding new features.
Fantastic. I cherish how quickly you perfectly implemented the new options screen. Everything seems to work flawlessly. I just discovered that the image quality option doesn't change the performance (frame rate) even on my rather weak system at all. I wonder if this option does still make sense nowadays. Can we expect people using systems where lowering the value would actually make a real difference? Maybe we should just hard code this value instead of having an option to configure at all.
And in general I would love to have reasonable keyboard commands on all menu screens instead of sometimes having to rely on the mouse. Paging and escaping the screens seems to work like expected everywhere already. It would be more consistent if up and down for navigating options and return for selecting items would work everywhere. (Only in the options screen left and right would be more sensible to navigate values since they are available in a horizontal line.)
Is that a request you can fulfil easily during working on the menus?
I also cannot see any difference for the setting texture quality even though it t is definitely forwarded to the OpenGL texturing functions. You are correct, even on my Intel GPU the game runs at its maximum frame rate. Do you know any map that has higher demands? Maybe it can be used to check, whether the option has an effect.
I implemented a first version of the control settings menu and committed it to SVN. Feedback is always welcome.
I have also noticed, that navigating the menu is inconsistent. I will add the possibility to navigate the menu via left and right arrow, enter and escape keys before looking into the next feature.
Not really. But it is always possible to increase the amount of vegetation in the map files easily by removing zeros from the "density" values in the "foliageband" tags. (What is the highest possible frame rate?) I never get more than about 25 frames. If it drops much lower I normally reduce the amount of vegetation.
An other option would be to double the "tilesize" value in the "terrain" tag.
I discovered that you can't fill in any new key in the menu if you once tried using a key that isn't recognised because then the field is empty and you can't make it active any more afterwards since without text in the field there is no active area to click at. (I only could overcome the problem by actually editing the configuration file.)
Thank you, that is fantastic.
I constantly get 60 FPS. I guess this is the maximum due to the limitation of the vertical sync of the display.
Great testing from your side. I observed the same issue with non-displayable keys after checking your hint. I committed a change to SVN to fix this issue. I mainly had the problem with Umlaute and the French accents.
Perfect. I can't reproduce the problem any longer. :)