Quote from Scawen :

Is there a standard safe setting used by other games, limiting frame rate by default in some way?

I would be interested to hear from anyone who knows about G-sync and Freesync monitors and how they interact with the vertical sync option.

Usually it's just V-sync (sometimes with an option for pre-rendered frames) or a manual framerate limiter to avoid V-sync induced input lag.

Unfortunately I don't have a G-sync/Freesync monitor yet, so I can't help with that.

Quote from Scawen :

Maybe "full screen vertical sync" should be enabled by default. It's easy to turn off.

I'm not sure if that's a good idea for new players who might experience some input lag and don't know that it's because of v-sync. It could be a bit off-putting for them.

But maybe most people know that already, so they can turn it off in options if it causes trouble, as you said.

VSYNC has to be off to let GSYNC control the refresh. There are some super precise article around but no time to find them.
I previously was running lfs on a TV with a high input lag around 100ms. That was the worse. Driving was harder especially in pack. Feeling was not as good as years before. I was not suffering much from tearing or stuttering anyway.
On Gsync I set frame limit to 100fps (maybe 102 or so would be better but is hard to test for sure) and resolution 1920x100hz. Input lag is supposed to be low. I don't feel no lag no tearing no stuttering even on Westhill were I can drop down to 70fps or maybe less for a short while. To really see tearing on lfs I do vsync off, gsync off (or my old tv) and then spectate high speed cars on the straight from outside. Gsync remove it.
On my setup the low input lag has more effect. On newest game like farcry 4 or gta gsync is perfect for smooth experience.

Thanks for the info.

For now, I have reduced minimum sleep to only have the possible values 0 and 1. I've also worked on the maximum frame rate system so it provides accurate frame rates for these more sensible options:

20, 25, 30, 50, 60, 75, 90, 100, 120, 125, 150, 180, 200, 240, 250, 300, 400, 500

It produces these frame rates in the most efficient way it can, using whole numbers of milliseconds.

For example,

100 fps is of course 10 ms per frame and 250 is simply 4 ms per frame.
60 fps comes from a repeating sequence of 17 ms, 17 ms, 16 ms frames.

My thoughts on the last several posts:

• GPU overheating - IMO, no need for the game to fret about this. In any case, why would high fps be any different from low fps but much higher workload per frame? Users can choose how how hot to run their GPU, and whether or not to impose fps limit. Having said that, I have never seen the point of very high fps (e.g. > 100)
  
• min sleep: firstly, as Scawen is probably aware, Sleep(0) does actually do something (it ends the process timeslice but leaves it ready to run). I *think* that on a pre-emptive multitasking OS, LFS shouldn’t need to do this at all. Scawen - do you remember which OS gave the trouble? Unless it was pre-NT it shouldn’t have happened... I'd be keen to see if totally removing the Sleep() call does anything bad on any machine.
  
• Furthermore, Sleep(1) should be barely distinguishable from Sleep(0) - provided I'm correct to think the Sleep is once per frame. Even if frame rate is only (say) 60 fps, then it’s going to sleep for 1ms in every 16.7ms, thus barely noticeable... Only someone who is (pointlessly! ) running at more like 200+ fps is gonna see a significant fps drop.
  
• Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?
  

Quote from Neilser :

Having said that, I have never seen the point of very high fps (e.g. > 100)

3D monitors/glasses require dual FPS60.. So 2x60FPS = 120 FPS (for example)

So this change is good. If I ever want to try this Nvidia glasses thing, I can maybe fall for that.. Not O.Rift ...

Quote from Neilser :

My thoughts on the last several posts:

• GPU overheating - IMO, no need for the game to fret about this. In any case, why would high fps be any different from low fps but much higher workload per frame? Users can choose how how hot to run their GPU, and whether or not to impose fps limit. Having said that, I have never seen the point of very high fps (e.g. > 100)
  
• min sleep: firstly, as Scawen is probably aware, Sleep(0) does actually do something (it ends the process timeslice but leaves it ready to run). I *think* that on a pre-emptive multitasking OS, LFS shouldn’t need to do this at all. Scawen - do you remember which OS gave the trouble? Unless it was pre-NT it shouldn’t have happened... I'd be keen to see if totally removing the Sleep() call does anything bad on any machine.
  
• Furthermore, Sleep(1) should be barely distinguishable from Sleep(0) - provided I'm correct to think the Sleep is once per frame. Even if frame rate is only (say) 60 fps, then it’s going to sleep for 1ms in every 16.7ms, thus barely noticeable... Only someone who is (pointlessly! ) running at more like 200+ fps is gonna see a significant fps drop.
  
• Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?
  

I can see it being a bigger problem on a single core machine, rather than a 4 or 8 core monster that many people have.

Quote from Scawen :

Or maybe I should add a new option "windowed vertical sync" as well.

I remember that being accidentally forced to be on in the early DX9 test patches - it would be a useful feature IMO.

Quote from Scawen :

Is there a standard safe setting used by other games, limiting frame rate by default in some way?

The only frame rate limiting I know of is where the engine is tied to 30/60fps due to being a crappy console port.
Any sensible limits not tied to v-sync probably vary a lot depending on specific hardware combinations and personal cooling noise preferences.

Quote from Scawen :

I would be interested to hear from anyone who knows about G-sync and Freesync monitors and how they interact with the vertical sync option.

An interesting input lag investigation with V-Sync vs no V-Sync, FreeSync vs G-Sync at different target framerates: https://www.youtube.com/watch?v=MzHxhjcE0eQ
Jump to ~ 11:40 for graphs, although there is some interesting stuff earlier in the video.

Quote from Degats :

An interesting input lag investigation with V-Sync vs no V-Sync, FreeSync vs G-Sync at different target framerates: https://www.youtube.com/watch?v=MzHxhjcE0eQ
Jump to ~ 11:40 for graphs, although there is some interesting stuff earlier in the video.

Interesting results. VERY hard to make sense of 'em though!

Good job Scawen. The preformance boost is a real kick, although there are some random drops in FPS (Tested in Westhill)

Quote from Neilser :

Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?

It's easily noticeable, atleast on FFB wheels.

Not to mention VR headsets.

Yep input lag is mainly a monitor issue. It is impossible to feel if you are spectating but behind the wheel you will notice. Some monitors are above 100ms and it is way too much.

Quote from Scawen :

For now, I have reduced minimum sleep to only have the possible values 0 and 1.

That sounds much better!

Quote from loopingz :

Yep input lag is mainly a monitor issue. It is impossible to feel if you are spectating but behind the wheel you will notice. Some monitors are above 100ms and it is way too much.

I wouldn't call input lag a monitor issue. It's more like an LFS issue. Reason why its there is because when VSYNC is on during some frames there is only one physics calculation, but again at some other frames there will be two physics caluculations. Because time step between these physics calculations is very short same contoroler (wheel) position is used.

1. Frame

(get wheel data)
-1. physics calc

2. Frame

(get wheel data)
-2. physics calc
-3. physics calc (same input data is used)

3. Frame
...

Quote from Matrixi :

Quote from Neilser :

Input lag: surely this isn't noticeable with vsync on, even at only 60Hz refresh?

It's easily noticeable, atleast on FFB wheels.

Not to mention VR headsets.

I use a G27. At 20fps (frame rate limited) I can certainly observe input lag. At 60 fps, I personally can't.

Quote from loopingz :

Yep input lag is mainly a monitor issue. It is impossible to feel if you are spectating but behind the wheel you will notice. Some monitors are above 100ms and it is way too much.

If you're spectating, there is NO input, so lag is impossible by definition, so I think I don't understand your point.

Quote from DANIEL-CRO :

1. Frame

(get wheel data)
-1. physics calc

2. Frame

(get wheel data)
-2. physics calc
-3. physics calc (same input data is used)

3. Frame
...

Thanks Daniel - nicely put. However, I would say that having multiple physics calcs with one input setting isn't by itself a problem; rather it's having too long between fresh fetches of the wheel data. I personally don't think 17ms (i.e. 60fps) is too long.

EDIT: why not get wheel/controller data and do the physics updates at the same rate? (100Hz right now, I believe.) That intuitively feels like the right thing to do. Reading the inputs each time the display updates seems... wrong. I would hope, perhaps incorrectly, that it's not a major code change. (I know this has been discussed in the past but a quick search didn't find me the threads in question.)

Somehow I forgot to include this bit in my last post:

Quote from Scawen :

The question is more like "Does minimum sleep 0 cause problems on some computers?"

Task scheduling has improved vastly in modern OSs and further improved now multi-core is common.

