Can you do more of these please?, Maybe an episode on debugging or finding code related problems that don't seem to have an answer

dont these 2 corrections contradict eachother? or am I being dumb xD If deltaTime returns fixedDeltaTime while in the Fixed Update, then how can it keep speed to units/second and help inaccuracies?

@@blockify no because fixedDeltatime takes the inaccuraties and inconsistencies in fixedupdate into account, and deltaTime gives rhat fixedDeltatime. Point is in fixedUpdate fixedDeltatime==DeltaTime. There is no difference using one or another. Still, using either one can be helpful to get around inaccuraties(which can happen in fixedupdate if u use neither)

​@@blockifyif it helps, you can think of multiplying by deltaTime or fixedDeltaTime as a sort of "per frame -> per second" conversion in unity! (You can also convert the other way by dividing by deltaTime, e.g. if you want to get the amount an object has moved in a single frame, you'd divide its velocity by deltaTime since in Unity velocities are usually per second)

It doesn't return fixedDelta time. If we go back to what I said in another comment, the correct answer is not A in fact non of the truly was the right answer. delta time is the time it took to process the last frame, the documentation backs this up. So when you run that in FixedUpdate, that means the normal delta and the fixed delta will be the same value, but one does not simply return the other. Physics is a fixed step, therefore both are going to equal the same value!

I recall when I got into Math 251 Differential Calculus, I thought it was going to be some pretty insane shit, but it turns out we use it all the time without even realizing it. It's just so much more powerful if you know the fancy tricks. I cannot recommend enough that those who don't know at least differential calculus to learn it. You will not regret it.

​@@nobody.of.importance*sigh* FINE. I'll go learn differental calculus this month.

@@gogauze im learning it in the fall

@@gogauze Knowledge is power! Good luck! Same for you Nidhsa c:

this is not only integrals, this is discrete integrals!

Fair! :)

The physics will actually break if you change Time.timeScale and don't multiply by fixedDeltaTime, because fixedDeltaTime will change with the timeScale. Meaning it's actually not always the same value, if you have any kind of speedup or slowdown with timeScale in your game.

Just want to add that the code example did not need to be changed at all to be called for FixedUpdate. And that is because Time.deltaTime actually returns Time.fixedDeltaTime when called from within FixedUpdate.

@@ThePhoenix107 Cool to know, but I'll still stick with fixedDeltaTime for consistency and clarity.

​@@zelos666it actually is the other way. The fixed delta time stays the same, but anything running in fixed time will become more granular in real time because fewer fixed steps will occur between frames. This is why you might need to reduce your fixed time step for slow motion. If you are modifying your fixed delta time for this purpose then you definitely need multiply by it in fixed update.

correct me if im wrong but, this will only happen if you use a rigid body controller, not for example the player controller asset, also you dont need to code a ray check as you can just set the rigid body to 'continuous' or 'continuous dynamic'

