Smooth 179 FPS and very low input lag (but in expense of details)

I see lag when change wheel rotation to 900 degrees instead vehicle setup (470). But i think this only visual.

 

It's exactly what input lag does (sync is set to video = vsync). You turn in when you've reached the right spot shown on the screen. However your car inside the game engine is not at that spot - it has travelled further. If your speedometer shows 250 km/h and input lag is 100 ms then your car is actually 7 meters farther than what is shown on screen - and you have already missed the turning point.

 

I'd love to be able to run without vsync but it's just to damn choppy even at 150 FPS.

 

Yep I think so too. 180 FPS at 60 Hz is minimum for it to start look smooth and to reduce tearing enough. Powerful harware is needed in rF2's current state.

 

What about the real input lag to controls. I've found that I can live with the visual lag if it's less than the 16.7ms @ 60hz.

But what really is important is how quickly the controls/ffb responds? Doesn't the simulation itself run at way higher refresh ratio? What I mean is that I'd think input lag andvisual lag shouldn't be married. And I thought that nowadays they aren't.

Very nice thread btw. Thank you!

 

hello! I tried this and same settings that you post and I reduced input lag because I was using video sync (too look smooth) and notice that the graph (using ctrl+c) before was always full, green and purple 100%, and now both are like 25%.
what does that graph means? and how to see input lag in ms? thanks

 

Few threads from the past:

http://isiforums.net/f/showthread.p...cy-to-lock-max-frames-to-(or-multiples-of-60)
http://isiforums.net/f/showthread.php/5350-FFB-Frequency

So it looks like both physics and controls operate at 400 Hz (I think theoretical lag is 2,5 ms).

 

I think those bars mean how much game is utilizing GPU (green) and CPU (purple). I believe little spikes represent lag - more to the right means more lag. Haven't seen so little "GPU lag" before (see image below) and maybe it proves I'm having very little input lag nowadays.

I don't think input lag can be shown accurately on screen. You would need high-speed video camera and some program to observe difference between real wheel and wheel on screen. Milliseconds in my images on first posting are just theoretical estimates.

View attachment 5132

 

The green spikes are distribution of framerate, more to the left means higher fps, more to the right means less fps. Ideally you want to see a single tall spike which means consistent framerate but you'll only see that when you cap your fps (and use settings that ensure you don't drop below that cap of course).

 

Hmm, think you're right and I was wrong. Input lag is tied to FPS when sync is not used so that spike also kind of represents input lag but that's just a side effect.

 

I find changing framerate most disturbing, so I have capped my framerate and tuned graphics so that I bars are not going to max length, I indeed have single tall bar as you mention.

I thought that green was CPU's graphic thread, but now I'm not sure at all, anyway if purple bar goes to full length, then sim drops out of realtime and that is bad, so always have some reserve there, also good to have some reserve for green bar too, but one gets that indeed only when framerate is capped and details adjusted accordingly.

 

I don't doubt anything that is said here as far as advantages of faster fps. But getting 179 fps is such an impossible feat for me (and I'm sure many others) that the goal is just a fantasy. I put everything at absolute min (low or off) and can only get 135 at LRP with a grid of 8 AI. And I doubt there is that much "optimization" possible. I must say that the "feel" "seems" smoother at 135 fps but god is it ugly to look at!

 

+1

 

It is a compromise we need to make. Make it look as nice as possible with as high fps as possible, without there being alot of fluctuation in fps, that is truly the worst enemy when it comes to the feeling of smoothness.

When talking about very high fps and input lag, it is obvious that those two correlate with eachother (first person shooters like counterstrike are great examples) but there is alot of factors that can render one useless even when they have achieved high frame rate.
Netcode can alter all this when going online racing and there is more than input lag issue from your pc or monitor to worry about after that.

Ideally high frame rates, low input lag display (dont confuse this to pixel response time) and high frequency wheel in single player/lan race, will provide the best and smoothest experience with the lowest possible input lag, but all this equipment can have a steep price especially when you add pretty to the picture. Often it is more than alot of us can/are willing to invest, so make it good for you with the equipment and funds you have or are willing to aquire.
Take advice/information, apply it in practise and see what does it do to your racing experience.

 

180 is a pipe dream in rFactor right now for me (running eyefinity). Frame rate fluctuation has never been an issue when I run at iRacing either, but sure is here.

 

Hopefully some major optimisation are going to start , a good fps performance is essential in a racing sim

(we can only turn resolution & details down so much )

 

So all this KeiKei is still valid with 2 or 3 graphic-cards in SLI or CrossFireX?

 

Sorry don't have experience on SLI or CrossFire. Hopefully someone would make experiments on those cards too and report back observations.

 

Have you tried just limiting FPS in PLR-file? I have mine at 60 with "flush previous frame" set to "1" and it's actually silky smooth without v-sync. For some reason I get less tearing this way than with GPU-sync. (amd 7970, triple screen)

 

I had tried limiting it before, but will give it another go now that I am also running a 7970. Thanks for the tip.