[cjakeman]

Csantucci, on 15 July 2021 - 12:28 PM, said:

So for me this option box may disappear and the option can be always set to true, but maybe some insider knows better about the usefulness of the option.

Thanks for this, Carlo. Perhaps I will set the option to true and remove it (just from the Unstable version) and see if that causes any problems to anyone.

roeter, on 16 July 2021 - 01:12 AM, said:

So, in my view, if we are looking at improving the menu structure, than it is about time that these options were moved to where they belong - which is the activity definition.

I agree with you about this (and with Peter's argument too). I'll take it up with James as I remember he had reservations.

roeter, on 16 July 2021 - 01:55 AM, said:

So far, this thread has only been about specific variables and their merit (or otherwise) to the simulation and/or to the users.
However, I feel that the structure of the menu is just as important an issue. A proper menu structure will help to understand the scope of options, and will also help to understand the relation between these options.. . .
So I would like to suggest the following options tabs:

You are ahead of me, Rob. I want to drop the Experimental tab too, and also the Updater tab could be replaced by a drop-down selection. I have some ideas about the categories too, so perhaps we can visit this again once we've explored all the individual controls.

roeter, on 16 July 2021 - 01:55 AM, said:

So, there no longer is an 'experimental' tab. If it is deemed essential to identify an option as experimental, this can be done by placing a red box around this option, with the text 'experimental' displayed in the boundary of that box. But by placing that option on the proper tab it is immediately clear what the context of that option is. Also, promoting an option from experimental to standard is made much more easy - just remove the red box. Presently, such a promotion requires rewriting half the menu.

Very nice. That arrangement would save us all time and trouble.


Moving on then to the next control:




The Manual has "When the option is checked, in cases where multiple instances of the same object have to be drawn, only a single draw call is sent to the GPU. This means lower CPU load. It is suggested to always check this option."

Does anyone know whether this control is still needed? Could it be like the Fast Alt Tab - always active and removed from these options?

[Weter]

What for Fast full-screen Alt-Tab...Well, if so, this can be merged to set of parameters, being switched for low-grade machines increased performance, or sub-tab for that, if such parameters have sense to be applied separately.

[YoRyan]

cjakeman, on 16 July 2021 - 11:08 AM, said:

The Manual has "When the option is checked, in cases where multiple instances of the same object have to be drawn, only a single draw call is sent to the GPU. This means lower CPU load. It is suggested to always check this option."

Does anyone know whether this control is still needed? Could it be like the Fast Alt Tab - always active and removed from these options?

Enabling this option has been known to introduce graphical glitches, so some people prefer to turn it (or keep it) off. Unfortunately, such glitches vary by content, by hardware configuration, and even by driver version.

[Weter]

About instancing
I asked about how it works last autumn and Derek explained to me.
That time I ran 2009-dated laptop and this option, being turned on slowed-down performance even more.
As I understand, that makes less work for GPU, but demands more CPU resources for computing, so Derek adviced, that as long as I have only 2GbRAM, that would be useless for me to turn it on.

[EricF]

If some options are re-worked into sliders, it may make them more intuitive in terms of increasing/decreasing and effect or value, which is good. But make sure there's some sort of clear description and scale on the control so that it's understandable.


Don't do this (Example from Euro Truck Simulator 2):
https://i.imgur.com/K3s3SQHh.png


The sliders to adjust force-feedback settings on a steering wheel are all very functional, but poorly described and there's no scale on the sliders. Just more/less depending on position. But yet their positions correspond to defined numeric values in the configuration file for the game. It's very difficult to change settings and then return them to prior values with nothing but vague visual reference.

A numeric reference display that changes with slider position would allow the user to know (and record or share) the set value. Even a set of tickmarks along the slider would help.

[Laci1959]

jonas, on 15 July 2021 - 03:57 PM, said:

Sorry Chris, for jumping a little back again in this thread. I hope it will not disturb the systematic discussion of the individual options that is going on here right now.

It's about the option "Forced red at station stops".[size="2"]

The player train now has to wait in front of its red signal after completed the passenger change, because the freight train had already occupy the track ahead the player train and simply overtakes the player train. The player train now has to wait until the freight train has reached the next station (the next signal).

Hello
Keep in mind the fact that MSTS has always given priority to the player. It was bad sometimes, in this case good.
Regards Laci1959

[cjakeman]

YoRyan, on 16 July 2021 - 11:36 AM, said:

Enabling this option has been known to introduce graphical glitches, so some people prefer to turn it (or keep it) off. Unfortunately, such glitches vary by content, by hardware configuration, and even by driver version.

Thanks, Ryan.

In that case we ought to keep it. Perhaps a slider than goes from low spec PC to high spec PC would set it appropriately. I reckon that sliders will make configuration much easier but access to individual settings will still be needed.

EricF, on 17 July 2021 - 07:18 AM, said:

If some options are re-worked into sliders, it may make them more intuitive in terms of increasing/decreasing and effect or value, which is good. But make sure there's some sort of clear description and scale on the control so that it's understandable.

Indeed, Eric. Point taken.

-------------------------------------

It seems to me that this exercise is very valuable, (provided it goes beyond forum posts to code changes for the better). So thanks for all your continued input.

-------------------------------------

Moving on then to the next control:



The Manual has "When this option is selected, the OR update rate cannot be higher than the monitor vertical sync frequency (typically 60 Hz). This reduces CPU energy consumption in fast PCs."

This statement suggests that there is no downside. Is that really the case?

[Weter]

@EricF
Even better: ORTS menu gives tips and comments, while you dragging sliders, telling you about default value and effect strength.
See experimental adhesion sliders for instance.
As for force feedback, I think, it's not a crime, as far as different wheels has different vibrator's strength and perception of the vibration of control devices is altering in very subjective way from player to player.
We did discuss earlier, how cool that would be, but for now we have no vibrating chair for playing ORTS with force feedback. :D

[YoRyan]

cjakeman, on 17 July 2021 - 10:23 AM, said:

This statement suggests that there is no downside. Is that really the case?

No, there are downsides. One of them is that vsync introduces input lag. And if your system cannot render as quickly as your monitor's refresh rate, vsync will cause an annoying graphical stuttering effect.

In general I would say most, if not all of the video options need to be left independent. Players need precise tunables to accommodate every possible hardware configuration and personal preference. That's why even commercial video games have complex video settings screens.

[R H Steele]

YoRyan, on 17 July 2021 - 10:53 AM, said:

No, there are downsides. One of them is that vsync introduces input lag. And if your system cannot render as quickly as your monitor's refresh rate, vsync will cause an annoying graphical stuttering effect.

In general I would say most, if not all of the video options need to be left independent. Players need precise tunables to accommodate every possible hardware configuration and personal preference. That's why even commercial video games have complex video settings screens.

Perfect explanation! I almost replied to that exact point earlier this morning, but decided I did not know how to clearly explain what I saw with my older desktop ( until I upgraded some components, graphics and such ) --- this effect does not appear on my alienware laptop.

[ebnertra000]

The term I've always heard is 'screen tearing', which I have noticed when the frame rate exceeds the monitor's refresh rate.

Is there a benefit to having it turned off?

[EricF]

Vsync is a complicated subject. Vsync off allows the GPU to run as fast as it's able given whatever it's processing. That can lead to drops in frame rate under heavy load, and "runaway" GPU usage (and heat output) on static screens (like a pause screen) unless there's a check for that condition in the application which invokes throttling under pause/static images. Vsync on will attempt to do as its name implies; keep GPU processing output synchronized to the monitor's frequency. Basic Vsync was 60Hz for ages until high-refresh-rate monitors came out -- now it's often selectable at 60/80/90/100/120 Hz or some subset thereof. (Game engine permitting, of course.)

Vsync in the game engine vs Vsync or frame rate capping in the video driver may have different effects on resistance to frame tearing and stuttering if the frame rate drops below the monitor refresh rate. Different game engines and drivers may have different effects. Usually better to rely on the game's Vsync, but not always.

Input lag with Vsync is often a case of problems with the game's polling of inputs versus uneven frame rate management versus Vsync. If the frame rate drops below Vsync, the image may stutter and lose sync with inputs as well. But it doesn't have to; it's up to game engine design. Nevertheless, if the image is stuttering, the payer may perceive input lag or uneven input reactions.

If the CPU and GPU both can maintain stable output at least slightly above the Vsync value, frame rate and input should be fluid and stable unless output drops below Vsync. Generally, the smoothest image and input comes from having Vsync set comfortably below the maximum throughput. It leaves ample headroom particularly for the GPU to have cycles in reserve for uneven inputs and sudden heavy demands. It basically flattens output demand, which tends to have a beneficial effect on stability. For lower monitor refresh rates, it often performs better matching between GPU output and monitor maximum frame rate input. For a train simulator, a stable match between GPU output and monitor refresh will tend to give the smoothest results -- and Vsync can be useful to essentially arbitrate that.

FreeSync (AMD/open source) and GSync (Nvidia proprietary) variable-refresh screens add extra twists. The additional processing in the monitor hardware is designed to prevent "screen tearing" without invoking Vsync. But not all game engines take advantage of it well, so in some cases invoking Vsync or at least frame rate capping in the graphics driver is still useful. Running variable-refresh monitors with games which don't handle them well are another place where input lag becomes an issue. Depending on how inputs are synced to frames, it can induce stutters and lag that wouldn't normally be present just because the game engine isn't able to cope with that scenario.

Examples of how this works out in the real world is in the trade-offs between graphic detail settings, anti-aliasing and image processing, and rendering options versus frame rate. Max all the settings out in a game and even a high-end GPU may have issues keeping up a consistent frame rate. Leave settings maxxed out, but invoke Vsync, and there's enough "headroom" for the GPU to crank out maximum output at 60-90 FPS, for instance. Or, selectively dial-back GPU-costly anti-aliasing and rendering options to gain maximum raw frame rates. There are trade-offs either way.

I'd guess that for Open Rails, Vsync on is probably going to offer the best performance for most use cases and monitors. Ideally, it's best if Vsync can be aware of and selectable for monitor refresh rates above 60Hz. Not everyone is going to be satisfied with 60 frames per second, so offering the options for Vsync at higher refresh rates may make sense for user satisfaction and acceptance. (And the ability to set it below a high-refresh rate monitor's default can avoid issues with frame rate drops.) In the modern age of high-fps monitors and games which capitalize on them, some people's eyes are very much "trained" for higher frame rates/refresh rates and will perceive classic 60Hz Vsync as too slow and blurry. But that comes with the caveat that supporting higher monitor refresh rates also requires investing in more costly monitors and graphics cards -- not just for the end-users, but for developers as well, since the game engine will have to be tested for stability and quality at those higher standards.

[steamer_ctn]

This thread is demonstrating that we have introduced a huge amount of complexity into OR by allowing all sorts of option selections by users. Given the fact that we are having to ask about each item suggests that they are not clearly understood by the majority of the developers and players of the game (I certainly fit into this category with some of the options), so what chance do some of the users have when they attempt to fiddle with them on their PCs?

One only has to look at the forums to see the issues created by users playing with option settings without fully understanding what they do. On top of this we need to consider the amount of effort required by the community to try and assist the user to "fix" their problems.

If we introduce sliders I believe that this will further increase the complexities even more as we are introducing additional option variation.
Hence I believe that as part of any work being done to change the options menu we need to consider adding some way of providing a quantitative measure for support for these types of options. I would see this as a form of "option debug" for the user and community. This could take the form of an error/informational message that is generated when the option is selected, and appears to be creating an issue.

So for example, for Vertical Synch would it be possible to monitor the OR update rate, and compare this to the monitor vertical sync frequency, and provide a log message if it exceeds or approaches this limit?

This would allow the users to self debug this feature, or at the very least allow community support to zero quickly in on potential trouble points.

Similarly we need to look at the other options in a similar fashion.

[YoRyan]

Vsync is a standard feature in almost every PC game ever released. I am surprised so few of you have heard of it.

The expectation is not only that it's available, but that it's configurable on a manual on/off basis. Here is the video options screen for Microsoft Flight Simulator, a 2020 game:



In short, I would not support any proposal to remove this option, or to fold it into a global quality slider.

[jonas]

Beyond the questions discussed here about whether an option is still necessary or not, I realize from reading the last few posts that informing the user what the particular option actually does exactly is an important point.

I now understand more here about the Vsync option and its pros and cons with respect to OR than I ever would have from OR's menu surface (and probably not from the OR manual).
I'm sure the user doesn't expect the verbosity of this thread, but that for example turning on the Vsync option can cause "stuttering" on slower computers is certainly not known by many, although I can remember the Vsync function at least back in ATARI times :-)

I sometimes miss Fliyouts or ToolTipsTexts in the menu surface of OR, which give further detailed information about the menu options.
The "i" dots from Chris on the first option card "General" are a good way I think. Remains the question, which information one gets then in the manual and is the respective information sufficient.