Oh man I subscribed as soon as this video started!! Hardest thing to get right in my game library RatorGL was the main loop. As soon as I integrated box2d my physics went to crap before I realized I need a fixed dt. Great job!!!
Why do you put underscores before some variable names? At first I thought it had something to do with maybe constants vs something or something like that, but the ball is technically a constant and you didn't put _ for that so..
I'm not sure how the change you made at the end fixes your tunnelling bug, since you're updating with a fixed timestep in both cases, but you just structured your code differently. Why would you disable the simulation after literally showing a bug caused by poor simulation? 13:25, you are saying its working but didn't even let the ball bounce around enough for the velocity to increase to the point that tunnelling can be an issue. I hope you realize with a high enough velocity, you could still have tunnelling with this implementation, even with a small enough step size. This is because velocity could increase to such a high value that even a small piece of it could force the ball to move past the paddle, this is why I think you didn't include the simulation in your video. Consider learning about ray casting for collision detection or swept AABB.
I like your videos, but sometimes the reasoning behind the mechanics you write are too complicated for me to understand. For example, "(millis-lastTime)/1000" seems like it would produce a number 1/1000th the difference the elapsed time from the last update (where I'm assuming lastTime gets updated), but I'm confused as to why you would do this. (millis-lastTime) alone should be somewhere in the 10^-3 range, why would you increment accumulator by 10^-6? Is that not what's happening? These are just some sample confusions I have when I'm watching you write your software. I'm not sure that I'm alone in this- I think it would be cool if you did review videos where you isolated specific mechanics from your games and went over them in a bit more detail, explaining why something works for those of us who aren't experienced enough to recognize the logic for ourselves. Either way, entertaining video as always, thanks!
The number you get back in the callback placed to requestAnimationFrame is in milliseconds and in my Pong game tutorial, on which this episode is based, I chose to work in seconds because I find it easier to work with seconds throughout projects. If for example my drawing unit is pixels, and I set a velocity to update position using seconds, my velocity number will be in the magnitude of 100s. If I instead use milliseconds it would be 0.1s. I find it more practical to adjust the time once to fit the scale I usually work in, than fitting the scale to time I don't usually work in. In the end it doesn't matter and is up to taste. Thank you for your feedback! I will keep this in mind.
Thanks for taking the time to write me that explanation! I suppose I'm quite a long way off from understanding the mathematical approach you take to things, but I'm sure as I continue to watch your videos I'll figure it out. Have a good one friend.
Nice Video! I like the way you try+fail to guide us to the better solution.
That sounds concerning. Can you extrapolate what went wrong?
I mean that in your video you show the situations where the original solution fails and then make changes to fix it.
+João Lopes ah good golly, thanks. I thought you meant I failed completely at mitigating a bad game timer. :)
epic intro for programming
This is a really good explanation on separating draw and simulate steps. Thanks!
Bro, just for the intro video, I subscribed ... 😍
Just subscribed. Really like your content. Hope you will return back to youtube :(
Would be awesome to feature other games like chess or checkers etc
O Lodriguez same here, he really knows how to explain
thank u very much for sharing these nice works (): and very nice the intro music
Oh man I subscribed as soon as this video started!! Hardest thing to get right in my game library RatorGL was the main loop. As soon as I integrated box2d my physics went to crap before I realized I need a fixed dt. Great job!!!
Best intro 11/10
ill waiting for more !
Heck of a channel name lololol
very nice video!
Awesome! what about a game timer that can queue up work in the threadpool?
Check Norres I haven't looked into that.
Why do you put underscores before some variable names? At first I thought it had something to do with maybe constants vs something or something like that, but the ball is technically a constant and you didn't put _ for that so..
Putting underscores in from of variable names is a common code practice to indicate that the variables are private variables.
I'm not sure how the change you made at the end fixes your tunnelling bug, since you're updating with a fixed timestep in both cases, but you just structured your code differently. Why would you disable the simulation after literally showing a bug caused by poor simulation? 13:25, you are saying its working but didn't even let the ball bounce around enough for the velocity to increase to the point that tunnelling can be an issue. I hope you realize with a high enough velocity, you could still have tunnelling with this implementation, even with a small enough step size. This is because velocity could increase to such a high value that even a small piece of it could force the ball to move past the paddle, this is why I think you didn't include the simulation in your video. Consider learning about ray casting for collision detection or swept AABB.
I like your videos, but sometimes the reasoning behind the mechanics you write are too complicated for me to understand. For example, "(millis-lastTime)/1000" seems like it would produce a number 1/1000th the difference the elapsed time from the last update (where I'm assuming lastTime gets updated), but I'm confused as to why you would do this. (millis-lastTime) alone should be somewhere in the 10^-3 range, why would you increment accumulator by 10^-6? Is that not what's happening? These are just some sample confusions I have when I'm watching you write your software. I'm not sure that I'm alone in this- I think it would be cool if you did review videos where you isolated specific mechanics from your games and went over them in a bit more detail, explaining why something works for those of us who aren't experienced enough to recognize the logic for ourselves. Either way, entertaining video as always, thanks!
The number you get back in the callback placed to requestAnimationFrame is in milliseconds and in my Pong game tutorial, on which this episode is based, I chose to work in seconds because I find it easier to work with seconds throughout projects.
If for example my drawing unit is pixels, and I set a velocity to update position using seconds, my velocity number will be in the magnitude of 100s. If I instead use milliseconds it would be 0.1s. I find it more practical to adjust the time once to fit the scale I usually work in, than fitting the scale to time I don't usually work in. In the end it doesn't matter and is up to taste.
Thank you for your feedback! I will keep this in mind.
Thanks for taking the time to write me that explanation! I suppose I'm quite a long way off from understanding the mathematical approach you take to things, but I'm sure as I continue to watch your videos I'll figure it out. Have a good one friend.
my ears... fuck