It's worth mentioning that this video doesn't show how smoothly the rectangle moves (probably because of RUclips's video compression, I don't know). But it's definitely worth following along in this example to see how to achieve smooth motion! Before watching this, I was always a bit frustrated by the occasional jerkiness of object motion in Pygame--no matter what frame rate I used. This fixes the problem! If you care about smooth motion in Pygame, learn this technique!
This is such an elegant explanation. Just wanted to add, that I had fun adding my scaling factor to the speed as well. My game is using a standard 320x180 pixel art canvas then everything is scaled up 4x or 6x (or less for fun). The scaling was only applying to the image sizes but now I am adding scaling to the speeds. As I understand it, using dt also simplifies the choice of speed as a value basically translates to pixels per second. Therefore, I have to correct it with my 4x or 6x scaling. (Don't want 100 pixels per second on a 320 screen AND a 1920 screen). Very satisfying
Attention at 4:50. The example there is about "fixed time", and does not count difference between frames. This could led to confusion if you implemented it in your code, expected that everything multiplied by that just "move correctly" (since it will not). To correct, you need to take your system's "now" time, subtracting "last_draw_time" from it. The result is the right value of the delta time that you can multiply. This value will have to (maybe) be elevated to some power of 10, just to reduce precision. But it works as expected.
This is exactly what I was looking for. Almost ALL tutorials handling movement and jumping using frame dependant code and it's always bothered me. They do not even touch on the topic of accurate movement. Today was watching a tutorial on jumping and they set jump_height = 15 (steps aka frames) then were monitoring a variable called jump timer counting frames and once you hit 15 you'd be at max height... But just like you explained if you ran this game at 600 fps... it would happen at light speed and you'd only jump a fraction of the height you'd jump at 30 fps. This is a such an important part of a game's development and I do not see anyone talking about this. I'm glad I found this video and am not going crazy lol.
*Review*: ok, so by multiplying the desired speed by Δt each frame refresh, this enables you to scale the speed traveled each frame according to the hardware fps. so. Each frame refresh the motion would actually be different with this formula. *but* since there are more frames being output at 120fps vs 60fps, over 1 second the lower motion per frame should normalize to a constant value
Thanks RUclips recommendations for this.. I've tried to make this already since August 2021 and didn't know how to solve it. Thanks you, man, you are really cool
Another solution or addition: Have two update methods. One for logic and the other for drawing. The drawing loop should run at computer speed while the logic loop should run at a fixed interval ideally 30-60 times a second
It's a bit easier to do that now in Pygame-CE thanks to frects, which are rects that use floats instead of integers, so you don't need that extra variable for the position.
i thinck you can skip most of the second part ,because with new cpygame you can make "FRect" instead of "Rect" and it will do the work with float numbers as well (this video is for 2022, in his newer videos he said you should use the FRect almost every time)
Very good content, and good advice from some comments. I may just add not to call time.time() twice, you are losing a (very tiny) amount of time between the two. Use a variable current_time that you use throughout all the current frame. This includes body loop and passing the variable to function that want the current time.
Generally a very good video and helps a lot to grasp this really important matter, but you erroneously built the table from 5:50: 0) 1/30=0.033, not 0.33 etc. 1) units are wrong. On the left site you've got 1/s*pixel*s=pixel, whereas on the right site you've got pixel/s. 2) The variable you calculate in the table is just covered distance i.e. Δx, not Δx/Δt. 3) You indeed want to have the same Δx/Δt regardless of FPS, but to have it constant 4) You need to have various Δx and Δx/frame. For instance, since Δx/Δt=Δx/frames*frames/Δt=Δx/frames*FPS, if you've got FPS=10 and you want Δx/Δt=100 you must have Δx/frames=10 and Δx=10 in every frame, but if you've got FPS=30 and want Δx/Δt=100, you must have Δx/frames=100/30 and Δx=100/30 in every frame. Thus Δx/frames must differ.
Thanks. I think what is missing is a standardised formula for speed from, oh, say, a speed variable value for 60 FPS to one for 1000 ticks per seconds. It would help us slow learners to get a handle on what he attempting to explaining. I'm not sure that "CDcodes" does it any better. Both make some logical leaps without more thought/examples/whatever. The following is stream of consciousnesses, feel free to ignore. Given his maths, I was attempting to determine just what the various speed numbers actually mean. Does "speed = 250" mean I want this object to move 250 pixels per second (as 1000 ticks =~ 1 second)... But there is some slop in his maths (or my head) that I'm just not getting (admittedly I'm a bit tired and a bit drunk 😇). I would like to not guess as to what the speed numbers mean and have to use (more then the normal) trial and error to determine them. If my standard game used 60 FPS, then there should be a pretty well defined formula for converting from the speed numbers I used with 60 FPS and the speed numbers I use for 'dt'. i.e ((original_speed * 60) / 1000)) No...that's not right. It should be just (original_speed * 60) and the 1000 ticks per second will take care of themselves, once you invert it (1/1000). Because I use both a fast Windows 10/HP laptop and (my preferred development environment) a relatively slow Raspberry Pi 4 (64 bit Debian)... this kind of thing is actually important to me.
It really doesn't matter I'm sure, but I set new_time to the time, calculate the delta with new_time then set last_time to new_time that way I can't possibly loose time between the two lines that call get time.
I know this is old, but i have a lottle bit of a tough time understanding the exact math of this. Wouldnt delta be a measure of the amount of time per drame (sec/frame as the units). So wouldnt multiplying pixel/frame * frame/sec * sec/frame result in just pixels as a measurement? So then we arent really deifning a rate? I totslly get the explanstion if delta doesnt have a unit, but i don't understand why delta is just a scalar woth no unit.
You don't want to tie animation to a specific frame rate. In other words, you don't want to hard code an animation to run at 30 fps because it will run twice as fast as it should at 60fps and 4 times as fast at 120fps. This is why a lot of old PCs had a "turbo" button on the case to toggle the CPU between full clock rate and a slower clock rate. A lot of old games and software didn't limit frame rate in code and didn't really take frame rate into account, so e.g. an old PC game would run at an unplayable 900 fps on newer hardware and characters and enemies would move around at light speed and music would be on fast forward or would just break.
I am not an expert in this but what if we use an OOP like structure and call the update function x times per second and to get x we do something like calculating delta time. something like using dt to calculate how many times we need to call update(). this way we dont need to mutiply everything by delta time
Hi, I'm a beginner in programming and I'm trying to code my first mini game with the great help of your video 'the ultimate introduction to Pygame', but I have encoutered a problem with the framerate ; is there a simple way to reduce or remove the kind of lag when you run a simple animation ?
@@firnyx I struggled with the same problem until I watched this video. By using dt (delta time) as described, and (this is mportant!) keeping test_rec_pos in a separate variable including the fractional part, and then setting the position attribute (x or y) of the moving object to this variable every time you move it, you will get smooth motion! Watch the video starting at 18:02 if you don't understand what I mean.
Instead of setting extra variable for previous time, then subtracting it from the current and then saving it into dt variable, simpler and more precise solution would be pygame.time.Clock.tick_busy_loop(), which is pre-compiled, thus, producing better results!
i followed along with this video and I still had some trouble. I know some python basics and some pygame basics. Your explanations are great, but do you, or anyone else, have any recommendations for how I can get up to speed on understanding this code a little bit more? it's hard to wrap my head around some of it. thanks!
Honestly, more than anything, I'd like to know a good cross platform engine that would allow Android/iOS games, as that's where all the potential players are.
Hello. Everything has made a lot of sense, but I have one problem. For some reason, when I try to implement this into movement controls, my character moves slightly faster along the negative axis. Whenever I move my character along +y or +x, I'm forced to add speed in the equation so that the speeds even out in all directions. The amount of speed I have to add is dependent on what my framerate is. If I have 120fps then I have to add 100. If I have 60fps I have to add 60 speed. Is there any fix for this?
Maybe you're setting the position (x or y) of your object by using += instead of just = . Only the external variable...in this case, test_rect_pos...should be updated with +=. (I had a similar problem.)
@@ClearCode what would be the indentation error tho? My code under while true is: while True: for event in pygame.event.get(): If event.type == pygame.QUIT: pygame.quit() exit() screen.blit(sky_surface,(0,0)) screen.blit(ground_surface,(0,300)) screen.blit(text_surface,(300,50)) screen.blit(player_surface,player_rect) snail_rect.x -= 4 if snail_rect.right
For anyone curious, i think that the problem is that the code rendering graphics etc. is placed inside event loop and it should be only in while true loop
This isn't entirely correct. A more in depth look at how delta time works can be found here: ruclips.net/video/yGhfUcPjXuE/видео.htmlsi=sE4QcgXeCbMBxhzb This is still a good video as an introduction to dt
in my honest opinions this channel is so underated this channel deserves 1 mil subs
you mean 1 bazillion subs 🙃
@@K5RTO you mean 1 morbillion subs
I noticed just now that he has only 100k subs
It's worth mentioning that this video doesn't show how smoothly the rectangle moves (probably because of RUclips's video compression, I don't know). But it's definitely worth following along in this example to see how to achieve smooth motion! Before watching this, I was always a bit frustrated by the occasional jerkiness of object motion in Pygame--no matter what frame rate I used. This fixes the problem! If you care about smooth motion in Pygame, learn this technique!
Yup I too was so frustrated by the choppy motion.
This is such an elegant explanation. Just wanted to add, that I had fun adding my scaling factor to the speed as well. My game is using a standard 320x180 pixel art canvas then everything is scaled up 4x or 6x (or less for fun). The scaling was only applying to the image sizes but now I am adding scaling to the speeds. As I understand it, using dt also simplifies the choice of speed as a value basically translates to pixels per second. Therefore, I have to correct it with my 4x or 6x scaling. (Don't want 100 pixels per second on a 320 screen AND a 1920 screen). Very satisfying
Attention at 4:50.
The example there is about "fixed time", and does not count difference between frames.
This could led to confusion if you implemented it in your code, expected that everything multiplied by that just "move correctly" (since it will not).
To correct, you need to take your system's "now" time, subtracting "last_draw_time" from it. The result is the right value of the delta time that you can multiply.
This value will have to (maybe) be elevated to some power of 10, just to reduce precision. But it works as expected.
I struggled so much with the floating point issue and my position being 0 because of it.
Thank you!!
This is exactly what I was looking for. Almost ALL tutorials handling movement and jumping using frame dependant code and it's always bothered me. They do not even touch on the topic of accurate movement. Today was watching a tutorial on jumping and they set jump_height = 15 (steps aka frames) then were monitoring a variable called jump timer counting frames and once you hit 15 you'd be at max height...
But just like you explained if you ran this game at 600 fps... it would happen at light speed and you'd only jump a fraction of the height you'd jump at 30 fps.
This is a such an important part of a game's development and I do not see anyone talking about this. I'm glad I found this video and am not going crazy lol.
*Review*: ok, so by multiplying the desired speed by Δt each frame refresh, this enables you to scale the speed traveled each frame according to the hardware fps.
so. Each frame refresh the motion would actually be different with this formula. *but* since there are more frames being output at 120fps vs 60fps, over 1 second the lower motion per frame should normalize to a constant value
Thanks RUclips recommendations for this.. I've tried to make this already since August 2021 and didn't know how to solve it. Thanks you, man, you are really cool
Another solution or addition:
Have two update methods.
One for logic and the other for drawing. The drawing loop should run at computer speed while the logic loop should run at a fixed interval ideally 30-60 times a second
BEST video about delta time in games i have never followed a tutorial that actually made me understand this THANK YOU!
Really well explained. I like the mix of theory and practical demonstrations.
Very good explanation. Thanks for making the video.
For the Pygame fps, have you tried using time.perf_counter() instead of time.time()?
luv it. best video about deltatime
It's a bit easier to do that now in Pygame-CE thanks to frects, which are rects that use floats instead of integers, so you don't need that extra variable for the position.
Pygame CE, I just read that this is a forked ver of pygame with more updates, what happened to og pygame?
i thinck you can skip most of the second part ,because with new cpygame
you can make "FRect" instead of "Rect" and it will do the work with float numbers as well
(this video is for 2022, in his newer videos he said you should use the FRect almost every time)
Thank you for the great videos! I ended up purchasing your course on Udemy and loved it.
Very good content, and good advice from some comments.
I may just add not to call time.time() twice, you are losing a (very tiny) amount of time between the two.
Use a variable current_time that you use throughout all the current frame.
This includes body loop and passing the variable to function that want the current time.
This was so worth every second
Generally a very good video and helps a lot to grasp this really important matter, but you erroneously built the table from 5:50:
0) 1/30=0.033, not 0.33 etc.
1) units are wrong. On the left site you've got 1/s*pixel*s=pixel, whereas on the right site you've got pixel/s.
2) The variable you calculate in the table is just covered distance i.e. Δx, not Δx/Δt.
3) You indeed want to have the same Δx/Δt regardless of FPS, but to have it constant
4) You need to have various Δx and Δx/frame. For instance, since
Δx/Δt=Δx/frames*frames/Δt=Δx/frames*FPS,
if you've got FPS=10 and you want Δx/Δt=100 you must have Δx/frames=10 and Δx=10 in every frame, but if you've got FPS=30 and want Δx/Δt=100, you must have Δx/frames=100/30 and Δx=100/30 in every frame. Thus Δx/frames must differ.
Thanks. I think what is missing is a standardised formula for speed from, oh, say, a speed variable value for 60 FPS to one for 1000 ticks per seconds. It would help us slow learners to get a handle on what he attempting to explaining. I'm not sure that "CDcodes" does it any better. Both make some logical leaps without more thought/examples/whatever.
The following is stream of consciousnesses, feel free to ignore.
Given his maths, I was attempting to determine just what the various speed numbers actually mean. Does "speed = 250" mean I want this object to move 250 pixels per second (as 1000 ticks =~ 1 second)... But there is some slop in his maths (or my head) that I'm just not getting (admittedly I'm a bit tired and a bit drunk 😇). I would like to not guess as to what the speed numbers mean and have to use (more then the normal) trial and error to determine them. If my standard game used 60 FPS, then there should be a pretty well defined formula for converting from the speed numbers I used with 60 FPS and the speed numbers I use for 'dt'. i.e ((original_speed * 60) / 1000)) No...that's not right. It should be just (original_speed * 60) and the 1000 ticks per second will take care of themselves, once you invert it (1/1000).
Because I use both a fast Windows 10/HP laptop and (my preferred development environment) a relatively slow Raspberry Pi 4 (64 bit Debian)... this kind of thing is actually important to me.
Thanks bro, just taught me all of the basics :D
such an underrated channel 🙏
It really doesn't matter I'm sure, but I set new_time to the time, calculate the delta with new_time then set last_time to new_time that way I can't possibly loose time between the two lines that call get time.
Excellent video as always. Keep it up!
Happy I found your channel, learning a lot here :)
nice video clear code !
I know this is old, but i have a lottle bit of a tough time understanding the exact math of this. Wouldnt delta be a measure of the amount of time per drame (sec/frame as the units). So wouldnt multiplying pixel/frame * frame/sec * sec/frame result in just pixels as a measurement? So then we arent really deifning a rate? I totslly get the explanstion if delta doesnt have a unit, but i don't understand why delta is just a scalar woth no unit.
5:09 wouldn't the formula be movement*target framerate*deltatime to prevent lag?
You are an amazing teacher!
I like your vids because how clean they are 👍❤❤
that's so useful, thank you man
you made it even more complicated now for me
Great video!
I've heard that tying animation speed to frame-rate is "a bad thing to do". Is this true? Why? What are the other options?
you could use a timer to update a frame every 1/10 of a second or something but I haven't really encountered problems why the animations on delta time
You don't want to tie animation to a specific frame rate. In other words, you don't want to hard code an animation to run at 30 fps because it will run twice as fast as it should at 60fps and 4 times as fast at 120fps.
This is why a lot of old PCs had a "turbo" button on the case to toggle the CPU between full clock rate and a slower clock rate. A lot of old games and software didn't limit frame rate in code and didn't really take frame rate into account, so e.g. an old PC game would run at an unplayable 900 fps on newer hardware and characters and enemies would move around at light speed and music would be on fast forward or would just break.
I am not an expert in this but what if we use an OOP like structure and call the update function x times per second and to get x we do something like calculating delta time. something like using dt to calculate how many times we need to call update(). this way we dont need to mutiply everything by delta time
Can I just use speed = base_speed*max_fps/fps or does that not work?
Hi, I'm a beginner in programming and I'm trying to code my first mini game with the great help of your video 'the ultimate introduction to Pygame', but I have encoutered a problem with the framerate ; is there a simple way to reduce or remove the kind of lag when you run a simple animation ?
Is it a kind of stutter every second or so or just basic lag (help is much better on the clear discord though, so suggest you check that out)
@@KlaasJanssen a kind of stutter yes, you're right I posted my question on discord
@@firnyx I struggled with the same problem until I watched this video. By using dt (delta time) as described, and (this is mportant!) keeping test_rec_pos in a separate variable including the fractional part, and then setting the position attribute (x or y) of the moving object to this variable every time you move it, you will get smooth motion! Watch the video starting at 18:02 if you don't understand what I mean.
Underrated
Hi, pygame-ce solve the problem of movement with integers?
yep, that's what FRects are for :)
Instead of setting extra variable for previous time, then subtracting it from the current and then saving it into dt variable, simpler and more precise solution would be pygame.time.Clock.tick_busy_loop(), which is pre-compiled, thus, producing better results!
Their is any possible way to make android games using pygame
Thanks
Piece of advice: multiply dt by 60 so you don't have to work with high speeds
i followed along with this video and I still had some trouble. I know some python basics and some pygame basics. Your explanations are great, but do you, or anyone else, have any recommendations for how I can get up to speed on understanding this code a little bit more? it's hard to wrap my head around some of it. thanks!
I'm late but it'd be best if you watched his introduction to pygame tutorial. You'd get most if not all of the code he wrote
Honestly, more than anything, I'd like to know a good cross platform engine that would allow Android/iOS games, as that's where all the potential players are.
Thanks for this.
How to move position from 0 to 100 in 1000ms??
Hello. Everything has made a lot of sense, but I have one problem. For some reason, when I try to implement this into movement controls, my character moves slightly faster along the negative axis. Whenever I move my character along +y or +x, I'm forced to add speed in the equation so that the speeds even out in all directions. The amount of speed I have to add is dependent on what my framerate is. If I have 120fps then I have to add 100. If I have 60fps I have to add 60 speed. Is there any fix for this?
Maybe you're setting the position (x or y) of your object by using += instead of just = . Only the external variable...in this case, test_rect_pos...should be updated with +=. (I had a similar problem.)
How to make screen that fits display of any pc
hey why are we using the pygame vector?
Hello can you plz do a series on kivymd
What editor are you using in this video?
18:08 Why is the answer to the issue?
bro do some raylib c++ tutorials pls 😢
Question: are pygame sprites/objects supposed to move by themselves or are they suppose to move when you move your mouse?
They move by themselves. You messed up the indentation in the while loop!
@@ClearCode what would be the indentation error tho?
My code under while true is:
while True:
for event in pygame.event.get():
If event.type == pygame.QUIT:
pygame.quit()
exit()
screen.blit(sky_surface,(0,0))
screen.blit(ground_surface,(0,300))
screen.blit(text_surface,(300,50))
screen.blit(player_surface,player_rect)
snail_rect.x -= 4
if snail_rect.right
@@ClearCode sorry if I am being annoying. The code is from the ultimate pygame introduction
For anyone curious, i think that the problem is that the code rendering graphics etc. is placed inside event loop and it should be only in while true loop
beset tutorial about this
If you don't limit the fps the game will empty the battery energy on laptops or smartphones/tablets.
The fps are still limited with pygame.clock.time(60) even when using deltatime.
Instant like
Algo
This isn't entirely correct. A more in depth look at how delta time works can be found here:
ruclips.net/video/yGhfUcPjXuE/видео.htmlsi=sE4QcgXeCbMBxhzb
This is still a good video as an introduction to dt
i liked and copied link :)
lol pygame
first comment
69th comment
Lol, btw love ur vids bro.
Bot :?)
@@Vofr nah breh, 69 was a joke
@@IzUrBoiKK you are not the 69th comment ~_~. It doesn't work that way :3
good pc: 600+ fps (i think it's supposed to be 60 plus)
bad pc: 30 fps