[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.

[EricF]

Vsync is probably a good worst-case scenario for condensing down the basics for a tool-tip or popup explanation.
A good tool-tip or explanation for Vsync would be something like:


"VSync attempts to lock ORTS' output frame rate to your monitor's refresh rate for the smoothest image and to resist image "tearing"
VSync may help keep the frame rate more stable on complex routes, reducing sudden frame rate drops and apparent control lag in some cases"
If ORTS' frame rate drops below your monitor's frame rate, you may see stuttering or image "tearing"
If this happens, reduce the ORTS graphic options such as view distance, anti-aliasing, or world object density until it no longer happens"

That's probably enough to fit in a tool-tip box or a popup description. It's still longer than what might be ideal, but it manages to condense the main aspects of Vsync in games into a "just the facts" format. I've seen worse, more verbose explanations in games for settings with multiple aspects/performance impacts. In this case, it gives the end-user some idea of what Vsync is used for, and what to do if the setting isn't fixing their apparent problem (Adjust several likely graphics settings). It doesn't bother with any details like how frame rate is affected by screen resolution (more pixels=more for the GPU to drive) or additional processing loads like ReShade -- that all belongs in the manual.

Settings which control a single aspect or effect rarely need more than a one-liner tool-tip or popup text explanation.

The only thing missing might be whether or not the particular setting is turned on by default (And with respect to Vsync, there's no "standard" in games. Some default it to "on", some don't; it's a design decision.) I tend to prefer it if the default can be indicated somehow; it's more informative than just dropping a generic "reset to defaults" option on a settings page which puts everything there back to default at once, but no indication of what will be when you click it.

I will say that settings menus are probably one of the more neglected aspects of game design in general. While most modern games try to keep the settings pages looking pretty and organized into reasonably cohesive groups of settings, The current state of Open Rails explanation of the settings is really no better or worse than what's found in much of the larger world of computer games and simulations. The Microsoft Flight Simulator example above shows how that development team is now leaning into better explanations of the settings (I was a beta tester; it's come a long way...) but there are other areas where that interface still has "gaps" in either good explanations or ease of visual understanding of what a particular setting is doing. It's difficult to account for all contingencies without it being intimidating or causing information overload.

In many cases, it makes sense to offer a "basic" interface which is basically a collection of high/medium/low default presets, and then offer an "Advanced" gateway option which displays the full range of settings and more detailed information. It's a good way to make a game with complex settings more approachable to players of varying tech comfort levels. It can make support easier for helping a non-technical user; eg "You can fix that particular problem by first putting your graphic settings on "High", then go into the Advanced menu and set just these three values to ("x", "y" and "z")"

[R H Steele]

EricF, on 18 July 2021 - 05:30 AM, said:

Vsync is probably a good worst-case scenario for condensing down the basics for a tool-tip or popup explanation.
A good tool-tip or explanation for Vsync would be something like:


"VSync attempts to lock ORTS' output frame rate to your monitor's refresh rate for the smoothest image and to resist image "tearing"
VSync may help keep the frame rate more stable on complex routes, reducing sudden frame rate drops and apparent control lag in some cases"
If ORTS' frame rate drops below your monitor's frame rate, you may see stuttering or image "tearing"
If this happens, reduce the ORTS graphic options such as view distance, anti-aliasing, or world object density until it no longer happens"
...

Thanks, Eric, your explanations always help me out, in fact, that's just the solution I took with my old desktop when trying to use Vsync. With the new laptop set for Vsync, the fps for OR ( in all routes so far - complex and less so ) is set at 60 and everything runs comfortably, smoothly, with no visual aberrations apparent to me.

[cjakeman]

YoRyan, on 17 July 2021 - 03:53 PM, said:

Vsync is a standard feature in almost every PC game ever released.

The expectation is not only that it's available, but that it's configurable on a manual on/off basis.

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

So, as for Model Instancing, Vertical Sync is a control that we ought to keep.

Perhaps a slider that 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 this individual setting will still be needed.

EricF, on 18 July 2021 - 05:30 AM, said:

"VSync attempts to lock ORTS' output frame rate to your monitor's refresh rate for the smoothest image and to resist image "tearing"
VSync may help keep the frame rate more stable on complex routes, reducing sudden frame rate drops and apparent control lag in some cases"
If ORTS' frame rate drops below your monitor's frame rate, you may see stuttering or image "tearing"
If this happens, reduce the ORTS graphic options such as view distance, anti-aliasing, or world object density until it no longer happens"

Thanks for this, Eric.

I am more than happy to extend the (i) icons already in the General tab into the other tabs also. That takes the user directly into the manual, which let's us provide diagrams and links to other resources if needed.

I will replace the current manual text with yours (and we can do this before releasing v1.4).

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

Moving on to the next control:



The manual help is here at 6.3.9 Do read that and read on to consider the letterbox presentation with Ctrl+1

I am wondering if this %age stretch should be retired.

Instead of maintaining the original arrangement which filled the window with a distorted image, we could drop that entirely.Instead the image would always be undistorted and the user could simply choose between filling the window (and scrolling to see the hidden portions) and fitting the image wholly within the window and padding with black borders.

Bring on 3D cabs :-)

Does anyone ever run Open Rails with any stretch at all?

[Weter]

Eyes adopt to everything, but why victims?
I appreciate the CaB scrolling, which gives an illusion of virtual cad, though, I have only 2d.
Yes, I can't see BC manometer and locomotive signal aspect display simultaneously, but I don't like distorted circles of gauges.
I don't like cab stretch.
BTW, are your icons links to local disc manual, or to online resource?

[Csantucci]

cjakeman, on 18 July 2021 - 10:25 AM, said:

Does anyone ever run Open Rails with any stretch at all?

Chris,
when some work was done on it, I had the intention to remove the option, but someone here in the forum begged me to leave it, because he was running with cab2dstretch...