im literally so new at game dev, im just pretty much using everything in fixedupdate, and what needs to execute fast for example key pressed in update, idk if its fine but it works fine, example in my game this: void Update() { if (Input.GetMouseButtonDown(0)) { isShooting = true; CalculateShootDirection(); } else if (Input.GetMouseButtonUp(0)) { isShooting = false; } if (isShooting) { CalculateShootDirection(); } } void FixedUpdate() { if (isShooting) { shootTimer += Time.fixedDeltaTime; if (shootTimer >= shootingDelay) { Vector3 bulletVelocity = bulletSpeed * shootDirection; GameObject bullet1 = Instantiate(bulletPrefab, bulletSpawnPoint1.position, Quaternion.identity); bullet1.GetComponent().velocity = bulletVelocity; GameObject bullet2 = Instantiate(bulletPrefab, bulletSpawnPoint2.position, Quaternion.identity); bullet2.GetComponent().velocity = bulletVelocity; float rotationAngle = Mathf.Atan2(shootDirection.y, shootDirection.x) * Mathf.Rad2Deg; bullet1.transform.rotation = Quaternion.Euler(0f, 0f, rotationAngle); bullet1.transform.Rotate(Vector3.forward, 90f); bullet2.transform.rotation = Quaternion.Euler(0f, 0f, rotationAngle); bullet2.transform.Rotate(Vector3.forward, 90f); shootTimer = 0f; } } } private void CalculateShootDirection() { // Calculate the shoot direction based on the player's transform shootDirection = bulletSpawnMainPoint.up; // Assuming the player's forward direction is along the X-axis shootDirection.Normalize(); }

Orange grenade lifestyle

Neutral Milk Hotel

so that’s how i fix that.. too bad i’m already making a new player controller

I feel like springs are better expressed with approximations in games.

Is a second order taylor series the wrong thing to do here?

@@drstrangecoin6050 It depends. For springs or gravity (N-body sim) to get stable results Taylor series won't be enough. You would need implicit methods for accurate and stable results (too slow for real-time). But for games springs could be done without forces in more stable way (e.g XPBD). Stability of gravity forces usually not an issue unless you're doing Solar system simulations or the like (in which case parametrized elliptical orbits may be better option for game). For a game maybe first check implicit Euler and then XPBD if it fails, otherwise start faking it.

Implicit is used all the time in games. In fact they showed a common example in the video … velocity = velocity + acceleration * deltaTime position = position + velocity * deltaTime 2nd order Taylor series is fine for most use-cases. If you have to support some wildly stiff springs or need a high degree of accuracy then you could try rk4. p0=initialPos r=restingPos v0=initialVelocity k=springStiffness dt=deltaTime m=mass f1=k*(r-p0) // force v1=dt*f1/m+v0 p1=0.5*dt*v1+p0 f2=k*(r-p1) v2=0.5*dt*f2/m+v0 p2=0.5*dt*v2+p0 f3=k*(r-p2) v3=0.5*dt*f3/m+v0 p3=dt*v3+p0 f4=k*(r-p3) v4=dt*f4/m+v0 v_final=v0+(f1+2*f2+2*f3+f4)*(dt/m)/6 p_final=p0+(v1+2*v2+2*v3+v4)*dt/6

Performance cost is relative as well. It’s all about scale of use. If you wanted a 3rd person spring arm camera and it needed to be super stiff/snappy one use of rk4 would be fine. However if you are setting up a dense foliage section where foliage physically interacts with the player then you’d probably just use a simple implicit approach with v_final=v0+dt*k*(r-p)/m p_final=v_final*dt+p0

Negative F!

being undefined, there's every chance we hit a negative integer overflow and land on a grade no less than 150

In this case I think you can just give yourself 4294967285 points

Spoken like a true game tester!

@@madmax404 the only winning move is not to play

For future reference: It *piqued* your interest.

@@superscatboy Maybe his interest curve reached a local maximum, so it really did peak his interest.

@@oisyn- Or maybe that's just a load of old bollocks 🤷‍♂️

​@@superscatboy Well, my interest definitely *peaked* when seeing the title of this video

@@baitposter So your interest decreased when actually watching the video?

Thank you.

wtf this is exactly what I just wrote lol. With a lot more fancy words sprinkled in though

it won't auto use the fixed delta time, the timing will just be identical.

It's not only in the latest Unity version. I recall hearing about this behavior at least several years ago.

Wow that's kind of terrible API design. Would be a lot better if using deltaTime in fixedUpdate were an error. Implicit/hidden behavior is an evil that you might expect to see in the realm of web dev frontend nonsense, but not in applications programming.

In my opinion, the best API design would be to have the delta time as argument to the update functions, that way it's impossible to mess it up.

Unity's API design choices are notoriously bad. Thankfully once you learn all the shitty things and minefields it's full of, you can safely ignore it and build up your own software more robustly. But be warned, Unity is a hell to learn.

Are you saying you did position = lerp(startingPosition, endingPosition, 1-cos(x*pi)/2)? Because that would cause it to go back and forth between the start and end, not approach but never reach the end.

@@bastian_5975 It should probably be cos(1/(x+2)*PI), which is really just a differently smoothed version of 1 - (1/(x+1)), where x is elapsed time in both scenarios. (There's an absolute ton of "sigmoid" functions you can use to infinitely approach a number.) The delta-time lerp works though, just it makes a little less sense logically because instead of lerping between two fixed points, you end up lerping between the destination and the previous location.

@@gajbooks at first I thought you meant cos(1/(pi*(x+2))), but cos(pi/(x+2)) looks so much better that I think you mean that. And are you saying that the function you defined was a sigmoid function or that sigmoid functions are a class of functions that also achieve that effect?

yeah, btw for those that don't know, the equivalent of FixedUpdate() in Godot is _physics_process().

​@@lukkkasz323isnt it _physics_process(Delta)

Yeah, thankfully stuff like this is pretty engine agnostic. Once you know how one engine works, a lot of it is easy to carry over to others, at least from a technical perspective.

I'm also a Godot user, and I know that Update() is "_process(delta)", and FixedUpdate() is "_physics_process(delta)"

ive also never seen someone mult everything by delta time in a godot tutorial

Or avoid FixedUpdate() altogether and call Physics.Simulate() by yourself in Update() after disabling automatic PhysX Update. Actually the only method I know to avoid Unity's microstuttering.

Lol

Haha. Oh, no. :D

haha i too didn't realise for ages because since I never did anything big scale the fps stayed relatively consistent

same with us lol tested it out by racing each other in different refresh rates haha

For this reason, I would use Math.Exp(-lerpSpeed * deltaTime).

Just want to point something out here, cause this kinda bothered me. You are correct in that the reason for the deltaTime being in the exponent is so that they add to 1, but the total distance covered is NOT just the product of the blends. You can easily see this if you use a base other than 0.5. Assuming you have the function laid out like Jonas did, where the target position occurs when the blend is 0, then the position of the snail after n frames is going to be (target_position)(1 - (product of all the blends)). You can deduce this through induction with the lerp function. Lets say that our blend is 0.1 ^ 0.25, where the 0.25 is our deltaTime, just like in your example. Initially, the snail's position is 0. After 4 frames, or 1 second, the snail's position will be (target_position)(1 - (0.1 ^ 0.25) ^ 4) = (target_position)(1 - 0.1) = 0.9(target_position). After 4 frames, the snail moves 90% of the distance, not 10% as you implied. Fundamentally, what you're saying is helpful, but I saw the comment and got caught up on that snag for a while, and it kept me from truly understanding what was going on. Also, I agree with @NXTangl, using the built in exponential function is nice because then you don't have that arbitrary base and the speed is more directly controlled by lerpSpeed.

> So in the video this number (lerpspeed) is 0.5 which means the character covers 1/2 the distance to the goal every second No, in the video you cover 0.3 of the distance every second because of that number (lerpspeed) being 0.5.

@@feha92 No, "this number" refers to the base of the exponent, which is 0.5 in the video. I also say that I'm setting lerpSpeed to 1 for simplicity. lerpSpeed is also 1 in the video IIRC, so I'm not sure how you mixed that up. Edit: actually, lerpSpeed is 0.5 in the video, so it makes sense you got mixed up. But I still said "if lerpSpeed is 1".

@@pixelz3040 You're right, the base of the exponent is the portion _remaining_ after one second, not the portion covered. Those two numbers just happen to be the same when the base is 0.5, my bad. I personally still like to use the arbitrary base because the meaning of the base is clear when the exponent is 1, and I don't want to think about a base of 1 / 2.718. lerpSpeed controls the speed the same way in either case.

If your engine is developed properly, DeltaTime should be tied directly to the update of a frame. Most modern engines (Unreal Engine, Unity, and most AAA Engines) tie DeltaTime directly to the update of every frame. This by definition means that each tick is tied to the update of a frame. In the scenario you presented this is not what happens. If your actual frame update is not in sync with your refresh rate on your monitor, you'll typically see frame tearing (since almost all engines will queue at least a frame in advance in the back buffer and update the screen on each refresh). Screen tearing happens since the new frame that was in the process of rendering in the back buffer is being pushed to the screen in an incomplete state. Microstuttering really happens when you're close to the target refresh rate. Since there's some variability in each frames workload (both on the CPU and GPU), frame completion may not fall exactly on the expected interval to update (ie 1 frame may have taken 17ms rather than 16.5ms to complete rendering). In order to avoid this, a lot of devs will try to exceed performance from the target enough to minimize Microstuttering. It has nothing to do with updating your game with variable DeltaTimes. It has more to do with frame consistency.

True, although this makes the difference between explicit (forward Euler) and implicit methods (backward E, C-N) appear very similar, since there is only a time dependence here. Normally you will need to solve a system of equations, which makes the thing inherently stable. A good example is the exponential speed case, where an explicit method can easily overshoot.

Just to add on to your comment, the video is wrong here as per reasonable definitions. The term 'current frame' always refers to the one you're currently processing. 'deltaTime' is calculated at the start of the processing of the current frame by comparing the time to the time the previous frame began processing. deltaTime is essentially how long the last frame took to process from start to end (where 'end' is the start of the current frame). "Time elapsed between the last frame and the one preceeding it" is a not a good definition of deltaTime because the frame before the last one has no relevance. The current frame's deltaTime value is calculated in the current frame and not at the end of the previous one. As per Unity's own documentation for Time.deltaTime it says it's "The interval in seconds from the last frame to the current one". I believe the error is largely due to representing frames as a point in a timeline when something is rendered on the screen. At some time, typically very shortly after that rendered frame point on the timeline, the deltaTime value will be calculated. The only relevant frames in the calculation is the previous frame and the current frame. Carrying on from this the video then describes deltaTime having a "1 frame delay" which is also stated and described confusingly. Obviously deltaTime is not going to be related to how slow the current frame is because it can't predict the future. So the best value it actually could be: the previous frame's calculation time, is essentially what it actually is. Describing that as a "1 frame delay" doesn't really make sense. Obviously here the video is referring to deltaTime in relation to something moving on screen and pointing to how the object moves only a little bit on screen on the frame that took a long time and then has the larger jump on the next frame. Saying that "deltaTime always has a 1 frame delay" because of this particular example is not reasonable. deltaTime is not delayed, it is the correct value for when it was calculated. Nothing prevents a programmer from calculating their own deltaTime equivalent value and moving objects with that right before rendering. Time.deltaTime is not delayed, you have just chosen to use it in a way that gives a result that you refer to as having a delay. If anyone was confused by the 1 frame delay part of the video and curious, the way the deltaTime value would work after a slow frame is is: If a game was running at 60FPS on Frame A, Frame B's deltaTime would be ~0.0166s. That's how long it was from the start of Frame A to the start of Frame B. If Frame B was then slow and took 0.1s (10FPS) to complete, Frame C's deltaTime value would be 0.1s Basically the frame after the slow frame would see the larger deltaTime value. Not a bad video otherwise, but that section in particular I think would be very confusing to programmers trying to learn about deltaTime. I believe conceptually it's essentially correct, but by representing frames in relation to deltaTime in that way and slightly misrepresenting when deltaTime is calculated it makes something fairly simple much more confusing.

I understood it that way too, thanks for confirming! +10 points to me!

And I just want to say that I don't like leaving some big comment like that, I just needed to write that much to explain everything. Obviously Jonas seems to be great at what he does and has made an excellent video. I know I'd hate making videos like this because it'd be very had to not make errors or poorly represent some things even if you know them well yourself in reality. I'd not want to have to see comments like mine above, but know that it's only left in the interest of helping clarify those elements from the video for anyone confused or off-put by them. I'm sure you (Jonas) understand what I've explained yourself and just (in my opinion) didn't express them adequately in that small part of the video.

@@mcarr87 Your comment is far more confusing than the video is. There are a few reasons for this. Firstly, there are two entirely contradictory definitions of a "current frame" at play here, which you don't seem to realise. On their own, both definitions are valid, but the one you present here has some issues in its broader context. You seem to define a "frame" as the routine that runs to produce it. In that sense, the current frame is indeed the one you're processing. But then a frame is a process and not a point in time. This contradicts with the definition of deltaTime in the Unity documentation you quoted, "The interval in seconds from the last frame to the current one". That one notably _does_ define a "frame" as being a point in time, as evidenced by it not saying "from the _start_ of the last frame". One important problem with your definition is that updating the game state is not linked to visuals whatsoever. A game could poll for inputs twice as often as it renders a new frame. These are still two game updates, but there is only one frame rendered. If you define a frame as a process, you'd have to exclude the time spent updating the game state, and only include the rendering time. But that's demonstrably not the value that deltaTime contains. The other definition of a frame is "the image being shown on the screen". This is a far more intuitive definition, and how most people understand such terms as "fps". There are 60 images being shown to me per second. And whatever is being shown to me at any given time, is the "current" frame. This frame is shown to me all at once and does not change afterwards until the next frame arrives. Thus, the moment it appears on my screen is a single point in time and not a process. Reading the definition of deltaTime again, this makes a lot more sense. Because the "current frame" is what you just finished. And deltaTime is indeed the space between those points in time by all definitions. You say that the way this definition is worded in the video is inaccurate, but that is simply not true. "Time elapsed between the last frame and the one preceding it" is a perfectly valid way of describing it, so long as you take "last" to mean "most recent" over "previous". The current frame is the most recent frame, and therefore the current frame can also be described as the last frame. This is not a strange way to use English, and should not be confusing for someone who speaks the language well enough to watch English videos on KZfaq and writes English comments. Additionally, I strongly disagree with that a "1 frame delay" is a bad way to describe what happens. Of course, the variable itself isn't delayed. Because it's defined with that delay already built-in. If I told you what I ate yesterday, my statement isn't delayed by one day. But that doesn't mean that your knowledge of what I ate isn't! The latter is the "delay" the video refers to. The example is clear about this as well: the frame shown after the lagspike does not take the lagspike into account exactly because that frame is being calculated as if it will render in the same amount of time that the last frame did. Regardless of what you're actually building, it is theoretically impossible to react within 1 frame to the time it takes to render just by reading the deltaTime variable. In short, it takes exactly one frame before you can react to how long a frame takes to render. I'd like to ask what you would describe this effect as, if not a "1 frame delay." This description has nothing to do with motion; it's a factual description of what you observe when you look at the game frame by frame. It takes one frame to adjust to a frame taking longer to render. You cannot adjust immediately. This is the definition of a delay. Don't get me wrong, I agree that there are ways in which the video could have been clearer. I just don't think that the things you take issue with are the problem, and that the alternatives you provide make things less clear rather than more clear. What the video really needed is not a change in definitions, but a more precise and consistent use of language. "Last" and "current" typically have the same meaning, but it'd be clearer if you stuck to one. It'd also be helpful to distinguish a "frame" as what's being shown, from an "update" as being the process to create it. And possibly a few other similar things. The content and presentation itself is fine and doesn't need to be changed, the script for the video really just needed one more editing pass.

@@Gamesaucer I appreciate your arguments and while I don't disagree that much of this depends on your particular definition, I don't agree that in this context of programming the definition of 'current frame' would only refer to the frame most recently output to the GPU. While not used too commonly as a direct term in the Unity docs and variables, you'll only find "current frame" referring to the one currently being processed that would next render (e.g. OnDemandRendering.willCurrentFrameRender) unless referencing something selected in a timeline like in the Profiler. Also I was directly referring to where the video's uses the phrase "the frame currently being processed". I 100% agree that a frame can and often does refer simply to the image presented to the screen, and the duration of that image on the screen in a standard, single buffered game would be determined by how long the following frame takes to update and render. That's not in question. But you bring up a great point that I didn't bother with because I'd already written too much before, and that is how a game could have multiple Updates without rendering a frame if it wanted. Alternatively you could have things like double or triple buffering that could delay the rendering of a frame until after other queued frames had rendered. To me, both of these are great arguments for my point. First, going off your concept, lets say you're in Unity with a disabled Camera object and you manually called Render() every 3rd frame. Here you have 3 Updates over 3 frames (as per Unity's definition of a frame. See e.g.: "Update[()] is called every frame") where only 1 of them is something drawn to the screen. You also have 3 different deltaTime values across those frames, 2 of which can't be said to have any relevance to what was drawn on screen last. You could also run your game's multiplayer server without rendering anything ever and it still has deltaTime and what most refer to as a frame rate (including Profilers, etc). You could argue that without rendering anything there is no 'frame rate' if you wanted, but that only diminishes your arguments because deltaTime still exists and is still calculated in the way I said it was without any relevance to what was drawn or if anything was drawn at all. The same type of example can be given for multiple buffering of frames where the deltaTime does not relate to what was last drawn on screen. I don't think in the context of programming your point "the moment it appears on my screen is a single point in time and not a process" has much validity. For one, saying a frame is a point in time doesn't really relate to the concept being discussed which is to do with the duration of a frame. Secondly even if you were to try to talk about it as a singular moment in time, what moment is that? When the LCD monitor draws the first line or the CRT's electron gun starts emitting or when the end of the image is finally displayed? What if the frame rate is faster than the monitor and it never finishes? I know that's overly pedantic, but it's just to illustrate that that is not a consistent or really even well definable thing and doesn't actually relate to actual programming and deltaTime. I don't really want to continue, but I'll quickly address your points on "1 frame delay" which I also find a bit odd. Saying what you ate yesterday is completely different from deltaTime. When deltaTime is calculated by Unity when a new frame begins processing, that is not a value telling you about something from the past. That is an immediate, current time difference between right now and back then. If it's referred to on the next line it's extremely current and relevant. You could say it's less 'current' later in the frame processing, but that depends entirely on how it's used. This is why I mentioned how you could use your own delta time calculation for rendering if you really wanted something more current for the frame you're processing than deltaTime. To say it has a delay is to proscribe a very weird definition to it. It is what it says it is and it does not give a delayed value at any point after its value is set. It's always 100% accurate as per what it is defined as being the value of. You know immediately at the start of processing a frame what the time the last frame took, there's no delay. That's the point of the value. To say it has a delay would be to give it the definition of "this is how long this frame will take, but you won't know until next frame because it has a 1 frame delay". I feel like this sort of discussion comes across as antagonistic and I apologise if it comes across that way. I also expect this could be one of those things where it's an ongoing back and forth, but I don't want to do that. I will freely admit that there's validity to the video's way of putting it and taken with certain definitions it's not wrong. This is what I said in my original post. I just don't believe in the context of programming, which this is, it was stated in the most valid and coherent way.

Please elaborate. I've wanted to implement multiplayer in the future so any hiccups or things to consider is really useful.

.

@@magnusm4 multiplayer you can't just use deltatime for each pc because everything needs to be synced. So you need a main computer (which could be a player too) that does the calculations, and the players' pcs need to display that information. But frames can't be involved in the calculations of the variables, otherwise things would move really weirdly. You need the numbers sent to the pcs, and the pcs to render that information using deltatime, because you need to get the correct number for that point of time based on when the individual player's frame renders. And the rendering calculations are gonna need to be precise otherwise objects are going to appear in the wrong spot because if the calculation is off the number on the server is still correct, but it's displayed incorrectly on the player pc.

​@@IONProdAnd this is the reason why so many beautiful indy games lack multiplayer support. It's really hard to do properly.

i dont think this has to do anything with coding. more like high school physics and how delta time on game engines work with a very very simple explanation.

@@Fix-- Why did you get scared away? If you didn't understand anything, I want to say that it's completely normal for a newbie to not understand like 70% of the video. To be able to take something from this video, you need to have basic knowledge of C# (at least be able to write a quadratic equation solver), basic knowledge of Unity (at least what GameObject is, what MonoBehaviour class and its methods are and a rough idea of how physics work in Unity), a good school level math and some calculus knowledge. Besides, you have to have tried to make a character move to encounter the problems Jonas is talking about.

Please when is thronefall dropping on PS4

I got grade c! (Being a beginner programmer that can't even make a simple player movement script lol)

F, because I didn't write down my points. I did okay but it counts for nothing :P

F i got 10 in the second question and ten in another and then lost ten

Grades are of no importance

Always.

That's a useful addition. Good to know.

@@JonasTyrollerthis comment should be pinned tbh

yep absolutely, once was having issues with the precision of physics collisions in a project I was working on so I had to bump up the fixed update rate to help solve it. I use fixedDeltaTime in my workflow for exactly cases like that, I might have had to rewrite weeks of code otherwise

You can even modify fixedDeltaTime at runtime.

Hey you seem to understand this. can you explain why he used .5f as if it means half? isn't that hexadecimal for 95? isn't he trying to get half the acceleration for the first part of the frame and half the acceleration for the second half of the frame? if that's the case why didn't he actually just use .5? And if he wasn't trying to get half, doesn't that mean the snails would've accelerated quicker than they were when it was just one line? was the point not to get them to move the same speed but split the acceleration addition up so that it would get an average of the frame start and the frame end acceleration? to be clear, i need no explanation of delta, i understand how it works. I just don't get this bit. about splitting the acceleration into two. i get why he does it, cuz i understand why you wouldn't want the acceleration from before nor the after, but rather the midpoint of the two, i just don't understand how multiplying by .5f gets that, unless .5f is in fact just .5, but it seems like it's hexadecimal for 95 edit: oh my god, i was right the whole time it is just 1/2. 0.5f is unity notation for floats. that was so confusing as someone who uses godot. correct me if i'm wrong

@@dexlovesgames_dlg yeah, f is the suffix for "this is a single-precision float, not a double-precision one"

Ohhh i also missed that! I need to go edit my comment now

The lerp is from the current position, not the starting position.

I think this is an ambiguity with the phrase "current frame". In the video, he means the frame that hasn't been displayed yet, and the "start" of that frame is when it is displayed. But most game developers think about the "start" of the "current frame" as when the previous frame ended and the frame is displayed at the "end" of the frame rather than the "start".

Good catch :)

The sad thing is that teachers make a terrible case for learning calculus, algebra, and geometry, usually throwing only rocket science as an example. I went through the classes just fine but never understood why I should learn the material and could never discover a legit use case for it. That is until dealing with graphics and games, at which point I heavily regretted forgetting most of what I had learned.

I'm with you, but schools don't seem to have an interest in teaching "real" math. It's all just about calculating numbers, like robots. Studying physics was an absolute eye opener for me. There I got taught math on a more fundamental level, which really made it click. I'm still wondering why they don't teach axiomatic systems, logic and set theory in schools and let the students be creative for once. The basics actually aren't that hard. After having achieved some knowledge of those topics, calculating stuff, even derivatives and integrals, which are the highest level topics in schools, becomes piss easy.

We thought you perished!

use * 0.5f

Correct me if I'm wrong, but the first method (which is the same as you provide) is called the forward Euler method, which tends to artificially adds energy to the system the further it goes. Updating speed before position (the sympletic/semi-implicit Euler method) or adding half before and after (the midpoint method, which equates to 0.5 because he is using a linear function) tends to be more stable (the error is bounded)

To be clear: It's not just the same result but it's also the same mathematical formula, except not applied with intermediate state (only modify speed once). It's easier to see if you simplify the formula to: transform.position += Vector.right * dt * (speed + acceleration * dt/2); speed += acceleration * dt; And then pulling out the acceleration term to apply to speed makes looks like Jonas' code: var boost = acceleration * dt/2; speed += boost; transform.position += Vector.right * dt * speed; speed += boost;

​@@mrnowhere-sc3mvFor anyone who wants to go deeper on this math, "Math for Game Programmers: Building a Better Jump" goes into Euler integration, Velocity Verlet, and concludes simplified Verlet (the same result we have here) is a good compromise: kzfaq.info/get/bejne/nq1pht2C3cennWw.html

So, is the reason the lerp was looking exponential causes by the fact he use transform.Position, which got the current position, instead of the start position which never changes, so it should be a constant, somewhere outside the update function?

@@pepperdayjackpac4521 Yes it wouldn't be exponential if he sets the initial position. You can test yourself to see.

give up (just kidding, keep on learning)

Make it less simple, stick it into it's own function. There, nice and readable in your normal code

2fps was just an example. You can have something that accumulates overtime because of wrong deltaTime and gets messed up. For example I had a character controller that would get slower and slower as the frame rate drops and below 15 it would stop moving altogether. See what I mean

This discussion about the mathematical correct version of lerp is a relatively recent topic in the indie bubble and no one was doing it that way before, without anyone ever noticing a problem, that's how big of a deal it is. I don't stop anyone from using the more complex version, I'm just saying that I myself stick to the easy version 🤷

@@TackerTacker I use a tweening library that takes care of it. But no it has to be correct because it becomes very noticeable when frame rate drops even a little bit

@@stickguy9109 I think you mean something different than I do. By approximate version I mean "lerp( a, b, lerp_speed * delta_time )" not no delta_time at all.

I don't think there's necessarily anything wrong with using a lerp in this way. As long as you're careful to acknowledge that you're using the lerp as a building block for your own primitive exponential easing function, and make sure to do it right, then that's probably one of the simpler and more transparent ways to think about implementing one. "I want the distance to half every X time" > "Lerp is an extremely simple way to get the halfway point" > "Here's how I can modify the lerp implementation to be robust to changing update rates". You might be reinventing the wheel a bit, but if you're more familiar with the math than the engine, it works out just fine!

@@EpicGamerScout It has the distinct issue of having to snap the object to target position after the elapsed time, leaving us with about the same amount of code though.

Same thing, was hella confused when he didn't put in a time counter until I've noticed that the start position is not a constant one

Negative F...

Jokes on *you*! You multiplied your grade by a number almost certainly less than one! Your grade was lowered to a fraction of what it would've been! Unless you run with less than 1 FPS in which case the joke would again be on Jonas...

@@lFunGuyl I'll take the risk for a shot at glory!

lol

Genius solution. We should all start doing it like that!

@@JonasTyroller just finished the video, it was greatly informative and entertaining, thanks Jonas! Sorry about the meme comment hahahaha

many games use this, killing floor 2, the enemys keep doing repeating the last action so if its walking forwward and lest say the internet goes down, for 4 seconds, it will keep walking forwards for this 4 seconds while its down (u can lag switch test this) when internet resumes they will smothly move to the correct position, terraria does this as well and many other games i know does this, these two games use prediction and interpolation,.

i chose d because i thout it made scenes... i already know thats its the ammount of lag