I tested this ON SO1+FZR and UF1. Same thing happened: I also encountered that same thing if you adjust camber settings instead in those cars. It also happens if you adjust back tires.
However this is where it gets interesting: if you change tyre type, or wing in FZR's case, it works properly. But if you adjust camber and/or tyre pressure at the same time, that bug still happens.
And I also noticed one more confusing thing and one more actual bug:
1) If I decide to change my both front and rear tires type, it's still possible to have that F12-option Tyre change as never. I understand that option can be set to "never", if you don't decide to change all tires. It's just confusing that it says "never" even if you decide to change tyre type on all wheels. Of course, it does change your tires if you change tyre type regardless of tyre wear.
So in case you decide to change tyre type to all wheels, should that option then automatically be: Tyre change : "always"?
I attached a screenshot about this.
2) Actual bug, happened at least on FZR. How to reproduce this:
1) Adjust your rear tires tyre pressure to the lowest possible (for example, if you're using FZR, adjust it to 0.70)
2) Do a pit stop.
3) After that pit stop, you can see that on F12-window, tyre pressure is correct, but it still says that change is -0.10 bar at rear tires compared to current setups. I attached a screenshot about this.
Regarding F12 menu and pitstop settings I have an improvement suggestion:
Once you accidentally switch from assymetric to symetric,you can't turn back so easily. I mean you can turn back to assymetric,but the settings all are now symetric and you have to adjust them manually back - it's quite difficult when racing on track and who can remember all the settings anyway?
So the suggestion is that either switching back to assymetric it should return to previous settings or there should be some way to cancel requested setup changes.
I've added this to my notes file for the compatible patch.
Thanks for the tests.
That FZR bug is one of the things I fixed yesterday, linked to by MandulAA above.
Thanks but I don't want to tackle that, as there is bug potential and complication there. Actually I'm just trying to stay sane while trying to get the compatible fixes done so I can get back to the incompatible fixes so I can release version V so I can get back to the development version and try to finish the graphics so I can get back to the tyre physics.
A quick fix for the auto-repeat - I've enabled it again for all keys by default so it is as before. But it can be disabled on any particular function with a single line of code.
I know at least one function in the development version where I would disable it. But I haven't thought of any in the public version. Please do tell me if there is anywhere that auto-repeat can cause unexpected, confusing, annoying or otherwise bad issues, and I'll disable it on that key.
OK, some more updates in U15. Still a compatible version.
F12 pit instructions:
Pressure change with new tyre no longer counts as SETUP CHANGES
A new 'cancel' option beside the 'setup changes requested' line
Settings that will be adjusted are now shown in light red colour
FIX: rear tyre pressure was limited by front tyre pressure limits
FIX: symmetric pressure/camber request remained after pit stop
More accurate transmission of fuel load from local to remote car
Remote car fuel load is now shown in F12 if /showfuel is enabled
Rolling resistance included in catch-up phase of prediction
FIX: Remote cars with worn tread could wrongly get a puncture
Auto-repeat key function reinstated (disabled in previous test)
MPR / SPR are now prevented from being named temp_mpr / temp_spr
Free view mode minimum field of view reduced from 10 to 2 degrees
InSim NLP / MCI minimum time interval reduced to 10 ms (was 40 ms)
Mouse X and Y sensitivity (in Axes tab) lower limit reduced to 0.5
FIX: Message MPR_BLANK sometimes displayed when watching live MPR
I’m not sure if this is caused by button-repeat or some issue with latency, but sometimes online I’ll accidentally hit the block messages key, and it quickly blocks and unblocks messages. But the server will only display the “blocked messages “ message. So I’ll hit it again to unblock messages and it displays that I blocked messages again. And finally a third time to unblock messages. So server output looks like:
I just made a quick test on Blackwood for this feature :
While driving alone, if I limit the frame rate at 250, I can see the sleep value at around 70.
If I do not put a limit, I am reaching 1200-1300 fps, but this time the sleep is around 0 => I can see a core going at 100% of cpu usage (single core app behaviour I suppose)
If I use a full AI grid without limiting fps, I can see them dropping to 300-350 while the cars are present (a lot more if you are "alone" in your field of view).
The Draw is almost always identical I would say, in my case ~70 when not limiting fps. Physics is going to 15-20 with the full grid of AI, and almost 0 when alone.
How is this working : does more sleep mean more cpu "free" time ? is it the same for physics value ? if so why would 31 AI with you cost less less cpu for physics than when alone ? Or is it a display showing the average consumption between each part (the sum is close to 100 each time) : physics, draw, etc... and the "free time" (sleep) ? I tend to suppose it is the last one...
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 ( ) 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 , it ease a lot the cpu consumption for a given result in the end.
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.
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.
@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
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)
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.
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.
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.