That's not how it works. Without VSync and framerate that is not an integer fraction or multiple of the screen's refresh rate you get tearing - one part of the screen displays Nth frame while the other part of the screen shows N+1th frame. This is annoying to look at but it doesn't introduce any delays.
There is a good case for setting the frame rate to 100 Hz. This way, there is a read from the steering wheel for every physics calculation. Some people like higher frame rates for their own reasons. Anyway, it's interesting to see in the new moving bar chart which works well.
I had hoped to release test patch H5 this weekend but that issue with the transparent autocross objects not being visible until the optimise button is clicked has taken longer than expected. Rather than a quick fix I am working on a worthwhile improvement.
I've noticed that my skins are visibly more smudged in newer patches, compared to pre-new Westhill releases. I've always had all the mip biases set to 0.0, to smoothen the background. Any chance to fix those skin definition problems (check the front of the roof area).
I have tested on Linux with Wine and an old mobile Radeon GPU using open source drivers which have poor performance. In the worst places on Westhill from the cockpit view the framerate went up by around 40 % in 0.6H5 when compared to 0.6H (in 0.6H4 it was maybe 15 % better then 0.6H). Very impressive!
Joining servers should not be affected, maybe a coincidental internet glitch at your end?
Yes, there will be tearing at 60 FPS because the frame update is not synced with the screen. The only way to avoid tearing is vertical sync, but if you do use vertical sync, don't use buffered frames as they will cause lag. It seems to me that 100 Hz is the best limit, because there is one physics update per frame.
Sleep every frame probably isn't needed except for people using unlimited frame rate and maybe things like having a single core CPU. Basically I don't think it is needed unless you get problems like Windows forgetting to pass messages, update internet, controllers etc... and this may not happen at all with modern OS or dual core CPU.
Has anyone tried the frame info graph? You can switch it on in Misc Options and if you click the car icon you can see it in game.
Phys in graph isn't exactly just car physics as far as I figured, but it includes time to handle interface and stuff.
While messing with that graph I noticed that everytime I activate LFS window I get stutter almost a second long. What I mean is your LFS is on half on screen and on other half you have other program which is active, when click on LFS to activate it that stutter happen. Anything possible to do with it?
Now that sleep option is much more simple one other thing came to my mind
Sound lag, how many people actually understand what does it do and why it is needed? Probably less than 1% I'd say
My explanation in short... Sound isn't constantly produced, but programmer has to provide sound that will be played between this and next frame. Sound lag is infact a value which says how far to buffer sound. So if FPS is 100 you'll have to use minimum Sound lag of 0.01s. Value less than that will result in sound stutter. Less lag is always better as log as there is no stutter.
Of course as it was the case with Sleep I doubt many people understand its meaning. Well, to get sound stutter with the minimum setting of 0.05s your LFS have to run at less than 20 FPS which is pretty unplayable. What I've got on mind is a simple system that would dynamically adjust that setting based on your FPS and perhaps totally hide it from user.
As most of us are running pretty high FPS nowadays I'd suggest using minimum Sound lag even lower than 0.05s. Difference between 0.05 and 0.10 is easily noticeable for me.
And i like the graph it is really helpful when adjusting graphics on an old HW to find compromise between detail and performance.
However i did find a "funny" texture missing error once at WE1X see attached.
I found it both in H and H5. i did try to reproduce in a second run without luck, but it is happening in the attached replay (time 2.51). I am not sure if this is a know bug i just wanted to report it.
I think you can use a frame rate limit if you like or vertical sync if you like, but in any case, do not allow more buffered frames than you need. They will add lag if you add more than the number that increases your frame rate. I guess for most people, 1 buffered frame should be the best. Old LFS had the equivalent of 0 buffered frames. It's still possible that 0 buffered frames is best, to reduce input lag, if you are using vertical sync and you never drop below your monitor refresh rate.
With buffered frames, more is not better! Just enough to achieve your desired frame rate and no more!
EDIT: I know there are a few points to answer in the posts above, and I will do so. Thanks for the feedback.