Impossible to get perfectly smooth motion with Unity?

Never heard of unigine before, but I've never really had this problem in anything except Unity, and back in the day I tried quite a few engines (Torque, Construct, & a few other engines I don't even remember the name of), as well as rolling my own engine more than a few times (SDL, SFML, XNA, DirectX, PyGame, Slick2D).

It also doesn't help that in addition to Unity Engine's history of unsmooth-ness & stutter, reaching a perfectly smooth 60 fps is actually a huge technical leap & (at least at the time of this video) requires access to the Unity source.

Probably already in this thread, but again....

Of course since I do 2D & 2.5D games, I don't recall having this problem anyway (60fps) but I do remember being concerned for getting 144fps (which by itself is a very difficult thing anyway, as you're talking about targeting 6.94ms vs 16.67ms). Not really show how difficult this is to achieve even outside of Unity without a lot of hardcore multi-threading.

I am a bit sad about this thread's continued existence though. Everytime I get a notification that someone has posted, I get disappointed that this is still an issue for people. It doesn't matter to me if the issue is with the engine or with people not having access to the resources needed to have smooth motion. This should be addressed by either Unity or by a popular Unity resource author. If I had more time, I'd love to quantify a lot of different game systems (how much performance in ms they might take, giving a general idea for performance & talking about it with verifiable examples in code) to give people a better idea of what can take computer resources more/less, along with best practices & other things. sigh. So much I'd love to do to help teach & grow amateur gamedev & establish learning resources, but I simply don't have the time. I wish I could make a single one-stop-spot website people could go to, to make their dream games (so we can stop all the lame platformers and start all the innovation).

 

On the video: I hadn't seen it. But when you have a totally empty scene and it still stutters, then there's nothing you can optimize. It's an issue in the engine itself.

 

Thx @Edy for clarification about the internal Unity versions change:
("...The problem in Unity is that Time.deltaTime is bound to the frame generation time, not to the screen's frame rate. This was good enough up to Unity 4, but since Unity 5 and the new graphic APIs this is not good anymore...")

Just curious why they changed this "Time.deltaTime" stuff from U4.7 to U5.6 to the newest one. Maybe they needed for the new graphics ? But it could be made bounded to the screens frame rate ?

Some users mentioned, using the "update" loop. I prefer using "StartCoroutine / IEnumerator". As i understand it is the same. But with the difference that i can stop the updating completely. The usual "update" runs forever. You can´t stop it, except putting if-functions inside. As far as i know. Would anybody also prefer "StartCoroutine" against "update" ? Or is it a bad idea / doesn´t make sense ?

 

I should have mentioned that the graphics APIs at that time also worked differently. Other users pointed out that currently the stutter exists in Unity 3, 4 and 5.

I don't think Unity changed anything with regards to Time.deltaTime. The method they use worked fine back then, but it's not good anymore with the new graphic APIs.

I'm yet to see how using coroutines could help on this. Some times the Unity Update loop takes more time than the frame time, so it's immediately followed by a quick Update. This results in the heavy variations in Time.deltaTime that cause the stutter. Stopping the update loop would just make it worse, as far as I can figure out.

Using coroutines may allow you to ensure that each Update cycle consumes a precise time, giving consistent values to Time.deltaTime. But that requires disabling VSync, so you would get tearing. To me, as solution is a no-go.

 

Just wanted to say to those users, StartCoroutine also performs an allocation of iterator method call that cannot be avoided.
So if your aim is to make perfect smooth movement, adding garbage to collect might not be the smartest idea.
(Depends when started / stopped ofc)

 

Thx for that info.
I am not so far with C# coding. I am curious which method in general is better suited for low-end devices (the common update or Coroutine ?). So you mean Coroutine is "adding garbage to collect", which is bad. Update on the other hand, does not. Or just a little.

 

Update on its own doesn't create any garbage.

However, be aware that Update is called from the native side.
And got some overhead in terms of extra CPU usage when there's a lot of updates > 1k which may stack up.

So it really depends. If you alloc coroutine once, and never end it, it shouldn't create any garbage to collect.
But you'll have a coroutine running wasting ops.

Best solution I've found for myself is a custom managed update manager.
So, on low-end devices I suggest doing the same, if you want buttersmooth performance.

But probably the best solution to this is ECS / Job driven updates.

 

Or .enabled = false;

 

