Well now i have been enjoying the new improved performance, and with the new frame graph something just seem so obvious now.
And that is the answer to this Q?:
Why is it I can reduce quality options and resolution and get 6-700 FPS!! and when i put on V-sync i still get temporal randomly stuttering??
Well with the new frame graph when (display refresh rate@50HZ) it is showing every frame with 2 physics calculations until stutter begins then there could be one frame with one physics cal and next have 3 cals and so on randomly.
I am pretty sure it is the physics clock and display refresh rate going of sync for a moment. And when looking at picture with v.sync off and LFS FPS limit to 50 FPS i can see one screen tear relative steady but moving slowly up or down representing the two clocks difference. And i can also see that there is a fast jitter in the tear position of 20-30 pixels up and down representing the the jitter between the two clocks.
Now.. whenever this screen tear(with v-syn off) is in the middle of the screen and i turn on v-sync, everything is perfectly smooth always. But if the screen tear(with v-sync off) is at the upper or lower end of the screen and i turn on v-sync i get a terrible stutter, which make sense because the Frames change fast from 1,2 and 3 physics cal per frame because of the clocks "edges" overtake each other randomly. I hope you understand what i mean :-).
And what use is High frame rates when frames come randomly with bad timing(stutter) which ruin the illusion of the virtual world?
So, my idea or question to you Scawen: Why not sync the physics clock to the Refresh clock when v.sync is on
And sorry if my lack of insight make you feel tired of getting this question
It "just" need to micro(0,01Hz) adjust the physic clock to keep sync steady and aligned so the jitter between the clocks don't generate the stuttering. Its not like the physics clock is(or need to be) more precise than the refresh rate is it? This would be a major improvement in smoothness/anti-stutter without screen tear at all refresh rates and HW without having to make a complete "resample/interpolation" implementation.
I made this table just to see how often the Physics clock could be synchronized with different refresh rates
Refresh rate(HZ) ,number of Phys between sync, number of frames between sync
50Hz ,2 phys calcs between sync ,1 frames between sync
60Hz ,5 phys calcs between sync ,3 frames between sync
75Hz ,4 phys calcs between sync ,3 frames between sync
90Hz ,10 phys calcs between sync ,9 frames between sync
100Hz ,1 phys calcs between sync ,1 frames between sync
120Hz ,5 phys calcs between sync ,6 frames between sync
Of cause micro stutter at anything else than 50 and 100Hz will still occur but, it is really not as big a problem as the other stutter, created by the jitter and off sync clocks, is imo.
You probably have a good reason why its not already in-sync, and maybe it has already been tried but found not possible. I just wanted to know if this idea have been considered? Also now when you have made this frame info graph which seems to have all the info needed to update a physics clock to be in sync with refresh rate. I could be wrong