Your PC will go into power saving mode by default when switching from AC power to battery, try changing your power/battery settings from "High Performance" to a plan where the laptop doesn't go into power-saving mode.

Edit: Just saw you solved it.

Small summary of performance LFS version 0.6E to version 0.6H5 (Windows 7 64bit)


LFS 0.6E to 0.6H5 work 2x faster

Scawen: I'm just curious now...
If somebody has 200 fps, phys update happens only every other frame (100Hz max). So if he's driving inside car, he gets two identical graphical frames? Or how does the "every other" gfx frame without phys update differ from the first one after phys update?

He will get 60, 75 or 120 FPS depending on his PC monitor. But theoreticaly, if he would have 200Hz monitor, he would get two identical frames because between first and second frame, the physics update has not occured.

By the way, no performance change at my side. Still locked on 75FPS on max. settings, everything works perfectly, even after update to Windows 10.

Quote from Lucas McFly :

Small summary of performance LFS version 0.6E to version 0.6H5 (Windows 7 64bit)


LFS 0.6E to 0.6H5 work 2x faster

Thanks for that chart and thanks Scawen for all improvements!

Quote from Ped7g :

If somebody has 200 fps, phys update happens only every other frame (100Hz max). So if he's driving inside car, he gets two identical graphical frames?

Exactly!
Moreover using VSYNC (60 FPS) while game runs at 100Hz causes discontinuous move of a world around you. For example you are driving at 90 km/h, that makes 25 m every second or 0.25 m every game loop (0.01 s). World around you will move by 0.25m first frame, 0.5m 2nd frame, 0.25m 3rd frame, ... which should be easily noticeable if you look at the side while driving fast.

my pc is just able to deliver around 120fps on the new westhill if i do not limit the frame rate and leave v-sync off.
now i noticed if i use v-sync at 60hz then there is noticeable stutter at some points of the track where the frames fall just below 60fps - e.g. 58 or 56fps. (i believe the frames then drop to 30 to get v-sync every second frame?)

but if i set the frames to 75fps fix it does not fall under 60 at any point of the track any longer, so it does not stutter like with 60frames fixed or v-sync.

is this setting of 75fps better for me to get more constant frame rates, than to limit to 60frames or use v-sync (my monitor runs at 60hz)?

also what does this mean for physics and input lag? would it be better to switch to 100fps to be at the same speed as the physics engine?

just letting everything free running at the highest fps is also not as smooth as the 75fps setting, because then there is way more dynamics in the fps and the values jumping up and down depending on the place on the track.

could anybody make an instruction on how to find the settings that produce the smoothest display of frames, with the least amount of fps jumps and no input lag?

the performance gain of the test patches on older machines is really great - looking forward to great future releases of lfs!

peace, mo

Quote from DANIEL-CRO :

Exactly!
Moreover using VSYNC (60 FPS) while game runs at 100Hz causes discontinuous move of a world around you. For example you are driving at 90 km/h, that makes 25 m every second or 0.25 m every game loop (0.01 s). World around you will move by 0.25m first frame, 0.5m 2nd frame, 0.25m 3rd frame, ... which should be easily noticeable if you look at the side while driving fast.

So the experience might be more smooth if changing your monitor to 50Hz and add V-sync. Only problem is that the 100Hz physics "clock" is not synchronized with the Monitor clock The only right way to get smooth frames between two non synchronized clocks is to resample timewise all frames but i guess that would really be complex and take a performance hit, not to mentioning lag. Even though not impossible since, to my knowledge, digital tv's have been doing something similar real time for some time now. Else a technology as G-sync should be used but that can't be used with Oculus Rift or other HW not build for it.

Smoother Graphics when setup "Maximum Buffered Frames" to 2 @50 Hz, Vsync on 50,0 fps. Thank you very much.

Aston is now 100% smooth at my AMD A6 APU, Westhill is at the problem zones not smooth....

