The online racing simulator
Test Patch U16: Updates and fixes
(408 posts, closed, started )
Thanks for the testing and reports.
Quote from Flotch :How is this working : does more sleep mean more cpu "free" time ?

Yes. Sleep is done deliberately by LFS if you limit the frame rate or if "Sleep every frame" is set. It calls a function "Sleep(x)" which gives up x milliseconds to the operating system before continuing to process LFS code. It tries to do just the right amount of Sleep each frame to get down to the target frame rate.

"Flip" is a another kind of waiting time when we are waiting for D3D to finish and present the finished frame. One way to see that is if you use SHIFT+F11 (full screen borderless window) with vertical sync enabled.

I just noticed that if you use SHIFT+F10 (full screen exclusive mode) then all the extra CPU seems to be in "Draw" rather than "Flip" so I'll have a look why that is different from SHIFT+F11.

About your question "why would 31 AI with you cost less less cpu for physics than when alone". That should not be the case. More AI drivers should always use more CPU time for Phys. By the way, the CPU usage for the actual 'AI' is also included in "Phys" and Audio is also included there. But these are very small compared with the actual physics.
Ok, noted. I think I was misunderstanding sleep/cpu time/cpu tick.
Indeed when more AI are present, the percentage for physics is at 20, while alone it barely reach 1. What is logic.

A simple side question : is LFS limiting the cpu usage to compute frames ? for instance, in my case I suppose the clock frequency is getting somewhere at 5GHz when a single core is stressed, and so LFS displays a huge amount of FPS (more than 1300 when alone). But in the mean time LFS knows that my screen is limited to 60Hz => how is handled the thing in the end : does the couple cpu/gpu has really computed the things (1300 fps), but forbid the gpu to send this flow of framerate to the screen ? or is it done anyway, and the screen discard the unecessary frames ?
I know in the past there was some strong proselytizing ( Big grin ) for using vertical synchronization to have fps matching the screen max frequency, but at my level when doing some tests in various games, I tend to have a slightly less fluid experience than not using it ... it is of course very subjective I guess.
Anyway Scawen, I hope you wil succeed to find how to implement the facility for multithreading capabilities for LFS Thumbs up , it ease a lot the cpu consumption for a given result in the end.
Quote from Flotch :I know in the past there was some strong proselytizing ( Big grin ) for using vertical synchronization to have fps matching the screen max frequency, but at my level when doing some tests in various games, I tend to have a slightly less fluid experience than not using it ... it is of course very subjective I guess.

In a lot of games, the processing of controller inputs is tied to the frame rate, so a high FPS will give a lower latency, making the game feel more responsive, even if the same number of frames are rendered on the display.
When inputs (and sometimes physics) are decoupled from the frame rendering, you can still benefit from good latency without having your GPU render loads of frames that will just get thrown out anyway. Some newish GPUs/drivers do some magic to try to improve the latency without having to render so many unneeded frames.
Remember that any need for frame rate higher than 100 Hz was eliminated in test patch U7.

Quote from Scawen :...

About the connection between visual frame rates and force feedback:

In the old system there was a reason to go for higher frame rates to get more immediate force feedback. But this is now controlled by these user settings and there should be no reason to go higher than 100 fps (LFS physics update rate).

Quote from Flotch :or is it done anyway, and the screen discard the unecessary frames ?

Yes, if LFS shows a high frame rate, then all that drawing really is going on and it is being flipped to the screen memory (or an off screen surface) at that high rate. But you can't see it because all those extra frames above 100 Hz are identical to another frame (e.g. at 200 Hz we draw 2 identical copies of every frame). And if your monitor is at 60 Hz you won't even see the 100 Hz non-identical frames. You may see a single tear line if the frame is updated during the vertical refresh.

I recommend limiting to 100 Hz or using vertical sync. Otherwise you are just wasting energy for no reason.

Makes me think of gas flaring: https://duckduckgo.com/?q=oil+flare&t=ffab&iax=images&ia=images
@Scawen : what I see/feel :
* with vertical synch (60 fps here), I find some disturbing transitions between frames. It feels not so fluid in some parts, more often when going at high speed, but even in the corners of Blackwood it is sometimes a bit weird to me. One note : Sleep is = 0.00 in this mode (while my cpu is almost doing nothing)
* at 100 fps I still see some "missing frames" I will call them. Again, it is obviously subjective, but it gives the feeling of a computer slowing down when doing the job
* at 150 fps it looks the same as without limit

