Removing input lag and stutter caused by the tick rate?
by Paul Seyfarth · in Torque 3D Beginner · 04/04/2014 (9:07 pm) · 9 replies
Seems that the 32ms tick rate causes input lag and looking around isn't smooth, is there an easyish way to fix that? I have changed TickMs to 8, which helped some( checked it at 4, 16, and 128 to make sure it made a difference). But it's still not smooth and this is with framerates above 80fps. I have checked out looking around in other engines and games to make sure I wasn't imagining it and I am not.
I am sure there is something simple to fix this.
I am sure there is something simple to fix this.
About the author
#2
First the stuttering I was noticing was because of how much the camera turns per mouse movement. I will just lowering the how much the camera turns on mouse movement. Will I be dealing with camera.cpp, or is there something else to deal with what we see on screen?
Second is the tickrate, though it may not be as noticeable after I adjust the camera movement. Though you can see what I was noticing exaggerated if you up the tickMs to 128.
If anyone has done any of this before let me know. I am off to bed now, I will take a look in the morning. For camera movement, I am thinking I will just need to take the input before the camera does anything and drop certain values by a factor of 2 or something like that.
04/04/2014 (9:47 pm)
After another test it seems like there are two problems, both should be easy to sort out in the engine. First the stuttering I was noticing was because of how much the camera turns per mouse movement. I will just lowering the how much the camera turns on mouse movement. Will I be dealing with camera.cpp, or is there something else to deal with what we see on screen?
Second is the tickrate, though it may not be as noticeable after I adjust the camera movement. Though you can see what I was noticing exaggerated if you up the tickMs to 128.
If anyone has done any of this before let me know. I am off to bed now, I will take a look in the morning. For camera movement, I am thinking I will just need to take the input before the camera does anything and drop certain values by a factor of 2 or something like that.
#3
Uhm, no. You'll be dealing with lowering mouse sensitivity if you think it's too high. It's in prefs.cs.
You're comparing 128 ms with 32 ms (4x difference) to make your point. You can lower FPS from 60 to 15 as well (4x difference) and that will stutter too, but that's doesn't make it a valid point that 60 fps is too low.
All game engines tick, or they wouldn't be very performant.
04/05/2014 (3:16 am)
Quote:
First the stuttering I was noticing was because of how much the camera turns per mouse movement. I will just lowering the how much the camera turns on mouse movement. Will I be dealing with camera.cpp, or is there something else to deal with what we see on screen?
Uhm, no. You'll be dealing with lowering mouse sensitivity if you think it's too high. It's in prefs.cs.
Quote:
Second is the tickrate, though it may not be as noticeable after I adjust the camera movement. Though you can see what I was noticing exaggerated if you up the tickMs to 128.
You're comparing 128 ms with 32 ms (4x difference) to make your point. You can lower FPS from 60 to 15 as well (4x difference) and that will stutter too, but that's doesn't make it a valid point that 60 fps is too low.
All game engines tick, or they wouldn't be very performant.
#4
One was fixable by turning vsync on and then off. I am not really sure what that problem was, but I was noticing stuttering when walking sideways. So tried to see if it was some sort of sync problem so turned on vsync and it was much smoother, then turned it off and it was still smooth even though you still get the normal tearing.
Second was lowering mouse sensitivity. Even with increasing DPI on mouse it's still much smoother than it was.
Now the sync issue may have been causing the lag I was feeling. But it is a perfectly valid point if you want to see the type of lag I was talking about. It may not be the tickMs that is actually causing the main lag that I feel but it allows you to see an what I am talking about. Though that problem is basically gone now.
04/05/2014 (7:56 am)
It seems there were two main problems with smoothness.One was fixable by turning vsync on and then off. I am not really sure what that problem was, but I was noticing stuttering when walking sideways. So tried to see if it was some sort of sync problem so turned on vsync and it was much smoother, then turned it off and it was still smooth even though you still get the normal tearing.
Second was lowering mouse sensitivity. Even with increasing DPI on mouse it's still much smoother than it was.
Now the sync issue may have been causing the lag I was feeling. But it is a perfectly valid point if you want to see the type of lag I was talking about. It may not be the tickMs that is actually causing the main lag that I feel but it allows you to see an what I am talking about. Though that problem is basically gone now.
#5
Have you used a vendor tool to profile your video hardware?
I've never seen any sort of "lag" (this term gets mis-used a ton - it is actually network latency, not related to graphics performance at all) that wasn't caused by my own overloaded scenery - drop too much work on the graphics subsystem and it will slow your frame rate.
04/05/2014 (9:36 am)
How complex is your scene?Have you used a vendor tool to profile your video hardware?
I've never seen any sort of "lag" (this term gets mis-used a ton - it is actually network latency, not related to graphics performance at all) that wasn't caused by my own overloaded scenery - drop too much work on the graphics subsystem and it will slow your frame rate.
#6
04/05/2014 (10:01 am)
Not very getting over 100fps, I think the lag was coming as a problem from the stutter that I was getting which has since been fixed. If I were to move my mouse at the same time as the stutter it would delay the stutter time before I would see movement. Fixing that along with lowering mouse sensitivity seems to have fixed all the problems I was having. It works great now!
#7
04/05/2014 (10:13 am)
I would agree that the word lag is misused a lot and ends up causing confusion. Yet as a word it can be a good descriptor to describe what is happening. It just needs to be described as such. Input lag being a good example. Such as what I see happening on screen is lagging behind my mouse input. Sure you can use other words like delay or latency but it shouldn't matter.
#8
04/06/2014 (9:25 pm)
The usual case for me is that when a ton of objects come into view (I quickly turn around, for instance) I notice a frame rate hit - and that might be due partly to the ghosting system. Anything not in frustrum and not marked GhostAlways will not be ghosted to the client. I'm just guessing here, really, but I rarely see this issue except in fairly noisy levels. 
#9
Regardless of what the OP's original problem actually was there is some mouse lag in Torque inherent to how the client-predictive network model works
Mouse moves are collected continuously, but are only applied on the simulation level at ticks. For example when you're controlling a Player object your moves are only converted into object Z rotation and mHead.x changes at each tick (32ms by default).
That alone doesn't cause lag, but it would produce a stutter because the input is only having an effect every 32ms (and your FPS is probably a good bit higher). Instead the control object gets interpolated just like everything else, smoothing out the camera movement but also introducing a little bit of mouse lag (<32ms assuming everything's working properly).
This is how things have to work because the client-predictive networking is reliant on the client and server simulation of control objects coming up with the exact same results, which means they have to run the exact same number of ticks (a server object with a controlling client only processes ticks when it gets new moves from that client).
While this lag isn't desirable it's preferable to running without client prediction (which gives you a control lag of at least your ping). Increasing the tick rate obviously will help.
I don't think this is really a problem for any games using the default tick rate or higher, but I can see someone building an MMO or other low-action game dropping the tick rate and wondering why their mouse moves are so laggy. Correcting the issue in that case seems like it would be a mess, and I'd say slow games like that may not need the level of server authority that Torque provides by default (an MMO probably doesn't need to be server authoritative about the client's current "look" direction).
The other common causes (as more or less already covered) of mouse input problems are:
Mouse sensitivity too high + DPI too low. When the sensitivity is too high, the minimum motion you can create with mouse movement is larger than 1 pixel, creating stutter.
Frame rate stutter. If the engine isn't rendering frames smoothly the overall control experience won't feel smooth. It's important to note that frame rate can sometimes lie about performance because it's an average over some time. A graph of frame times is far more informative (maybe you're getting 80fps on average, but the engine is periodically stalling for a particularly long time and creating a stutter).
06/19/2014 (2:15 pm)
Some notes relevant to this topic:Regardless of what the OP's original problem actually was there is some mouse lag in Torque inherent to how the client-predictive network model works
Mouse moves are collected continuously, but are only applied on the simulation level at ticks. For example when you're controlling a Player object your moves are only converted into object Z rotation and mHead.x changes at each tick (32ms by default).
That alone doesn't cause lag, but it would produce a stutter because the input is only having an effect every 32ms (and your FPS is probably a good bit higher). Instead the control object gets interpolated just like everything else, smoothing out the camera movement but also introducing a little bit of mouse lag (<32ms assuming everything's working properly).
This is how things have to work because the client-predictive networking is reliant on the client and server simulation of control objects coming up with the exact same results, which means they have to run the exact same number of ticks (a server object with a controlling client only processes ticks when it gets new moves from that client).
While this lag isn't desirable it's preferable to running without client prediction (which gives you a control lag of at least your ping). Increasing the tick rate obviously will help.
I don't think this is really a problem for any games using the default tick rate or higher, but I can see someone building an MMO or other low-action game dropping the tick rate and wondering why their mouse moves are so laggy. Correcting the issue in that case seems like it would be a mess, and I'd say slow games like that may not need the level of server authority that Torque provides by default (an MMO probably doesn't need to be server authoritative about the client's current "look" direction).
The other common causes (as more or less already covered) of mouse input problems are:
Mouse sensitivity too high + DPI too low. When the sensitivity is too high, the minimum motion you can create with mouse movement is larger than 1 pixel, creating stutter.
Frame rate stutter. If the engine isn't rendering frames smoothly the overall control experience won't feel smooth. It's important to note that frame rate can sometimes lie about performance because it's an average over some time. A graph of frame times is far more informative (maybe you're getting 80fps on average, but the engine is periodically stalling for a particularly long time and creating a stutter).
Torque Owner Daniel Buckmaster
T3D Steering Committee