The last time I remember regularly having issues was a single core CPU on XP (don't think the various LFS sleep times made any difference back then though).
Somehow Chrome still manages to make my mouse cursor lag like a trooper (movement sometimes streched over 10+s) when it's loading multiple tabs, even on a quad-core on Win8.1, but Chrome's behaviour is far from a normal application/game though so there's not much to read into that.
FWIW, my old dual-core laptop that can barely run LFS anymore (it cries at Westhill ~6fps) seems to show no obvious difference with the various sleep modes. The only difference is a small framerate improvement on other tracks when min sleep is turned to 0. 1 and above seem to behave the same. It is GPU limited in Westhill rather than CPU limited though, so may be irrelevant.

I've seen Firefox do really bad stuff to my laptop as well. Not sure how/why...

I may well be misremembering/misunderstanding how Windows scheduling works. But... I really do doubt that the Sleep() is necessary at all.
IIRC, it used to be that as long as an app is doing a PeekMessage() or similar (or its modern equivalent) now and then, stuff just works.

In this direction, how about trying something like
if (minsleep != -1) Sleep(minsleep);
and of course allowing the user to reduce min. sleep to -1?

Then people could see what happens when the Sleep() doesn't happen.

If you need to change priority for a specific process, i.e. LFS.exe,
alt,ctrl,del to task manager, go to processes tab, right click on program, (LFS.exe)

That will work for nearly all processors as LFS is only single core. It will help

Thanks for the comments, links and discussion. I'm quite happy with the new frame rate limiting system which can really hit the target frame rate accurately now.

I'm adding an option to adjust the number of buffered frames, and an info display moving bar chart which should hopefully be quite interesting. It will be able to show the effect of minimum sleep, maximum frame rate and number of buffered frames.

About the minimum sleep, LFS doesn't call Sleep(0) anyway. It uses Sleep(x) (with x >= 1) to limit frame rate if needed. The minimum sleep setting in your version forces it to sleep for that number of milliseconds even if the target frame rate has not been reached. If you have the setting at 0 and you are not limiting frame rate, then there is no sleep call except while it is waiting for the GPU to finish rendering to prevent input lag. But the behaviour round there is different now as buffered frames are allowed. I hope the info graph will illustrate this effectively.

Sounds good - looking forward to testing. (And thanks for clarification on Sleep() calls.)

Quote from Racer X NZ :

If you need to change priority for a specific process, i.e. LFS.exe,
alt,ctrl,del to task manager, go to processes tab, right click on program, (LFS.exe)

Use Ctrl + Shift + Esc to start the Task Manager directly. ;-)

Quote from Scawen :

I'm quite happy with the new frame rate limiting system which can really hit the target frame rate accurately now.

Every framerate beyond the monitor refresh rate is useless. Why dont just use Vsync only? Also flatscreens have a refrsh rate. It is not true that the refresh rate have no effect on flatscreens.
In Aston i have everywhere 50 fps. But smooth is it not everywhere. But this i wrote already. Now i migrated to the A6-6310. But at time is a A10 for the same price available Its really not a gamer APU, but its the beginning of the future of computers.

Quote from matze54564 :

Quote from Scawen :

I'm quite happy with the new frame rate limiting system which can really hit the target frame rate accurately now.

Every framerate beyond the monitor refresh rate is useless. Why dont just use Vsync only? Also flatscreens have a refrsh rate. It is not true that the refresh rate have no effect on flatscreens.
In Aston i have everywhere 50 fps. But smooth is it not everywhere. But this i wrote already. Now i migrated to the A6-6310. But at time is a A10 for the same price available Its really not a gamer APU, but its the beginning of the future of computers.

Because Vsync can introduce input lag, along with inconsistent FPS if your frame rate is near (but below) your refresh rate. Triple buffered vsync makes it less bad, but you end up with jumps from 30 to 60 FPS and back.

Besides, more options are better. If you want to enable vsync, you can. The majority of gamers disable it, especially in games where reactions are important becuase feeding every frame, with minimum delay, is important. Vsync forces frames to coalesce to the monitor, which can introduce millisecond delays.

@dawesdust_12: i bet, the delay is bigger when have asynchron fps, because then you see some frames not because the monitor is not able to show you the frame.

That doesn't make sense. vsync forces the process occasionally to "hold" a frame until the next refresh occurs, which means that frame could be many miliseconds old. Thats how input lag occurs.

Without vsync, you're always getting the newest frame possible because there's a surplus of frames, without any having to wait.

Quote from dawesdust_12 :

Without vsync, you're always getting the newest frame possible because there's a surplus of frames, without any having to wait.

Thats not true, because your monitor have a refresh rate of maybe 70 Hz or 60 Hz (50 Hz are only for Freaks using german tv on pc) and and when you are limiting the frame rate to 100 Hz, your monitor won´t show you 30 frames. 1 skipped frame is like 10 ms delay.