Microstutter?

[mountainmohawk]

Im running on a 780ti at 1440p on a 144hz monitor. It looks like I have a steady framerate (usually around 120) but when moving, everything looks kind of jerky and stuttery. I'm on my newest drivers, and tried playing around with the ingame settings, but nothing seems to work. :(

[Rat King]

That's a common problem with 144Hz monitors, they're making the fixed delta time of physics updates too 'obvious'. Create a file called 'ratkingsrules.txt' in the same folder where the tri.exe is, and write

fixeddeltatime:0.01

inside that file (standard value is 0.02, by the way). Hope that helps a bit at least.

[mountainmohawk]

Thank you, that helped a lot!

[Mairo the bear]

I have seen this happening with sooo many unity using games and this is the first time dev aknowledges the issue, knows what the issue is AND provides way to fix it to some degree.

Kudos for this. I'll assume 'ratkingsrules.txt' won't work with other games though.

[Rat King]

:-) Yeah, the 'ratkingsrules.txt' is specificall for TRI. If you know other Unity games with this problem you might want to give the developers the tip to create an option to decrease the Time.fixedeDeltaTime (if the game's gameplay won't break with this).

[Patapits | simplefullcraft.com]

+1. I have a 60Hz monitor, but was experiencing the same problem. I tried a huge deltatime (fixeddeltatime:0.5), and the problem was clearly the same, but worst. With a very low value (fixeddeltatime:0.001), the problem is gone ! And for reference, with fixeddeltatime:0.005, the problem is still visible. Thanks !

[Rat King]

Wow! 0.001 is crazy, that means the physics engine updates 1000 times per second!

[Patapits | simplefullcraft.com]

Yeah, and I don't get why it solves the problem at all :o For information, I initially posted a thread on the NVidia forum about this problem (because I thought it might be related to my graphic card) here[forums.geforce.com]. And some people are talking about some similar behavior with the Unity FixedUpdate method here[answers.unity3d.com], here[forum.unity3d.com] and here[forum.unity3d.com]. I think I'm missing something somewhere and I'm really curious about the real reason why this problem occurs so often on my computer with Unity games (and a common 60Hz monitor !).

[Rat King]

Thanks for the links, very interesting read. I guess it has something to do with some monitors and/or driver configurations? Like in the articles you linked, where someone has 59Hz instead of 60Hz, and that produces some hick-ups every few frames, as FixedUpdate() is not really called every x seconds like it suggests, but as often as necessary until it catches up.

But at least all this makes me attentive to such things. I would never have thought that it would create any problems to put stuff into FixedUpdate(), but well, here it is. :-/

[Patapits | simplefullcraft.com]

Hmmm, honestly, I doubt it... And now, with a fixeddeltatime of 0.001, everything seemed to be smooth, but when entering new wide areas, everything is lagging as hell (which is, well, expected with that fixeddeltatime !). So I went back to the default fixeddeltatime. I tried it on 2 different computers with different configurations, and the problem remains. I also checked the setup framerate of my monitor on Windows : everything is setup at 60Hz. I'm (really) far from being a Unity expert, but my assumption is that these stutters are due to the player/camera movement (and that anyone without some "filters" on their monitors can experience this problem). Instead of moving continuously, the camera/player is moving by discrete steps depending on the user input. In that case, if these steps are not perfectly synchronized with the screen refresh rate (which is in fact impossible to obtain), this can cause some stutters. This is why everything is smooth when standing still and looking around, but start to jitter when moving and looking around simultaneously. From what I understand about Unity physics engine (and my little experience), the solution seems to be :

- Get user Input in Update, not FixedUpdate (it can lead to input loss, but since looking around with the mouse seems to be smooth as butter, input loss might not be related to this particular problem)
- Make the character/camera move in Update (or LateUpdate), but not in FixedUpdate
- Having a rigidbody attached to the character/camera (which is probably already the case), set the interpolation attribute to "Interpolate" and use velocity to move the character/camera instead of directly moving the transform of the gameobject with Translate
- (And I would add not using the default Unity input manager, which seems to be not highly reliable, but that's another story !)

But once again, maybe I'm talking nonsense, and sorry if that's the case. If I'm not, the benefits/costs of this kind of fix seems not to be in my favor, so I guess I'll try to get used to it :p

Anyway, thanks Rat King for the great game and for your time !