I have found another bug with new path system, Scawen, please fix this, this is really annoying.

Quote from matze54564 :

Smoother Graphics when setup "Maximum Buffered Frames" to 2 @50 Hz, Vsync on 50,0 fps. Thank you very much.

Aston is now 100% smooth at my AMD A6 APU, Westhill is at the problem zones not smooth....

If the Monitor and Physics clock is not synchronized you will get 1/100Hz= 0.01second time jump error in the flow of frames even if you have 2 frame buffers. the question is how often you get the "time jump error", and that depend on how off sync the two clocks are. It is basically the same that happen when using 60Hz monitor rate where you make a 0,01sec time jump every 3rd frame(3/60Hz= every 50ms). If we say Physics are the Master clock and compared to that the Monitor Refresh rate is 50,1Hz then you will get that 0.01sec time jump every 250 frames(250/50,1 = 4,16sec) this maybe not detectable or maybe the clocks are much more close so the time jump occur even less frequent i dont know, but you will be having some timing error eventually unless it is dealt with some how.

Quote from hetner :

So the experience might be more smooth if changing your monitor to 50Hz and add V-sync.

Tehnically speaking yes, you would get rid of that problem. However as 50Hz is less than 60Hz it may look little a bit hmmm, slower
LFS could possibly calculate new car positions for every new frame based on speed and time since last physics calculation (s=v*t). My idea is to store two car positions for each car, one that is updated every 0.01s and used for physics calculation and other one that is used for purposes of moving view/camera/car. For example as already said running at 300 FPS will not benefit you in any way because 3 frames will be pixel to pixel identical. Still physics would run at 100Hz, however every frame will get its own camera position which is calculated by simple s=v*t equation. From my point of view that is the simpliest solution for that problem.
I guess Scawen like more the idea of having a 1000Hz physics, which should decrease the problem we are having at 100Hz.

BTW Scawen, is there any way we could see if Direct3D9Ex is used? I remember my RAM usage greatly decreasing when going from 0.6H -> 0.6H2 on Windows 7. Now on Windows 10 for some reason I don't get any decrease.

Quote from DANIEL-CRO :

My idea is to store two car positions for each car, one that is updated every 0.01s and used for physics calculation and other one that is used for purposes of moving view/camera/car.

Embarrassingly, I thought that was what LFS already did...

I just wanted to try 50Hz refresh rate by making a custom resolution and only changing Refresh rate from 60Hz to 50Hz but the resolution option do not show up in LFS setting??? if i change it to 56Hz it do show but not if i go under 56Hz??
is this a LFS bug/feature to not allow refresh rates below 56Hz?? I would think it actually would be a good option to be using 50Hz to minimize the frame timing jitter, for a smooth experience even on old HW.

EDIT: OK, I just did some testing in window mode and setting the desktop to 50Hz. It is more smooth than ever.
Only problem is screen-tearing because v-sync does not work in window mode, is that intended?

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI. It just shows the garage background during the delay.

I tested it with a clean LFS install and it occurs in H5 only, it's fine up to H4.

Anyone else with the same problem by any chance?

Quote from hetner :

I just wanted to try 50Hz refresh rate by making a custom resolution and only changing Refresh rate from 60Hz to 50Hz but the resolution option do not show up in LFS setting???

I can set 23, 24, 30, 50, ... Hz in LFS so it shouldn't be a problem. I guess you made custom resolution in a program like AMD CCC, in that case LFS will not display that resolution/refresh rate as an option. Only options are screen modes reported by Windows (that you can configure using just Control Panel).

Quote from Flame CZE :

Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI.

Everything fine here

Quote from DANIEL-CRO :

BTW Scawen, is there any way we could see if Direct3D9Ex is used? I remember my RAM usage greatly decreasing when going from 0.6H -> 0.6H2 on Windows 7. Now on Windows 10 for some reason I don't get any decrease.

You can see near the start of deb.log

Aug 05 21:23:33 started Direct3D 9Ex

Quote from Neilser :

Quote from DANIEL-CRO :

My idea is to store two car positions for each car, one that is updated every 0.01s and used for physics calculation and other one that is used for purposes of moving view/camera/car.

Embarrassingly, I thought that was what LFS already did...

The real way to have graphical frames independent of physical updates is to use one thread for physics and another for graphics. The physics thread must store snapshots of the entire game state (car positions, wheel rotations, suspension extension, tyre deflections, smoke particle positions, etc) and the graphics thread can then read these and render frames in even steps between the last two physical frames. Very interesting but a truly massive task and for various reasons already described, not a good idea to do it now.

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI. It just shows the garage background during the delay.

I tested it with a clean LFS install and it occurs in H5 only, it's fine up to H4.

Anyone else with the same problem by any chance?

I didn't see that in a quick test. Can you give any more info, like if you were online or in a replay, with many cars there, etc?

Quote from DANIEL-CRO :

Quote from hetner :

I just wanted to try 50Hz refresh rate by making a custom resolution and only changing Refresh rate from 60Hz to 50Hz but the resolution option do not show up in LFS setting???

I can set 23, 24, 30, 50, ... Hz in LFS so it shouldn't be a problem. I guess you made custom resolution in a program like AMD CCC, in that case LFS will not display that resolution/refresh rate as an option. Only options are screen modes reported by Windows (that you can configure using just Control Panel).

I actually use Nvidia Control Panel and if i do the exact same custom resolution with a frame rate set to 56Hz it appears in LFS to select and it works, but if i lower it to 55Hz or below, LFS is not showing it as an option in the setting. Pretty annoying actually when i just experienced 50Hz to be very smooth to the eye in Windowed mode because there is not time jitter of 10ms between every 3rd frame(like 60Hz has)

Actually if the physics would only just be changed to 120Hz any 60Hz monitor would run LFS silky smooth as long as frames never drop below 60Hz and v-sync is on.

In my Windowmode@50Hz i can see that Physics and Display refresh rate is very close to be in sync because the screen tearing is moving very slow and almost steady at one point. That would mean that the 10ms time jump error would not happen very often if at all if only it would work one(window v.sync) way or another(LFS accepting 50Hz).

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI. It just shows the garage background during the delay.

I tested it with a clean LFS install and it occurs in H5 only, it's fine up to H4.

Anyone else with the same problem by any chance?

I have the same problem.
Some times i have this message "LOCAL: TIMER BOUNDED"
I am running 0.6H5, single player, no AI, Windows 10.

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI.

Not seeing it here...

Quote from DANIEL-CRO :

I can set 23, 24, 30, 50, ... Hz in LFS so it shouldn't be a problem. I guess you made custom resolution in a program like AMD CCC, in that case LFS will not display that resolution/refresh rate as an option. Only options are screen modes reported by Windows (that you can configure using just Control Panel).

I was going to try a custom mode, and then checked my monitor manual which says 56Hz is the minimum :-/

Quote from Scawen :

The real way to have graphical frames independent of physical updates is to use one thread for physics and another for graphics.

Yes, I can't believe I keep forgetting what LFS actually does!

One thing I have noticed, which may be something you plan to tune up: when the fps target is changed, there's a brief settling period where I'm assuming the program works out how long it needs to wait(?). After that, the GPU wait time stays pretty stable. When the CPU load changes, I'm guessing that this sleep duration isn't instantly adjusted and that therefore maybe this can contribute to jerkiness. (Should probably only matter much when the load increases I guess.) I may just be inventing nonsense reasons for what I'm observing - when I've driven H5 a bit more and made more sense of the graphs I may be able to describe the symptoms better.

Quote from Scawen :

Quote from Flame CZE :

I'm currently having an odd problem in H5. Whenever I go to the pits (Shift + P), there is a 1 to 3 second delay before it shows the garage GUI. It just shows the garage background during the delay.