@xVergilx , you mean lot of updates in different scripts, or in one script? This sounds really interesting "custom managed update manager". Do you have more info about that ? For the ECS stuff, i didn´t investigate into it. I am just in learning mode with C#. Not sure if ECS makes sense for small games. As i was watching these videos, it looks like its best suited for some big game projects. Could be wrong here.
@hippocoder, yep you are right. But this stops the whole "update cycle". Lets say, i need an update on obj_A.x & obj_B.x. obj_A needs to stop after 10sec. But obj_B needs to be the whole time in the update. I think for this situation only the "if" functions inside an update can achieve my goal. Or these Coroutine-functions. Or are there other ways to do that ?

 

In the end its just one place where all Updates are aggregated, so basically its just a:

Code (CSharp):

1. foreach (Script s in updatables) {
2.     s.DoUpdate();
3. }

But the actual code for the update can be put anywhere. That's up to you to implement however you like it.
I did mine with three update loops (Update / FixedUpdate / LateUpdate) tied to the initial Unity updates.

Scripts are added to those custom update loops via extension methods + interfaces.
As a bonus, I can insert even non-monobehaviour classes to the update system as well.
And, it can be as well improved by introducing extra separate updates, in case I need extra logic to be split.

Cons, you had to catch exceptions at update system level. Otherwise each and every script will stop running upon it.
And that means you can't click on the error message to jump to the statement that caused an error.
So the stacktrace has to be outputted in catch block and read manually.

Also worth noting that since introduction of DOTS, there's a built-in custom update loops API in Unity as well. But its experimental.

 

Hey, thx for this explanation. I will need to investigate more into it. And i will try to play around with your tip. . About DOTS, in the video it was introduced for some mass-objects in the scene. For me its a bit far away. Need to learn the basics.

 

It seems this type of problem is apparently even in some of the most successful Unity games.

While I can't confirm this is a unity problem and not their horrific code, I am suspect.




And here is what I screen grabbed after looking at only the very first page...



On my PC, the game is quite awful with tons of visual artifacts - a very amateurish not-pixel-perfect Unity game. That would be the fault of the developer, not Unity.

However on my Switch, and on all these people's PC's, the stutter as shown in this thread is very, very prevalent.

Worse, on the Switch, there are 0 options for any attempt to fix the problem.
On a side note, the game's performance is horrible. Anytime there is weather, the game lags on the Switch really bad. That is totally unacceptable for such a simple 2D game, but here we are. So I cannot say it is a Unity issue, because the Lazy Bear Games are clearly really, really bad at game programming / performance.

However even when it is smooth on the Switch, the hitching/stuttering as shown in this thread is a serious issue.

But is it really a Unity problem, if other developers fix this issue?
​

I would argue, actually yes. Also no, obviously, but yes because...

If this is still a problem without having to do everything 'just right' it is a Unity issue. By default, this shouldn't be a problem. If it still is (which it may not be - unity may have fixed this - Graveyard Keeper is a really bad example due how bad the developers are) ... if it still is... it's an issue because it encourages this type of bad practice.

This however is my complaint, as a Gamer, for all Unity games. Many developers, including major ones like those of Shadowrun Returns, seem to pair Unity with a "Rush Development" mindset. The idea being to use Unity because it 'saves so much time' and so rushed developers tend to pick it. Which only hurts with that 'unity logo' stigma.

So the more Unity does to fix its problems in a 'by default' way, so rushed developers and incompetent developers don't screw things up, the less stigma Unity will receive. Perhaps in time, the Unity logo could be something worthy like the Unreal logo, rather than being a shame that everyone pays for to remove.​

 

100% sure it's because the programmer didn't code deltatime correctly. Next you'll be telling me boneworks on steam is Unity's fault too. That's done in Unity 2018, and runs typically at 144, 120, 90, 80 and 72 respectively.

The comments for that game you listed have a very telling givaway: with vsync off running > 60fps causes the character to move like lightning. Pretty sure that means there's no delta timing going on which will make it run like crud even if it's at 60 ish.

Not saying there isn't more Unity can do, but VR is the true litmus test here.

 

Yea, pretty much. I think that is obvious, although we can't know for sure.

I'm actually mostly concerned with the Switch version, which seems to have the problem really badly. I posted the PC complaints to point out though it still could (and is likely) the developer, not Unity.

Still worthy of cataloging how messing this stuff up is prevalent even in very successful games which use Unity, but not in very successful games of other engines.

That's my main point. It's in the interest of engines to stop incompetent/bad developers as much as they can. Not Unity's fault though, and they can't stop everyone. Wanted to bump to see if any other Unity Switch games had this issue.

Interesting! Unfortunately I can't test that out. Not into VR. Would love to see some people testing though or reporting games that goofed.