Small corrections (I learn some things from you as well, how nice, haha): - Using Time.deltaTime in Fixed Update is actually fine in Unity cause it automatically returns Time.fixedDeltaTime depending on where it is called from. - Using Delta Time in fixed update still makes sense for various reasons (it keeps speed to units/second and helps when inaccuracies in the fixed update intervals occur) That means 10 free points to you if your read this, haha. Will keep updating this in case I got anything else wrong. :P

Jokes on you, I multiplied my grade by delta time and now I'm above the maximum!

I just love how He's one of the only devs that instead of showing "what to do" shows "why does it do" which is something so important.

I love the presentation of this video, with an actual test. The whole "YOU WILL BE GRADED JOKE" actually motivated me to do well on this test that no one will see. I've seen many youtubers educate with information, by just telling us the right answer, showing it in examples, with great animations to help visualize. That process works, but I think many content creators forgot how effective it is to challenge our knowledge. At 3:41, despite me using deltaTime in many places, I realize that... I'm not EXACTLY sure which of these four are true. Thank you for challenging my knowledge, and because of that, you've stuck out as a memorable youtube educator. I've subscribed and I look forward to learning more from you.

Now THIS is the kind of tutorial i need, ive had enough of people just telling me what to put in to get my desired output, and i need that perfect level between talked to like a baby, and expecting im Einstein. You hit that nail right on the head.

As someone who litteraly had a math test earlier today on the subject of integrals, this was a great ego boost

6:50 I would say that it's not pointless to multiply by fixedDeltaTime; Makes it easier to code consistent units (say if you're trying to follow SI units strictly, or if you have calculations in both Update and FixedUpdate that should follow the same unit). Also, if you ever end up changing the frame rate of the FixedUpdate, you'll have to change every single calculation.

You think I'm using delta time incorrectly? Well jokes on you, I'm not using it at all. If the game lags, everything goes in slow motion and a pop up appears to insult the player's setup

My score was 100,000,000 * deltaTime . I think i mightve missed something

You actually do want to multiply by fixedDeltaTime in FixedUpdate a lot of the time, to ensure that your speeds are in units per second and the numbers in the inspector actually have meaning. It's also needed for more advanced custom physics, used in the integrations.

21:50 From your testing scheme, it's actually possible to get everything wrong and also the -10 points, leaving you with a grading that is undefined according to your evaluation :P (if I didn't miss anything)

I'm going to contest question 2 based on the wording. The presentation of a frame can be conceptualized as happening at specific instant of time, but the game logic of a frame takes meaningful time to happen. If I just see phrases like "the current frame" and "the last frame" in reference to timing and without further indication, I will interpret that as referring to those spans of time. In the context of timing, frames have a start and an end, and that end is before the frame's presentation. Since each operation can be conceptualized as contributing to a specific frame, the end of a frame is the same as the start of the next. You don't know when the current frame will finish or when it will present, but you do know when it started. A game engine is going to use the most recent frame-time estimate it can, and that would be the time between the start of the current frame and the start of the previous frame. This is more consistent with the wording of option B than the wording of option A, and it is consistent with the wording in the Unity script reference for Time.deltaTime: "The interval in seconds from the last frame to the current one"

Very impressed, you've covered many of the pitfalls. Just two remark: Fixed Update is useful to avoid costly exponent which are very common in Physics calculation because if you have a constant delta time then the linear approximation is good enough (so the "bad" lerp in a FixedUpdate would work just fine). The big drawback with FixedUpdate is that you'll usually notice "jerking" as one frame you'll update 3 times, but then the next frame only 1, then the next 2. Usually to fix this you need to extrapolate the difference between the current frame's deltatime and the FixedDeltaTime.

My solution to deltatime inconsistencies was always "just make sure the game runs at full framerate even on potato computers lmao" but even so, looks like I still have a lot of things to check for and improve in my code when one of the games I'm making is about all about speed and precision with the physics engine. I know someone will try to run the game on a computer that's probably weaker than my already 10 year old test machine, and they'll be counting on it.

GEARBOOOOOOOOX

I think this is a great subject and something that many lack a good understanding of, but in my opinion this video too shows a lack of understanding of deltaTime. My biggest problem with this video's explanation of deltaTime arises in the explanation of why alternative b) is wrong in the first question (around 4:18). This video seems to present the idea that a frame should represent what the state of the program is when the frame is presented, while in reality, a frame represents what the state of the program was when the frame's update function began (when deltaTime was measured, to be precise). This means we're not using "the last frame's deltaTime as an approximation for the current one's," we are instead rightfully using deltaTime as the time between the last update call and the current one, because that gives us the state of the program at the time of updating. This also means that deltaTime does not "always have a 1 frame delay" (5:34) as an explanation for why lag spikes are 1 frame off. Instead, the state of the program that a frame is presenting is always at a 1 frame delay from the current state of the program. There is no special feature of deltaTime making it 1 frame behind. Furthermore, in any well-designed double-buffer renderer, the previous frame should be drawn on the gpu while the current frame is updating on the cpu. Once updating has completed, the previous frame is presented as the current frame, making the presented frame TWO frames behind the current state of the program. (+1 for every additional frame buffer) Other than that, I think this video explains things well and was fun to watch. A quick point to make is that for the explanation of the last question, the idea is presented that an exponential function is essential to achieve the desired result, while any function beginning at 0 and approaching 1 would work, such as 1 - 1/(1 + deltaTime * lerpSpeed), removing the need of Math.Pow. I guess I'll come across as another know-it-all, but I just wanted to share my understanding of the topic and I'll be happy to discuss it further!

I am one of those. I know everything. No need for pen and paper. I already know. Even what I don't know I know... And then some..

If you're not using fixed updates, you might end up clipping through walls from lag spikes, unless you're using rays to assert if the player has moved through a wall between the previous frame and the current.

Someone needs to send this to Gearbox given the new Risk of Rain 2 update apparently commits several of these crimes.

6:05 Objection! The developer may want to change the physics framerate in the future. If you do not account for dt, you'll have a lot of fires to put out every time you change the physics timestep (which some assets actually require). Time.deltaTime will automatically return Time.fixedDeltaTime in FixedUpdate.