I tested it with a clean LFS install and it occurs in H5 only, it's fine up to H4.

Anyone else with the same problem by any chance?

I didn't see that in a quick test. Can you give any more info, like if you were online or in a replay, with many cars there, etc?

I just found out that it happens only when there are no other cars on track. It happens in both single player and multiplayer modes.

Using Windows 10 too btw.

Quote from nacim :

I have found another bug with new path system, Scawen, please fix this, this is really annoying.

What gauges are those?

Quote from dawesdust_12 :

OS X is weird as everything is "V-Sync". I'm not sure if games override it either.

The window manager vsync's everything by default. You can disable it on a per-boot basis. The feature in Quartz is "BeamSync".

Shouldn't that limit LFS to 60 FPS though? If I leave v-sync off in LFS, but leave frame limiter on @ 100 FPS, that's exactly what I get.

But if I turn v-sync on in LFS, the framerate starts bouncing between 120-150 FPS.

Quote from MiniVan :

Quote from nacim :

I have found another bug with new path system, Scawen, please fix this, this is really annoying.

What gauges are those?

The modified gauges are part of the LFSLazy Dashboard feature. Click me

Quote from Neilser :

One thing I have noticed, which may be something you plan to tune up: when the fps target is changed, there's a brief settling period where I'm assuming the program works out how long it needs to wait(?). After that, the GPU wait time stays pretty stable. When the CPU load changes, I'm guessing that this sleep duration isn't instantly adjusted and that therefore maybe this can contribute to jerkiness. (Should probably only matter much when the load increases I guess.) I may just be inventing nonsense reasons for what I'm observing - when I've driven H5 a bit more and made more sense of the graphs I may be able to describe the symptoms better.

The Sleep time is adjusted every frame to try and hit the target. It doesn't take more than one frame to work it out. The settling period you are seeing may be just the frame rate gauge which measures the average frame rate over the last 18 frames. So when one frame takes a tiny bit longer there shouldn't be a glitch.

If you see GPU wait time while trying to run with limited frame rate then you are probably not going to hit the target frame rate. In order to successfully hit the target frame rate, all waiting time should be in the Sleep column. If you see anything in the Wait column (waiting for GPU) then you will not hit the target frame rate.

Quote from Flame CZE :

I just found out that it happens only when there are no other cars on track. It happens in both single player and multiplayer modes.

Using Windows 10 too btw.

Thanks, I think I'm homing in on where this bug should be. Please confirm this is with frame rate limit set and should not matter if you are full screen or windowed. What is your frame rate limit setting?

EDIT: And is your computer achieving that frame rate limit at the time you press SHIFT+P?

Quote from Scawen :

The Sleep time is adjusted every frame to try and hit the target. It doesn't take more than one frame to work it out. The settling period you are seeing may be just the frame rate gauge which measures the average frame rate over the last 18 frames. So when one frame takes a tiny bit longer there shouldn't be a glitch.

If you see GPU wait time while trying to run with limited frame rate then you are probably not going to hit the target frame rate. In order to successfully hit the target frame rate, all waiting time should be in the Sleep column. If you see anything in the Wait column (waiting for GPU) then you will not hit the target frame rate.

Sorry I think I was mixing up two issues.

When I run with vsync, I get plenty of GPU wait. When I tinker with something the wait time can do slightly odd things. Best example is to alt-tab out and back in again - then there is a large fraction of a second with no GPU wait shown, but things seem to be vsynced still, and then suddenly the wait time registers and I get a nice salmon-coloured (?) stripe in that column. Slightly strange. And now that I'm looking for it, I can see a variation in the FPS readout during this time (which will be the averaging you just explained), but it hits a solid 60 well before the GPU wait shows up. Perhaps the GPU wait probably is actually happening but just not being shown...

When I run with a limited rate, yes I do get only sleep. For that case, I'd need to do more testing to figure out what oddness I had seen before (But since vsync works so well now I'm using that almost all the time.)