I think it's a misconception that there is "1:1" feedback available, unless you want to break the attachment from the steering wheel > steering column > steering arms > spindles > wheels (which would be even more confusing). Also, the update per drawn frame is an average of ~12 physics ticks, so it's essentially always going to function as a kind of histogram of input totalled throughout that frame.
Update 1.02 DID NOT fix the input lag [UPDATE 5]
- Thread starter Sier_Pinski
- 134 comments
- 17,209 views
- 1,116
- Gassolini
^ Not sure what you mean by "break the attachment" there. Anyway, the physics engine running at a high rate obviously needs to interpolate steering input when/if the input is read at a lower rate. But that is still happening at a rate that is quite fast in relation the lag that we perceive - the reasons for this has been partly explained by Griff (frame buffer pipeline, threads interaction, filtering).
What I see as a paradox is that even with ever faster hardware and presumably more developer experience, we're seeing worse performance in some areas than has been achieved previously. As a software developer I have some thoughts on that, but this is not the thread for that...
DJ
--
What I see as a paradox is that even with ever faster hardware and presumably more developer experience, we're seeing worse performance in some areas than has been achieved previously. As a software developer I have some thoughts on that, but this is not the thread for that...
DJ
--
- 146
- Spain
- TechnobearRacing
- TheTechnobear
.
Last edited:
- 523
- shoeface33
Im glad that this wasnt just me that noticed this. Got this game today and got really annoyed due to slow steering and inconsistency with steering speeds. Hopefully more updates will improve gameplay 
///M-Spec
Staff Emeritus
- 4,928
Gentlemen. Some of you need a reminder on how to get your message across without hurling insults; actual or implied.
Some of the work being done in this thread is useful. Don't change that with petty OT bickering. I haven't had to give an infraction in a long time, so please don't make me familiarize myself with how to do it.
M
Some of the work being done in this thread is useful. Don't change that with petty OT bickering. I haven't had to give an infraction in a long time, so please don't make me familiarize myself with how to do it.
M
pgagoober
Site Sponsor
- 415
- AZ
- BadManTurismo
Point taken M-Spec. It's done.
Back on topic, I just completed the new video. You can see it here :
There are two clear input and direction changes in there. I measured the first one at 14 frames and the second at 13 frames, so let's call it 13 frames. At 30fps that comes out to 433ms +/- some margin of error. I also took another video with more attempts but it the lighting was poor so I went back and made the one published above. The first video showed the same results.
This result was as expected and shows that patch 1.02 definitely made some progress in this area. Fingers crossed for 1.03....
Hi there,
Just want to add my input on this, as I'm doing tests about shift2 latency for a while now (and posting the results for a while too, at EA forum and at nogrip in Griff post).
I've also came to the conclusion the best test is the car reaction time (direction change) to steering input, at a low speed, and that's what I've done. Ingame steering wheel display delay, or car's wheels display delay are irrelevant as the car can still react way after the wheels direction change is displayed.
Car's direction change mean the info (controller input) have passed through the physic engine (and through the 3D / display area too). And that's why we are intersted in, and nothing else. We want to know how long it take between our actions and reaction displayed on our monitor.
At low speed, tyres grip won't add latency as we'll have close to 100% grip. Suspensions load won't add any latency to the visible direction change as we can't have any lateral weight transfer without a direction change. The only latency from the physic will come from the tyre contact patch not following the wheel direction change at the exact same speed. There's a small delay (very small imho).
So, here are the results of my last tests. Those have been done using video recording @60fps, game running above 70fps (vsync off), screen (crt) refreshed @85hz, then the analysis is done frame by frame. The car is moving at 6mph max and I move my st. wheel as fast as possible to get precise measures (I even skip the 2 first frames of the st. wheel movement when I do the frame by frame video analysis, whilst I take the slightest 1st car direction change as the reference for car's reaction. So believe me, there's 100% chance my results under-estimate the real latency). All tests are repeated at least 5 times and measures averaged (last tests even were repeated 10+ times)
Post patch1 tests:
Win7 flip queue size @default (car's direction change at 6mph max, M3 E30): 231ms
Win7 flip queue size @default (car's direction change at 6mph max, Lotus Exige, race suspensions set the stiffest and semi slick tyres): 228ms
Win7 flip queue size @ 1 (car's direction change at 6mph max): 234ms
WinXP (car's direction change at 6mph max): 220ms
Win7 (ingame st. wheel): 160ms
Win7 (telemetry): 130ms
Some other tests:
driver CP / dxtweak2: 56ms
Test drive unlimited 1 (ingame st. wheel): 100ms
F1 2010 (ingame st. wheel): 83ms
Dirt2 (ingame st. wheel): 100ms
Shift2 vanilla (ingame st. wheel): 200ms
Shift2 vanilla (ingame st. wheel, friend's video): 200ms
Test drive unlimited 1 (telemetry): 97ms
Shift2 vanilla (telemetry): 136ms
Shift2 vanilla (car's direction change at 6mph max): 283ms (test done with patched game but 1.0.0.0 exe)
Shift2 vanilla (high speed direction change, friend's video): 500ms
Values in blue have +/- 33.4ms error margin
Values in red have +/- 16.7ms error margin
(discovered later my camera could do 60fps capture. So in red are tests done @60fps, blue 30fps)
One of my video test can be downloaded here:
test 1a - test 1b (approx. 70MB each). This was the post patch1 test under win7 with flip queue size to 1.
At the present day, I tend to think everybody has more or less this amount of latency (on PC). People only "saying they feel no lag" aren't proving anything. I'll believe someone saying he has no abnormal latency when I see a carefuly made video showing he has no abnormal latency, and it hasn't happened yet (but it happened that some people told me they had no latency, and when they gave me the video it was showing the same latency as in my personal tests).
I plan to do the car reactivity to steering @low speed test with other games like TDU1, F1 2010 and Dirt2, and with a real car if I manage to do it properly.
If latency was reduced more, I bet most people saying they "don't feel any input latency post patch1" would say the gameplay would be vastly improved.
Lag or no lag, it's a moot point. S2U is a blast!
The same already happened with patch1. Many people were claiming they didn't have latency with the vanilla game, but when they applied patch1 which reduced latency a bit they said the gameplay was completely different now, that it was like if it was another game with a much more precise car handling than with the vanilla game.
230ms before your car starts turning after you have started turning your st. wheel (or pushing your stick) is huge. Look at my video how deseperating it is to see the steering wheel doing such a large movement with the car continuing to go straight for 14 images long !
We don't see the full st. wheel in my videos as I make the capture as close as possible to the st. wheel for the best measuring accuracy. But with the acceleration you can see on the 3-4 first images until the yellow line of my wheel goes off screen you can imagine how much the st. wheel is turned when the car finally starts reacting to your input. With no doubt the st. wheel will have turned between 1/8 and 1/4 of a full rotation before the car starts reacting. That's huge.
Believe me, if it was reduced by 100ms you would have a completely different handling again. It would be that much precise you would wonder how you were able to play before. Also certainly many hardcore simmers claiming shift2 is an arcade game would rethink their opinion.
- 1,116
- Gassolini
@ VolCoMx_x : It has nothing to do with dead zones. And it has nothing to do with the propagation speed of electrical current in copper wire, which is typically around 2/3 the speed of light 
@ tribolik : Other games have significantly less lag, so I think we can safely rule out hardware problems.
(I had typed up an explanation with a concise estimate of what is technically possible, but this issue appears to be so contentious that it feels more than futile to publish it)
DJ
--
@ tribolik : Other games have significantly less lag, so I think we can safely rule out hardware problems.
(I had typed up an explanation with a concise estimate of what is technically possible, but this issue appears to be so contentious that it feels more than futile to publish it)
DJ
--
VolCoMx_x & Minnesota, iirc electricity travels @ more than 90% the speed of light (edit: aww DrJustice said 2/3, let's take 2/3 
That's still way fast enough considering the distance the signal has to travel 
). The latency doesn't come from the time the signal takes to travel through wires. Most of the latency is due to buffers, refresh rates, calculations times etc.
Look at my tests results on page 5: driver CP or dxtweak take 56ms to display your input. This is from physical input on the controller to visible result on screen, thus including signal travel time, USB refresh, bufferings, display latency etc.
If we look at shift2 delay to display input with the telemetry or the ingame st. wheel it adds 70 to 100ms to this time, when F1 2010 manage to add only 25ms.
Of course this is not really relevant as what import the most is car's reaction time, but ingame st. wheel taking twice the time in shift2 than it does in F1 2010 is ominous I think.
We'll have a clearer view on this when the car's reaction time test is done with other games. Then, there will be no doubt if shift2 has room for improving latency or not.
But if we take 56ms as the absolute best reaction time obtainable, then we have:
- a game running above 70 fps -> one refresh every 14.3ms
- a physics engine refreshed at 400hz -> one refresh every 2.5ms
We have to take twice those values, because when the "signal" (info) reaches a given point, let say 3D refresh for example, if this refresh just began the signal will be delayed by 1 refresh (the one which just started when the info arrived) + another refresh after the info finally was able to enter the loop.
So we have (14.3+2.5)x2 = 33.6ms as the worst case concerning the part of the total latency due to 3D and physics refresh.
Even if we double this again to take into account other parts of the code we would have: 56+ 33.6x2 = 123ms. And shift2 cars take 230ms to react to actions on the controller...
What does the game do during those 125ms delta ? That's more than 7x the times needed for 1 complete 3D refresh (@70fps) + 1 complete physic refresh.
Any buffer latency, signal travel time, display lag, haven't to be taken into account as they already are also present in the 56ms for the driver CP / dxtweak test. The 125ms delta can only come from the game itself imo.
Bad news is many people doesn't mind / notice the latency. And most of the money from games sales is done during the first few weeks after release. So there is no doubt EA doesn't care much about fixing this.
The only chance we have is that Griff said at nogrip SMS was willing to support the game with a few more patches because they own the technology. Thus improving it now is not a pure loss of time for them, as they will re-use this tech in their next racing games.
So let keep fingers crossed, and if all people here noticing latency could voice it at nogrip in Griff thread it will certainly help to convince him that SMS should look at it to try to improve it. Atm, he only has theorical figures about shift2 latency. That's why I'm posting my test results in his thread as I'm certain SMS haven't done that kind of test to check their game latency. But if I'm alone complaining about this at nogrip Griff will certainly don't care about it, even if I come with valid proofs.
For patch2 they have spent time to add a new graphic detail level, which will no doubt benefit a few players only, with very high end PC... Is it really what was the most important for a racing game ? (and especially one suffering a high input latency !)
So, if you are annoyed by shift2 latency, on PC or console, voice it at nogrip in Griff post !
I like this game, but as some people here I think we are missing a lot of its potential due to latency
Btw ISR shift2 final review, which was done with patch1 applied, also agreed latency was still there and that is was too high. That the player doesn't feel the tyres being connected to the road as irl on in other simulations.
That's still way fast enough considering the distance the signal has to travel ). The latency doesn't come from the time the signal takes to travel through wires. Most of the latency is due to buffers, refresh rates, calculations times etc.Look at my tests results on page 5: driver CP or dxtweak take 56ms to display your input. This is from physical input on the controller to visible result on screen, thus including signal travel time, USB refresh, bufferings, display latency etc.
If we look at shift2 delay to display input with the telemetry or the ingame st. wheel it adds 70 to 100ms to this time, when F1 2010 manage to add only 25ms.
Of course this is not really relevant as what import the most is car's reaction time, but ingame st. wheel taking twice the time in shift2 than it does in F1 2010 is ominous I think.
We'll have a clearer view on this when the car's reaction time test is done with other games. Then, there will be no doubt if shift2 has room for improving latency or not.
But if we take 56ms as the absolute best reaction time obtainable, then we have:
- a game running above 70 fps -> one refresh every 14.3ms
- a physics engine refreshed at 400hz -> one refresh every 2.5ms
We have to take twice those values, because when the "signal" (info) reaches a given point, let say 3D refresh for example, if this refresh just began the signal will be delayed by 1 refresh (the one which just started when the info arrived) + another refresh after the info finally was able to enter the loop.
So we have (14.3+2.5)x2 = 33.6ms as the worst case concerning the part of the total latency due to 3D and physics refresh.
Even if we double this again to take into account other parts of the code we would have: 56+ 33.6x2 = 123ms. And shift2 cars take 230ms to react to actions on the controller...
What does the game do during those 125ms delta ? That's more than 7x the times needed for 1 complete 3D refresh (@70fps) + 1 complete physic refresh.
Any buffer latency, signal travel time, display lag, haven't to be taken into account as they already are also present in the 56ms for the driver CP / dxtweak test. The 125ms delta can only come from the game itself imo.
Bad news is many people doesn't mind / notice the latency. And most of the money from games sales is done during the first few weeks after release. So there is no doubt EA doesn't care much about fixing this.
The only chance we have is that Griff said at nogrip SMS was willing to support the game with a few more patches because they own the technology. Thus improving it now is not a pure loss of time for them, as they will re-use this tech in their next racing games.
So let keep fingers crossed, and if all people here noticing latency could voice it at nogrip in Griff thread it will certainly help to convince him that SMS should look at it to try to improve it. Atm, he only has theorical figures about shift2 latency. That's why I'm posting my test results in his thread as I'm certain SMS haven't done that kind of test to check their game latency. But if I'm alone complaining about this at nogrip Griff will certainly don't care about it, even if I come with valid proofs.
For patch2 they have spent time to add a new graphic detail level, which will no doubt benefit a few players only, with very high end PC... Is it really what was the most important for a racing game ? (and especially one suffering a high input latency !)
So, if you are annoyed by shift2 latency, on PC or console, voice it at nogrip in Griff post !
I like this game, but as some people here I think we are missing a lot of its potential due to latency
Btw ISR shift2 final review, which was done with patch1 applied, also agreed latency was still there and that is was too high. That the player doesn't feel the tyres being connected to the road as irl on in other simulations.
Last edited:
- 10,403
- GTP_Spag69
- spagetti69
VolCoMx_x
Not so I'm afraid.
Fanatec with xbox is much better and that's via wireless.
- 219
Not bad news for those people not noticing it
Honestly, on PC, I have no noticeable latency whatsoever since the patch. Boxox's video shows essentially what I see too. I'm not using any dll or mod. So it may be that it's not that people don't mind or don't notice, some of us just don't experience it. Now I'm using a G27, boxox a G25, and I believe Ceth you have a Fanatec wheel? Maybe non-logitech wheels are experiencing the latency moreso and specific hardware too. I have C2D E8500 w/ ATI 6870 & 4GB.
I'm certainly not missing apexes, turning in too early or late, but then again I don't take corners by jerking the wheel as fast as possible left or right either.
I'm picking Shift 2 up for PS3 soon, where I believe there is still definitely small latency, but I'll be interested to compare the 'feel' of the game between the PC and PS3 versions. Hopefully the next patch will remove the last traces of it on console.
- 1,409
- PA
- JEFF636
- OLDSKOOLACURA
Of course.Not bad news for those people not noticing it
Now this topic is aiming at people who DO notice it
And for us that's a very bad news that that much people don't notice the latency and/or think it has been fixed by patch 1 just because the ingame wheel moves quicker or the handling has improved.
I've already said this, I'll trust this the day I see a video showing it.
I've analyzed his video as he has posted it at nogrip a few days ago. When I've checked it frame by frame I noticed frames with no movement following each other. I immediatly suggested his original video was captured at a low framerate and that youtube did a framerate conversion during its reencoding, and that's why there was frame with no movement (duplicated frame to reach 29.97 fps without changing the speed of the video)
I estimated his video was probably recorded at 15fps, and he confirmed a few posts below.
So his video is done at 15fps. Error margin = +/- 66.7ms (thus total error range is twice this, 133ms...). So if youtube framerate conversion was done correctly, without changing the speed of the video, the video is showing a latency somewhere between 66ms and 200ms, and the error margin makes it that much inaccurate that the range could be even wider than this.
At 15fps, accuracy of the measures by a frame by frame analysis is way too low. So, no conclusion can be drawn from this video.
Moreover his video shows ingame wheels response time, and that's not what we are looking for. Moving wheels doesn't prove the controller input went through the physics engine. Only a car movement can prove the physics have dealt with the input, and that's what must be used if you want to test latency in a game by recording a video imho, and nothing else.
Yeah I use a Fanatec. If shift2 is doing direct to driver access it could explain differences between st. wheels. Now many recent racing games (codemasters ones for example) grab inputs from DirectInput. In this case there shouldn't be any possible difference between various st. wheels.
I precisely was planning to do my test with my old microsoft ffb wheel to check if there was any difference or not.
You adapted by anticipating. That doesn't change the fact the game would be much better with a lower latency.
Also anticipation isn't always possible. When taking a corner you see arriving, you can anticipate. But when you have to react to something unpredictable, like for example avoiding someone cutting your path abruptly, no anticipation is possible. In this case you'll have your own reaction time (between 100 and 150ms) + game latency. Thus something between 300 and 400ms.
You can't do real racing in that kind of conditions. It's even worse in MP because of the ping and collision detection that need improvements too (and it will be done with patch 2 according to Griff).
A test you could do with your PC version: look at a replay and use shift2 camera control software to change the view FOV to 30° (put 0.525 in both FOV fileds in shift2 camera control and press F2 during replay so the default FOV is overridden in replay mode. You may be surprised to discover how jerky your steering moves may be (much more noticeable with a FOV at 30°).
You can have a look at my video comparing default FOV (55°) and a modded FOV at 30° if you want to have an idea of what I'm talking about:
See how some of my steering moves are composed of several corrections ? Because you've not steered enough you have to steer again in the middle of the curve. And because the car have moved before you can see you haven't steered enough you often end going off track because you do the correction too late.
That's not racing, I better call it guessing
- 8,426
- Rockay City
Well, maybe he as a really big house.
Anyway, interesting discussion. I shot a few movies at 30FPS myself, from both GT5 and Shift 2, and even without transfer to pc for analysis, the difference is quite obvious.
Still, I find it doesn't bother me a lot in game (have yet to try online though). Also, since I prefer to driver slower/road cars, the lag may not be impacting me as much as people driving the really fast cars.
I've just done a car steering test using my old Microsoft FFB wheel (usb one) and guess what... 182ms...
That's 50ms better than with my Fanatec GT3RS.
That's still high though (too high. Also keep in mind I always skip the 2-3 first frames of the real wheel movement when I do my test. So my measures are very likely to under estimate the real car's reaction time by about 20-30ms). But I tested about 20 laps at Spa Francorchamps (one of the track I master the most), with both a M3 E30 and a Caterham R 500 and the feeling confirmed the measure.
At first I was steering too early because I got used to anticipate the higher latency with the Fanatec. But lap after lap I readapted to the lower latency and my driving was much better.
For example I was able to take the Bus Stop chicane as I never did with the Fanatec (and closer to what I'm able to do on F1 2010 with the fanatec). I also was able to place the car on kerbs with more precision, and also my slides lasted way less time as I was able to do the correction more quickly. With the fanatec when I start sliding it's always for a long time (half a sec approx). With the microsoft I can stop the slide after 100-150ms I'd say.
Well, gonna post this at nogrip now. Idk if Griff will see that as he seems away from his thread those past days.
I wonder if the difference could have to do with some input smoothing. Because in controller xml I know there is a maxSteerVelocity data, and the Microsoft wheel is light as a plume with FFB off (and the fanatec is a heavy wheel). So I was able to make the Microsoft wheel accelerate a lot more quicker when I've done the test.
Damn, this is gonna make me do twice more test now, if I want to test with other games. Gonna have to test with both wheels
That's 50ms better than with my Fanatec GT3RS.
That's still high though (too high. Also keep in mind I always skip the 2-3 first frames of the real wheel movement when I do my test. So my measures are very likely to under estimate the real car's reaction time by about 20-30ms). But I tested about 20 laps at Spa Francorchamps (one of the track I master the most), with both a M3 E30 and a Caterham R 500 and the feeling confirmed the measure.
At first I was steering too early because I got used to anticipate the higher latency with the Fanatec. But lap after lap I readapted to the lower latency and my driving was much better.
For example I was able to take the Bus Stop chicane as I never did with the Fanatec (and closer to what I'm able to do on F1 2010 with the fanatec). I also was able to place the car on kerbs with more precision, and also my slides lasted way less time as I was able to do the correction more quickly. With the fanatec when I start sliding it's always for a long time (half a sec approx). With the microsoft I can stop the slide after 100-150ms I'd say.
Well, gonna post this at nogrip now. Idk if Griff will see that as he seems away from his thread those past days.
I wonder if the difference could have to do with some input smoothing. Because in controller xml I know there is a maxSteerVelocity data, and the Microsoft wheel is light as a plume with FFB off (and the fanatec is a heavy wheel). So I was able to make the Microsoft wheel accelerate a lot more quicker when I've done the test.
Damn, this is gonna make me do twice more test now, if I want to test with other games. Gonna have to test with both wheels
Last edited:
- 268
- Germantown, WI USA
- bmw2sq
I've just done a car steering test using my old Microsoft FFB wheel (usb one) and guess what... 182ms...
That's 50ms better than with my Fanatec GT3RS.
...
Damn, this is gonna make me do twice more test now, if I want to test with other games. Gonna have to test with both wheels
To cover most of the bases (wheels), you might as well add the Logitech DFGT
Well, if you offer me one, why not
edit: the test is very simple to do. You just need a camera that can record videos. Preferably @60fps but 30fps will give valid infos too. It would be intersting to see this test done using various hardware for comparisons (various st. wheel, on various PC spec, or even consoles)
edit: the test is very simple to do. You just need a camera that can record videos. Preferably @60fps but 30fps will give valid infos too.
It would be intersting to see this test done using various hardware for comparisons (various st. wheel, on various PC spec, or even consoles)Tests are done using a CRT (viewsonic e92f+ @120hz), and CRTs are known to have very low display latency (I even have seen them being a reference for testing LCDs display latency. Now ok, all CRTs aren't equals regarding display latency. But even a bad one won't have that much dl. And this viewsonic is certainly not part of the worsts CRTs ever).
Also the microsoft test doesn't show a difference between cables (come on, 1.5m long cables !). I've just done a driver reactivity test:
Microsoft sidewinder usb wheel: 44.7ms
Fanatec GT3RS: 31ms
I think the difference between wheels mostly comes from their electronics. And for the above test, maybe a bit from the software used as I wasn't able to test both wheels with the same software unfortunately. The Fanatec was tested using its driver CP, and the Microsoft using JoyTester (both utilities refreshing datas at least at 60Hz though. And with both I've had cases where the datas were displayed 1 frame after the wheel started moving).
About the 50ms difference on shift2, the main part must come from shift2 code and not from the wheels or their drivers.
Also the microsoft test doesn't show a difference between cables (come on, 1.5m long cables !). I've just done a driver reactivity test:
Microsoft sidewinder usb wheel: 44.7ms
Fanatec GT3RS: 31ms
I think the difference between wheels mostly comes from their electronics. And for the above test, maybe a bit from the software used as I wasn't able to test both wheels with the same software unfortunately. The Fanatec was tested using its driver CP, and the Microsoft using JoyTester (both utilities refreshing datas at least at 60Hz though. And with both I've had cases where the datas were displayed 1 frame after the wheel started moving).
About the 50ms difference on shift2, the main part must come from shift2 code and not from the wheels or their drivers.
- 1,116
- Gassolini
OK, Since the argument for delay through cables has been put forth a couple of times, just for fun let's see just what it amounts to :
1.5m cabe => delay of 7.5e-9 (or 0.0000000075) seconds
To put that in perspective, you need to wrap a cable at least 5 times around the planet Earth to achieve a delay of 1 second. If you stretch a cable from the Earth to the Moon, the delay is less than 2 seconds.
The quality and type doesn't matter much either. I.e. we should all forget about that
DJ
--
Last edited:
Similar threads
Latest Posts
-
-
-
Fanatec Discounts Sim-Racing Hardware up to 54% for Black Friday 2024- Latest: A_Higher_Place
-
-
