If you write your own controller code you might hit this bug.

Unity Engine
,
1

If your controller code uses Time.deltaTime to ensure smooth input movement e.g.

float3 move = new float3(leftright, updown, forwardback);
move *= deltatime * movespeed;
transform.Translate(move);

The problem here is it’s based on the assumption that the frame rate has no hiccups.

If however anything triggers a stutter in performance then the user experiences a huge jump in movement after a slow frame.

Or in my case their helicopter would flip over Xeewolf [Web] by Arowx

The trick is to test and cap deltatime e.g.

if (deltatime > 0.1f) deltatime = 0.0167f; //expecting around 60fps.
float3 move = new float3(leftright, updown, forwardback);
move *= deltatime * movespeed;
transform.Translate(move);

Hopefully this problem is not in any Unity controller code.

2

Does putting a hard-limit give you better results than using Time.smoothDeltaTime? I guess if it was more than a few frames and was persistent over a longer period of time then smoothing isn’t going to help.

1 Like
3

Actually there is Time.maximumDeltaTime which you could use and it should have the same effect as if (deltatime > 0.1f) deltatime = 0.0167f;

It was occasional frames when the games WebGL performance just tanks, e.g. bullet hell or on startup when the scene does some random generation.

Never looks good when your Xeewolf helicopter starts upside down on the helipad.

4

Note that maximumDeltaTime is by default set to 0.333333 (or 1/3). Capping the deltatime should only be the last resort. Though capping the framerate and reducing it heavily are two different things. In your code if the framerate is lower than 10 fps, you would fake a 60fps rate which in turn would make your game run 6 times slower.

It seems your game is just badly designed. You probably allocate tons of garbage and the hicups are the GC kicking in trying to clean up the mess. This had little to do with WebGL. Just as an example, here’s my “parallel” mandelbrot renderer as a webgl build. It does store and manage 2 complex numbers for each pixel in the image any every frame calculates one iteration for each pixel (576k pixels). Though once a pixel has settled it’s removed from the active list and only the remaining (black) pixels are still iterated. It should run pretty smooth on most machines, especially once the number has reduced. Of course this is just an example. I have zero memory allocations and therefore no GC would kick in.

I don’t quite understand your game design anyways. Your helicopter seems to rotate on any impact and then stays like that. That’s not really how helicopters fly and if it’s intentional, it’s a strange game mechanic :slight_smile:

5

Only WebGL is single threaded and therefore prone to hitting processor bandwidth limits and producing drops in frame rate.