Hi all! I experience that the steering movements on the screen have a delay of approx. 100ms. I am afraid this is a real delay which shortens the reaction time. Is this normal or can it be improved towards less delay? Probably a stupid question but this delay costs in race time! This problem I have in rfactor1 as well, so not really an rf2-specific issue. Thank you for any info in advance!
Do you have V-sync enabled in either the game or your Video Card settings? If so then that would cause it.
V-sync sets the games frame rate to match the refresh rate of you monitor. It works rather well at eliminating tearing in most cases, but causes input lag(that difference you are seeing between when you turn the wheel and what you see on screen). And in racing games that's exactly what you don't want.
Just to note that vsync doesn't always cause that sort of input latency, for example on my comp there's no discernible difference in input lag with it on vs. off. Some other things to try would be to set "Flip Queue Size" to 0 if you're on an ATI card, nVidia has the same setting with a different name.
Depending on the title I see little or no lag, but by default I keep it disabled. FWIW, I have yet to see any benefit to v-sync, as even if I have it enabled it does almost nothing to reduce tearing or smooth the frame rate. But then again maybe my eyes are getting old
Thank you jubuttib, I always have set it to 1 but now I switched to 0. The initial Problem is solved, thx!
what driver are you using for your wheel.? i have the same wheel, and using the newest driver for the G25/G27 wheel, works great, have been using these drivers for the last 2 years. also in rF2 to save FPS and boost performance a bit, i have the wheel turned off.
I wrote some private notes on this subject a while back. They're not complete, but may help out: Input latency (defined as the time it takes between applying an input on a controller and seeing its results onscreen and/or feeling the results with force feedback) is a major concern for racing simulations. Many things contribute to this latency: controller sampling at the hardware/USB level controller sampling at the software (application) level software processing time (using inputs, calculating physics, generating graphics) buffering video frames (for example triple buffering, Max Pre-Rendered Frames or Flip Queue Size) vertical synchronization (a.k.a. VSync, waiting for the vertical retrace on the monitor to avoid tearing) LCD latencies (buffering plus the time for the pixels to actually light up) in the case of force feedback, both USB delays and motor inertial delays Most of these are accumulative, so one bad apple (like VSync often is) can hurt the simulation experience. A latency of just 40 milliseconds (1/25th of a second) can cause mild confusion and result in a detached driving experience due to the loss of interactivity. Even smaller latencies (10-15 ms) can cause annoying effects like oscillating FFB steering wheels. Modern hardware has generally been designed towards overall throughput rather than latency, so rFactor2 has many features and options that attempt to mitigate these problems. For example, the new multi-threaded design allows fast, consistent input sampling and physics/FFB processing. We have also added various options to reduce VSync latency, and implemented precise synchronization techniques to predict where the vehicle should be when it is actually visible to the user. Here are some recommendations and options to reduce input latency: Buy a modern steering wheel or find a way to tweak the USB sampling rate of your device. Older wheels may only be sampled at 125Hz (adding up to 8 milliseconds of latency) while newer wheels tend to be sampled at at least 500Hz (no more than 2 milliseconds of added latency). Take a look at the "CPU Time" graph while driving. The purple histogram shows how "late" the physics loop ran in milliseconds. Ideally, the samples should stay in the left-most two columns, although a few occasional blips up to around 10 milliseconds do not usually indicate a serious problem. If you are consistently getting late physics, though, one must look into the causes - do you have too many external apps running? Do you need to bump up the thread priority with the command-line options +SimThreadPrio? Are you running some overly expensive mod physics? Do you need more CPU power? For your video card, lower the control panel variable "Max Pre-Rendered Frames" or "Flip Queue Size" (if available). For SLI mode, set it to the number of video cards, otherwise set it to 1. Setting this value to 0 tends to cause problems, it is not recommended. If you insist on running VSync, you just need to accept that you are adding *at least* 17 milliseconds of latency, often much more due to apparent driver bugs (this is all assuming 60Hz displays - we can't wait for 120-240Hz!). You will not be able to drive as well, but at least the tearing will be eliminated! Besides contacting your favorite video card manufacturer and demanding that they reduce latency with VSync, what else can you do? Check out the PLR file options and try various combinations to see what works best for you: Flush Previous Frame, Render Once Per VSync, Delay Video Swap, Max Framerate (and its corresponding Steady Framerate Thresh). Tune the prediction variable(s) (TO DO: MORE INFO). Some LCD monitors have a way to bypass internal processing, something on the display's on-screen menus like "1:1 Pixel Ratio" or "Game Mode". This can reduce latency in the LCD display.
