1
\$\begingroup\$

I'm calling Time.frameCount inside Update() and then immediately Debug.Break() to pause the simulation before Update() is finished. This of course happens (supposedly) on the very first frame, and yet Time.frameCount returns 1, as if one frame had already been rendered by at that point. Also, I'm calling Time.deltaTime the same way, on the first frame inside Update(), and it returns a value too, as if a previous frame had been rendered and took X milliseconds.

Considering Time.deltaTime returns the value of the "time it took to complete the last frame", and I'm calling it on the first frame and it's returning a value, is there an "invisible" first frame that Update() doesn't run on?

I couldn't find any reference to this specific issue on the Unity docs.

Improve this question
\$\endgroup\$

1 Answer 1

Reset to default
2
\$\begingroup\$

Update() is called during a frame. Time.frameCount counts the number of frames that have occurred. It's a count, not an index, so during frame zero (the first frame) the total number of frames (Time.frameCount) will be one.

There is no invisible first frame. It's typical to initialize "delta time" values with some reasonable small number for the first frame, because any values that are "technically correct" such as 0 or the time since you last launched the application are generally meaningless for the purposes of running the game simulation.

Improve this answer
\$\endgroup\$
5
  • 1
    \$\begingroup\$ Thank you. How is then that the description for Time.frameCount says "The total number of frames that have passed"? Is the wording just confusing? I also find it counter-intuitive that Time.deltaTime explicitly refers to the "previous frame" and yet basically makes up a value if there's not previous frame. I'd normally expect an uninitialized C# float to be zero. \$\endgroup\$
    – flatterino
    Aug 22, 2018 at 15:35
  • 1
    \$\begingroup\$ Yes, the wording seems confusing. Saying "that have passed" implies completion, but it also says that it starts counting "once all Awake functions have finished" which implies an increment right after awake, before update. They don't agree, but in practice your observation suggests that it does not just count completed frames, but also includes the current one. \$\endgroup\$
    – user1430
    Aug 22, 2018 at 15:38
  • 1
    \$\begingroup\$ As for the delta time issue, consider that delta time is almost always used as a scalar to do things like, say, move objects. If a frame runs with delta time 0 just because that is "technically correct" for the first frame, that entire frame's worth of processing is wasted because nothing will move or update. So it doesn't make sense to do; instead we just use the expected typical delta time, or some other small in-range value so as to avoid wasting time. \$\endgroup\$
    – user1430
    Aug 22, 2018 at 15:40
  • \$\begingroup\$ I see. And wouldn't that "made up value" for delta time make a simulation that depended on it very slightly inaccurate if for some reason you expect it to run since the very first moment? \$\endgroup\$
    – flatterino
    Aug 22, 2018 at 15:55
  • 1
    \$\begingroup\$ Not really. As long as the value chosen is reasonable for the expected range (e.g., 1/60, as most games try to achieve 60 FPS), the first frame will be just as accurate as any subsequent frame. It will not be an accurate simulation of real time, but that's not what a game is and games tend not to run on real-time OSs. If you need the actual time since the game executable launched, for some reason, that's available in other ways. Most games won't, not for the same purpose they'd need delta time, since that time-since-launch is massively impacted by load times. \$\endgroup\$
    – user1430
    Aug 22, 2018 at 16:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .