A couple of quick tests (all in windowed mode for now):
I get the freeze whether frame limit is set or not. (Very rare if no limit. I can't actually reproduce it anymore with no limit, so I may have messed up a setting). Doesn't seem to happen if I set a 200fps limit (getting ~170fps).
While the freeze is occurring, CPU usage is zero.
The freeze length seems to be quite variable - anywhere from unnoticeable, to long enough for windows to think LFS has stopped responding briefly.
Just noticed that in windowed mode LFS doesn't limit FPS to 60 while v-sync is ON, as indicated by in-game FPS counter in the top corner. Instead it uses FPS limiter option right bellow v-sync. Once I shift+f4 back to full screen it goes back to normal.
Couldn't tell if it was just an error in FPS counter display or v-sync was really not working as I couldn't notice any screen tearing during my short test.
I'm unable to test exactly which patch changed this, only that it happened somewhere in between G3 and H4. Somehow I keep forgetting to backup full patch exes. OS is Win7; GPU drivers are set to application preference.
I may have read something about this before so my apologies if it has already been discussed and explained.
That has never changed. The clue is in the name of the option: "Full screen vertical sync".
In DirectX 8.1 it was not possible to have vertical sync in a window. It is possible in DirectX 9 but I have not implemented it. As it has been this way for a long time some things depend on it being this way. It's just a matter of sorting out all the logic for it, considering all the situations, and adding a "Windowed vertical sync" option but this tedious task has not reached the top of my daily joy list.
Which version of Windows are you using? Mankan and Flame who also reported this are using Windows 10.
To be clear for anyone else reading, this is about a freeze entering the pits when you are in game (in single player or multiplayer) and there are no cars on track and you press SHIFT+P.
The only explanation I can think of, by reading the code, is that the Windows Sleep command isn't giving up the right number of milliseconds of time. So for example Sleep(2) only gives a 1 ms delay.
...TESTING...
I have reproduced this now in Windows 7, by calling Sleep(sleep_time - 1) instead of Sleep(sleep_time) in the frame rate limitation function.
I also get a pause when clicking the left arrow in the Maximum frame rate button. This pause is related to moving to a lower frame rate limit. In that case LFS never thinks the target time has been reached, so doesn't reset the timing frame counter. The pits screen has the same limited frame rate as the game setup screen. I also get the lag in my modified version when exiting to the game setup screen.
My code relies on the Sleep(x) command actually taking x ms to complete. I am quite sure now that this is not the case with Windows 10. For some reason the Sleep command gives up less CPU time than requested. My code needs to be made more robust to deal with this situation, but it seems to be an interesting bug / feature of Windows 10.
EDIT: One more question for you, at the start of deb.log what timer resolution do you have?
Aug 06 15:11:12 timer resolution 1 ms
I'm still on Win8.1 64bit - I haven't got W10 on here yet.
I *might* be able to test with W10 on my old laptop, but the GPU probably hasn't got enough grunt to exceed the frame limiter.
Aug 06 19:46:09 preinit d3d
Aug 06 19:46:09 started Direct3D 9
I guess there is no DX9Ex in Win10 then ...
Still if you keep 100Hz physics even with separate threads this problem persists. Graphical frames wouldn't have continuous time step (camera move).
There are 75, 100Hz, 144Hz monitors... Solution should be universal for all refresh rates.
Another issue is time step in 120 Hz physics. Current 100Hz physics relates to 0.01s time precision on splits. 120Hz physics would have 8.333ms time step, how to handle this because 10!=8.333 ? There isn't any interpolation in LFS ATM.
Quickly measured time to complete Sleep(1); using high performance timers.
Minimum=1.00861ms
Average=2.02136ms
Maximum=6.17521ms
I also tested on my pc with win7 x64 and win10 x64 and I was unable to reproduce the delay problem on windows 7, but on windows 10 I've experienced the same issue, the higher I set the fps limit, the more delay I get (sometimes around 3-4 seconds, or even more). According to deb.log, timer resolution is 1ms on both systems.
Well that would be consistent with the Windows API docs (sleeps for at least what you request, with a caveat about timer-tick resolution). What Scawen has observed is weird and inconsistent with the docs.
I'm a bit puzzled though that a shorter-than-expected sleep leads to a long pause
This afternoon I changed it so that after any Sleep, it makes sure that the required time has elapsed and if necessary it keeps calling Sleep until the required number of milliseconds have elapsed. It does solve the problem when I simulate the bug.
That is surprising!
It means that either LFS could not find the function "Direct3DCreate9Ex" in the D3D9.dll or it could find it but calling it failed.
I think it is possible to produce graphical frames smoothly interpolated between the 100 Hz physics frames, by interpolating camera positions and the positions / rotations of all objects. But I agree that it would be easier to use 1000 Hz frames and choose a frame to display without interpolation.
Do you get that lag bug that Flame first reported?
EDIT: Also it might be interesting to time Sleep(X) where X is greater than 1.
It's a bit complicated to explain, I'd have to upload the algorithm. But the way the bug appears is it fails to hit the target frame, so it builds up a large number of "frames since timing started". Without the bug, this goes back to zero every few frames because it keeps succeeding in hitting the target. But with the bug, it builds up a lot and when the "required frame time" is increased to X then X * "many frames since timing started" is a big number and it does a long Sleep at that point.
All these monitor would be able to run 60Hz and a gamer 144Hz monitor would be able to put out 120Hz. And the frame timing jitter would be 1,66ms less on all systems ;-)
Ofcause it would not be a backward compatible solution and therefore out of scope for now(until new physics maybe). But i cant see why 8.333ms step should be any different from 10ms to handle? I can't be sure because i don't know how the physics timing is implemented, but i think maybe it is using highperformance timing which have much better resolution than 1ms. It could be based on QueryPerformanceFrequency and QueryPerformanceCounter calls which usually have better than ~500ns resolution or the intrinsic instruction RDTSCP which have the resolution of your CPU clock(theoretically a 3GHz would have 333,333ps resolution), and we all know how bad sleep(x) timing is so i am pretty sure thats not how physics is timed else we would have way more problems with frame timing, i think
Usually Sleep(1) take less than 1ms typically 0,98ish ms if i recall correctly. maybe you forgot to take your performance timers calls overhead into account??
And it is commonly known that it is not wise to use Sleep() in critical timing because it is only a "wish" to the system that it is ok for your code the system handle other stuff for x number of milliseconds.
But never mind that i would just be happy if LFS could accept the Refresh rate of 50Hz in full screen mode. It is like there is some kind of display dependent limit of the Refresh rate range in LFS. ex. my monitor can be set successfully in windows desktop between 50Hz and 68Hz in custom mode, but LFS only display the range 56Hz to 68Hz to select from. And another Monitor and PC i have tried i can set it in windows to 41Hz to 62Hz an in LFS i only get the range 50Hz to 60Hz i really dont get why it should not show the whole range supported by the driver? I could understand it if it just did not support custom rates but that is obviously not the case
And can i just say: anybody who thinks that 60Hz display refresh rate is better than 50Hz for LFS because 60Hz is higher than 50Hz, should really try to see the difference with your own eyes. and remember you have a ~20Hz micro jitter which your eye can detect easily when things are moving/scrolling steady, or by looking at the wheels spokes not spreading evenly when turning fast. Running LFS at 50Hz is as smooth as having G-sync/free-sync@~50FPS. Only problem is that eventually you can get a 10ms time jump, but at least you dont get it as often as with 60Hz.
And sorry if i am on the edge of topic, but it is these very cool new things like improved FPS and Frame graph that has made it possible to get these smooth frames on my system, and it is really cool and addictive
My monitor doesn't present any 50 Hz resolutions on my system, but I can add custom resolutions with the nVidia control panel which LFS picks up fine.
Here's a video demonstration the difference between 50 Hz and 60 Hz in LFS, made by taking two recordings and changing the frame rate to 30 Hz for both to make the difference more visible. For me at least, the video playback in Firefox tended to stutter slightly, ruining the effectiveness of the demo, but Chrome played it smoothly so that you can see the difference.
Oh, and if you think it's annoying having to use a multiple or fraction of 100, I have a tank sim, Steel Beasts, that wants to run at 62.5 FPS!
Regarding physics calculations resolution and frame rates, I heard that today's games usually use up to 500Hz physics clock and yet they do use interpolation technique.
I also used nVidia control panel to make a custom resolution. My issue is that LFS dont accept the same range of refresh rates as Windows ;-) on my work laptop i can also make and choose down to 50Hz but not on my privat stationary(which is the PC I use for LFS.) I can make it allright but not choose it in LFS if it is below 56Hz
Ha ha i just had som problems with playback smoothness of this video because my monitor was set to 50Hz. But now i have seen it in 60Hz and the every 3rd frame time jump is very much visible at 60Hz, and thats what i mean is very much noticeable realtime also. at least you notice the big difference when the jitter is gone at 50Hz.
Could you do this video test with the new frame graph on so it would be visible when the 10ms time jumps occur? Time jumps would be visible in the physics graph as changes in thickness.
Ah, I hadn't seen that new graph! This time I dropped the frame rate down to 15 fps to make it more visible, and also included a 100 fps sample. Also, I recorded this with vsync and the frame rate limiter both off in LFS and used my capture software (Dxtory) to synchronize the display frame rate with the recording frame rate. Oh, and this was the AI driving each run new, not from a replay.
this is a great demo of the benefits of display being in sync with physics, even if you need to go down in FPS to be in sync. But the graphs dont show the minor problems in 50/100Hz that would show in real life situation because of physics is not 100% in sync like it is here on your captured video.
I have no idea why the 50 Hz modes is not displaying in LFS on your computer. LFS doesn't filter out modes unless their size is less than 640x480. All refresh rates reported by DirectX are listed for you to select. And some people reported they can see 50 Hz modes in LFS. There must be something different on your computer or the method you are using to create extra modes.
OK that got me thinking, and did som quick testing of Directx samples from the MSDirectxSDK and it looks like all Directx10 samples and up report the 50Hz on my system and all the Directx9 samples only report the same as LFS
Wonder why but this remove LFS as a suspect to that problem
Odd. I'm using Windows 7 with the 353.62 nVidia drivers and a GTX 760. I tried custom resolutions at 1280x720 and it displayed 50, 60 and 75 Hz all just fine. However, at 1920x1080 only 50 and 60 showed up, 70 Hz wasn't on the list.
Yes but apparently there is difference between Directx9 and 10, but it could be the nVidia driver making that difference or maybe it something in Dx9 that is not supported
With this i could add/mod a "Detailed resolution" to my Display driver directly in the regdatabase :-) and after a display restart(use restart.exe in the zip), 50Hz is now available in LFS :-) Its fantastic and the new graph made this very easy to adjust frame rate which can be set with hi resolution in CRU.exe ex. 50.005Hz. if you want to get closer to sync or deliberately slightly out of sync to avoid the jitter between Physics clock and refresh rate to make more than one frame timing error jump when "passing" the critical point. like if i set my monitor to 50,1Hz i will get that 10ms time jump once every ~4 seconds, which is hardly noticeable compared to 60Hz which does it once every ~3 frames.
ATM is simply checks if checkpoint has been crossed in last physics update.
These timers have nothing to do with LFS time. They are mostly only used to measure time needed to complete some tasks (parts of code).
None of my tests confirmed that ... Yesterdays tests were done in other Project which run tenths of other threads very light in fact, but I'm sure it had some effect on final results. Todays results are even better. Overhead is really low in this case as you can see in table below. 1000 samples for each.
Actually it does. Just few days ago I installed XP on other hard drive and I couldn't set my native resolution (1920x1080@60Hz) so I made custom monitor driver using a program PowerStrip to enable this mode, but I wouldn't recommoend using it unless you really know what are you doing.
BTW Scawen, now that our FPS increased so much I guess we are ready for some decrease (read: graphics improvements)
.) I can make it allright but not choose it in LFS if it is below 56Hz