@Degats : I see what you mean, and totally agree.
Vsync will inevitably result in slightly larger input lag, as swap will block when next frame is already completed. Thus when it is finally presented to the display it will contain older data than it possibly could.

Example: 60Hz display, Vsync is enabled. Buffer is swapped and in this moment next frame rendering starts. It renders in 4ms, but it needs to wait 16.66-4=12.66ms before it is presented. Note that if during these 12.66ms anything is updated, it won't change queued frame.

To avoid that and not waste electricity, rendering needs to start as late as possible. Thus it is necessary to estimate how long next frame will take to render, and wait for (refresh time - estimated frame time - safety margin) before starting rendering. Some swap modes have an issue there: estimated time is obviously not computed precisely exact, so with vsync disabled, it could tear near bottom/top of the screen. But with vsync enabled, small overshoot will cause waiting for whole next frame, which is even worse. I don't know how it is named in D3D lingo, but in Vulkan swap mode named "FIFO relaxed" would solve this, as it is essentialy "vsync but not if late", it would prevent bottom tearing and avoid catastrophic whole frame delay during occasional overshoot.

(there's possibility some graphics drivers are trying to do these calculations themselves and are blocking during swap for extra time)

Quote :(e.g. at 200 Hz we draw 2 identical copies of every frame)

Does that also mean that in VR mode, when running at eg. 120Hz player car position is not interpolated between 100Hz physics updates? Thus when eg. looking out of the window on track environment, apparent frame doubling will periodically happen, as 100Hz<120Hz?
Quote from milek7 :Does that also mean that in VR mode, when running at eg. 120Hz player car position is not interpolated between 100Hz physics updates? Thus when eg. looking out of the window on track environment, apparent frame doubling will periodically happen, as 100Hz<120Hz?

Yes that is the case. I haven't seen 120Hz but there is a similar effect at 90Hz. For a lot of people, when looking in the direction of motion, this effect is not too bad but some people seem more troubled by it. I don't know if that difference is purely a perception thing or related to the particular hardware. It is certainly noticeable for anyone when you look sideways at the scenery going past.

Simple answer, yes, it's a known problem.
Quote from milek7 :Vsync will inevitably result in slightly larger input lag, as swap will block when next frame is already completed. Thus when it is finally presented to the display it will contain older data than it possibly could.

Example: 60Hz display, Vsync is enabled. Buffer is swapped and in this moment next frame rendering starts. It renders in 4ms, but it needs to wait 16.66-4=12.66ms before it is presented. Note that if during these 12.66ms anything is updated, it won't change queued frame.

To avoid that and not waste electricity, rendering needs to start as late as possible. Thus it is necessary to estimate how long next frame will take to render, and wait for (refresh time - estimated frame time - safety margin) before starting rendering. Some swap modes have an issue there: estimated time is obviously not computed precisely exact, so with vsync disabled, it could tear near bottom/top of the screen. But with vsync enabled, small overshoot will cause waiting for whole next frame, which is even worse. I don't know how it is named in D3D lingo, but in Vulkan swap mode named "FIFO relaxed" would solve this, as it is essentialy "vsync but not if late", it would prevent bottom tearing and avoid catastrophic whole frame delay during occasional overshoot.

(there's possibility some graphics drivers are trying to do these calculations themselves and are blocking during swap for extra time)

i use Vsync for the only reason i get a line across the screen when not.
and i think you just described in detail exactly what my issue is with that.
a guess i start with. taking off Vsync.

even though MPR dont record it. im still getting massive lagspikes(or looks like lag) when someone joins server leave server go to or come from pit garage. only change is MPR dont record it now.

Quote from Flotch :@Scawen : what I see/feel :
* with vertical synch (60 fps here), I find some disturbing transitions between frames. It feels not so fluid in some parts, more often when going at high speed, but even in the corners of Blackwood it is sometimes a bit weird to me.

this is those "places" on tracks i spoke about some time ago @Scawen.
theres also one if going clockwise on westhill T1. its like the image clutter up or something in these specific areas. and thank you @Flotch for writing this. then i know im not totally off by what i have written earlier.

some months ago i spoke with someone about if multiplayer speed up function, is actually in use today and if so. what exactly does it do? because it seems to have some effect on this somehow. but we never found out if related.
Quote from THE WIZARD DK :i use Vsync for the only reason i get a line across the screen when not.
and i think you just described in detail exactly what my issue is with that.
a guess i start with. taking off Vsync.

even though MPR dont record it. im still getting massive lagspikes(or looks like lag) when someone joins server leave server go to or come from pit garage. only change is MPR dont record it now.



this is those "places" on tracks i spoke about some time ago @Scawen.
theres also one if going clockwise on westhill T1. its like the image clutter up or something in these specific areas. and thank you @Flotch for writing this. then i know im not totally off by what i have written earlier.

Those issues still sound like your computer being too weak for what you're trying to do. If there's a delay when cars join the track, that's resource contension where something needs to get paged in/out of memory and the system needs to wait for this to occur. Same thing if it happens in areas of the track.

Additionally becuase of how vSync work is that if it can't meet the refresh rate, it'll reduce to a fraction of the refresh rate to keep hitting frame timing. Triple buffering can reduce the major frame drops but it adds more imput lag. If you have it enabled and you can't maintain 60 FPS, then it'll drop to 30. If it can't maintain 30, even for a moment, it'll drop even lower.
Quote from gu3st :Those issues still sound like your computer being too weak for what you're trying to do. If there's a delay when cars join the track, that's resource contension where something needs to get paged in/out of memory and the system needs to wait for this to occur. Same thing if it happens in areas of the track.

Additionally becuase of how vSync work is that if it can't meet the refresh rate, it'll reduce to a fraction of the refresh rate to keep hitting frame timing. Triple buffering can reduce the major frame drops but it adds more imput lag. If you have it enabled and you can't maintain 60 FPS, then it'll drop to 30. If it can't maintain 30, even for a moment, it'll drop even lower.

i maintain 60FPS fluently with or without Vsync. ofc More FPS when not.
but in the areas described above in some instances it can drop to 30 fps as you say.
Triple buffering is active for LFS in my card. are you suggesting me to try another setting?
There is 2 versions of my card. mine run with highest rpm. so where do i lag on my card ?
(Danish version)(mine is the TI)i run screen at 1080p.
https://www.nvidia.com/da-dk/geforce/graphics-cards/gtx-1660-ti/
If it's dropping to 30 FPS then you're not able to maintain 60 FPS in those situations. If you were, it wouldn't drop to 30. Additionally, dropping to a divisor of 2, 4 or 8 of refresh rate is a symptom of double buffered vSync.

The settings in nVidia control panel for vSync applies to OpenGL games, not DirectX. DirectX also has some problems with triple buffering in older versions of DirectX, in some cases it's just unsupported and in other cases it creates further input lag or dropped frames. It's also up to the game to support.
Quote from gu3st :If it's dropping to 30 FPS then you're not able to maintain 60 FPS in those situations. If you were, it wouldn't drop to 30. Additionally, dropping to a divisor of 2, 4 or 8 of refresh rate is a symptom of double buffered vSync.

The settings in nVidia control panel for vSync applies to OpenGL games, not DirectX. DirectX also has some problems with triple buffering in older versions of DirectX, in some cases it's just unsupported and in other cases it creates further input lag or dropped frames. It's also up to the game to support.

it drops only sometimes and inside those areas. but otherwise maintains a steady 60fps.
so basically youre saying i can do nothing about that or?
supported : "Microsoft® DirectX® 12 API, Vulkan API, OpenGL 4.6"
Quote from THE WIZARD DK :it drops only sometimes and inside those areas. but otherwise maintains a steady 60fps.
so basically youre saying i can do nothing about that or?

So your PC can't maintain a steady 60 FPS if it drops down to 30 FPS via Vsync in some situations. "Steady except sometimes" means that it's, by definition, not steady.

The texture mods that you are using could be placing additional load or paging on the system, leading to missed frames and frame drops.

A background process could be stealing enough CPU time at the wrong moment to cause frame time to take too long, dropping the frame rate.

Again, it could be possible that for the races you're running, with the settings you're using, the mods that you're using, that your PC is just too weak and can't maintain 60 FPS.

Disabling vsync would help (albeit adding frame tearing) by ensuring that a slow frame doesn't immediately halve the frame rate.
yes true. "sometimes" doesnt mean its steady.
im gonna test this for some time. thank you for the help with this.


EDIT:
switched Vsync of. no ingame limits.
sleep every frame 2.
now i have no line across screen and running it seems steady at around 210FPS at my current place on track.
triple buffering on again.
it seems to have fixed it actually. however im currently in a track with less clutter/loads=AS.
will test on a full BLw server whenever i see one full.currently none is.
2:
i still see a spike whenever someone comes from garage to track or leaves.
however it seems to not affect my steering now.
3:
i am now detecting a clicking background sound whenever /sirens is within hearing range on server.
its the same clicking ,crunchy sound as when using lfs strobe/lagspikes. not sure why i get that now?
wasnt there before switching off Vsync. but very profound now but only when /sirens On.
4.
double checked this now. it occurs both with headphones and with speakers.
it comes in pattern intervals like "click x 3, then pause then 3 again it seems.
not sure what to make of that with all other things said now tbh.
i have no idea how that applies to taking off Vsync. plain confused now.
Wizard, please can you stop talking about this problem with your computer and your install of LFS. It has nothing to do with the test patch and I'm not going to be trying to improve that for you. This thread is for talking about changes in the test patch.
Scawen, about pit stops, could there be added thing to pit stop such as engine repair? But with added option in f12 to enable engine repair on, and depending on damage it would repair it in 20-180seconds. That would really help i think(times to repair choosed randomly it can be diffirent or in made in scale according to damage that engine has).
-
(Pasci) DELETED by Pasci : wrong thread
I don't know if this is related to multiplayer patch currently on going. There was a timerange in MPR when everyone turn into timeout and at the same time all the messages can receive nicely. Start at 7:18. This is the first time I've experienced this. Weird. I raced with U15.
Attached files
what.mpr - 1.8 MB - 11 views
Quote from Pathseeker :Scawen, about pit stops, could there be added thing to pit stop such as engine repair? But with added option in f12 to enable engine repair on, and depending on damage it would repair it in 20-180seconds. That would really help i think(times to repair choosed randomly it can be diffirent or in made in scale according to damage that engine has).

20 seconds engine swap? I'm in.

On the serious note, I kinda like the fact the engine cannot be repaired at all, it makes you run the engine with care in long races, not destroying your car is a vital skill after all.
Quote from michal 1279 :20 seconds engine swap? I'm in.

On the serious note, I kinda like the fact the engine cannot be repaired at all, it makes you run the engine with care in long races, not destroying your car is a vital skill after all.

If damage is 0.01%-0.10% 20sec is kinda fair i think, as in long endurances that damage is pain in ass, and if its like 1% damage its pretty much end of your endurance. So having option to fix it, but with long time to do that would be nice.

EDIT: because other damage fixing as suspension and body doesnt takes long either, just around 6-50seconds, so i dont see much problem to have now engine fixing time not wntirely massive, just in future if pit stop time will be reworked on make it like 10-20minutes engine swap having like 5%-10%+ engine damage.
To be frank, damage repair in LFS is already (too?) quick... Suspension damage only takes a couple of seconds to solve whereas the motorsport mechanics would need a couple of minutes at least (Le Mans style or Verstappen's crew in Hungary last season).
It would be nice to know what kind of damage the engine damage shall represent in the first place, i.e. derive from endurance races how much time the repair would need.
I'd rather see a (maybe even imperfect) real life based metric then some postulated time. If that damage is fixed by component change, then it should be a fixed time rather then a sliding scale for example.

Then again, that would need quite some research, I guess.
I feel like iRacing's damage repair is (for the most part) a bit more reasonable. Hard hits do take likle 30 minutes to fix sometimes. Only part I find "off" is that a 30+ minute repair doesn't leave the car driving well in many cases. You'd think if they rebuilt the suspension or something that they'd have aligned it even a bit correctly.
Test Patch U16. I'm expecting this to be the last compatible patch before the incompatible test.

Interface:

Key control (4/5/6/7) of free view FOV improved and reaches 2 deg
Prevented auto-repeat on block message and light switching keys

InSim:

IS_CPP FOV can now be used in-car but not smoothed (0 = no change)
IS_CPP Pos is now relative to "Centre view" not the user setting
FIX: It was possible to miss IS_PSF packet after taking over car
FIX: STime in IS_PSF packet was wrong after car was taken over
NOTE: for these fixes the new driver taking over must have U16

Misc:

Added a little more logging about D3D initialisation to deb.log

https://www.lfs.net/forum/thread/93185
Its really great that we have these small updates starting to be rolled out that actually make the game better. Only thing left for us is to wait for the official release.
I've just had a quick test of the CPP InSim changes.

FOV works fine, but the custom view still seems to be relative to the user's view file, not the "Centre view" position.
Other than the Pos data etc, I'm using
cpp.InGameCam = VIEW_CUSTOM;
cpp.Flags = ISS_VIEW_OVERRIDE;

Am I missing something?
This thread is closed

Test Patch U16: Updates and fixes
(408 posts, closed, started )
FGED GREDG RDFGDR GSFDG