Probably a bad title: What I mean is, say I want something to happen 10 times every second, no matter what the framerate is (unless the system is totally bogged down at least). Unity 4.6.
Use FixedUpdate? Only if it’s a multiple of the physics tick speed. i.e. If the physics happens 10 times per second, or 20 etc then it’ll be fine, but if I want physics to happen 15 times a second then I’ll get uneven intervals on my 10-times-per-second loop.
Use InvokeRepeating? Nope, it’s framerate-dependent. If my framerate is 2fps, I’ll get around 10 calls per second but they won’t be evenly spaced, they’ll be called a bunch all at once two times a second. Invokes only happen on Updates, not in-between.
Use a coroutine with WaitForSeconds? Nope, it’s framerate-dependent again. WaitForSeconds only calls a maximum of once per frame, so at 2fps I’d only get two calls per second instead of 10.
Obviously you’d hope not to be running at 2fps anyway, but the problem can show itself at higher framerates for more frequent loops.
Would you guys just use a default C# Timer in this situation maybe?
I realise that mostly stuff in-between frames doesn’t matter, and I’ll probably get the equivalent of the old “Doctor, it hurts when I do this” → “Don’t do that then”. But in networked games especially this sort of thing can be needed.
Does the code need to run exactly every 0.1 seconds?
If not, then you should be able to do this in the update method. Just set a timeLastUpdated variable, if the time since the last update is Greater than 0.1 seconds, then execute your code.
Edit: You could even add code to execute a couple times if frame rate is really slow.
eg (untested code, for demonstration purposes only):
float timeLastUpdated;
void Update
{
if ((Time.time - timeLastUpdated) > 0.1f)
{
float delta = (Time.time - timeLastUpdates) / 0.1f;
while (delta > 0)
{
... Do something
delta -= 0.1f;
}
timeLastUpdated = Time.time;
}
}
It’s more of a conceptual question than for a specific thing, but yeah, my general question is how to have a framerate-independent fixed-interval call to something.
I really just thought it was strange that all the things that seem like they’d do this in Unity are actually framerate dependent, except for FixedUpdate which of course you only have one of at one fixed rate.
Thanks for your response, but I just didn’t bother mentioning Update because it’s the most obviously framerate dependent of all! Like, as with WaitForSeconds, if you’re at 2fps and wanting a call 10 times a second, you’ll only get two.
BTW with your example, you may know already but Time.time is affected by the current timeScale. You’re better off using Time.realtimeSinceStartup for calls that you want to always have a real-time fixed delay.
You are correct about Time.time 
Sorry I don’t have anything else. As you have pointed out, the building blocks of Unity are all based around frame or physics cycles. The only option you would have is to use the Timer on a seperate thread. Threads are very limited because you can’t access any of the Unity API stuff. And I am not sure how Timer events would work in Unity.
Start a new thread with its own timer on it. Anything that needs this level of precision can then be generated on that thread. Of course you still have to queue anything that requires access to the Unity API back to the main thread. But that’s pretty doable.
You’ll also have to make your code thread safe. But hey, you are asking to be able to implement your method at a precise time, no matter what else is happening. That won’t come easy.
Points taken. I guess a separate thread with a timer would have to be the thing. Thanks for the comments.
Out of curiosity what’s your use case? Unite had some pretty good presentations on procedural sound, which required perfect timing. You might be able to leverage that.
Mainly a method that sends some position info and a little bit of other stuff from client to server at a fixed rate, but if the client’s framerate craps out it ends up looking the same as if they were lagging out from bad latency, or maybe trying to cheat and teleport around. Would be nice to send it consistently, but I think rather than do some complicated threaded timer solution I’ll actually be better off refactoring how things work to not require it to be so consistent.
1 Like