Is there a way to sync a Stopwatch timer to 240 fps?

Unity Engine
1

I’m trying to use a stopwatch through fixed update to achieve more consistent delta Times, but the stopwatch is giving me 0’s whenever I push the effect project settings timeStep to 240 fps.

The current readings go in a pattern of
.0
.0
.0
.016

and still looks like its being capped at 60 fps.

private System.Diagnostics.Stopwatch stopwatch = new System.Diagnostics.Stopwatch();

    void Start()
    {
        Application.targetFrameRate = 240;
        stopwatch.Start();
    }

    void FixedUpdate()
    {
        stopwatch.Stop();
        float deltaTime = 0.001f * stopwatch.ElapsedMilliseconds;
        stopwatch.Reset();
        stopwatch.Start();
    }
2

You might be able to get something finer-grained from AudioSettings.dspTime… check here:

3

What’s happening here is that you’re learning how FixedUpdate really works.

It’s not, in reality, called every fixedDeltaTime seconds. It’s always called before Update is called, but if Time.time has crossed the “threshold” of a Time.fixedDeltaTime interval, then it calls FixedUpdate - sometimes multiple times, until the “fixed time” has caught up to the “game time”.

If you use Unity’s own timing mechanisms in the Time class, that won’t be an issue, because Unity fakes the values like Time.time so that the simulation has a fixed time interval. If in FixedUpdate you Debug.Logged the value of Time.time instead, it would indeed be going up at an even amount. And from FixedUpdate, Time.deltaTime will always return your fixed time step.

So let’s back up and ask…

…why do you want this?

2 Likes
4

If you want physics to simulate faster, you should adjust fixed time step. Otherwise physics will still be simulated at the same rate.

5

We’re using a analog data acquisition source and we want to acquire samples as fast as possible (240 Hz).
I figure that the solution to this problem is to have C# threads instead use their own Stopwatches to determine when to read from the analog source instead of FixedUpdate telling it when to read.

6

In which case simply spin up a new thread to do the job, the same way you would in a console app.

All of Unity’s methods are tied to the rendering rate. And there is no point forcing your entire app up to 240 Hz just for the data acquisition.

7

If you have a scenario like that, you’re definitely going to want the data-gathering going on in its own thread. Neither Update nor FixedUpdate will reliably be run at any particular time interval in a real-world clock sort of situation.

8

Still, is there any way to get Unity to run at 240 Hz. I’ve tried using

Application.targetFrameRate = 240;

but the application will still be limited to 60.

9

Yes that is what I am currently in the process of doing. Still learning a lot of Unity’s capabilities and the proper way to utilize the engine and the resources. It’ll take me a while to get everything over onto a new Data acquisition thread.

10

Which platform are you building to? Some platforms are inherently frame rate limited.

Also have you turned off vsync?

You also want to check the rate in Update, not FixedUpdate. FixedUpdate simulates the physics framerate, no matter the actual frame rate.

11

Currently trying to build to a Windows system. We’re trying to see if we can get a good enough refresh rate for a 240 Hz monitor or adapt the rendering to VR.

12

On an empty scene I can easily get 1000+ Hz. So it’s definetly not a Unity limitation you are running into.

13

I would bet a pizza (with toppings) that this is the problem.

1 Like