Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Sort of. It's not about precision. It's about continuous versus discrete space, and it's about continuous versus discrete velocities. Not every game wants tapping the arrows to move by exactly and literally one tile.Say you're building some sort of space game, and ships are going to be going all over a to-scale solar system. You don't want the ship to blip a kilometer every 20 ticks, you want the ship to move smoothly through space. And ignoring the fact that space is actually big enough that such a game probably would barely bother with collision, your ship suddenly moving a kilometer every 20 ticks means that any object that's smaller than a kilometer can be tunneled through--the ship started on the left, then it moved a kilometer, and now it's on the right, but at no point did they "collide" from the perspective of the game code even though they should have.Another way of looking at delta is that delta decouples how fast objects move from how fast the game ticks *entirely*. Objects are clipping through each other and you don't want to write a continuous collision detection system? Well, tick twice as fast, not much if anything will break and now they don't. URL: https://forum.audiogames.net/post/538213/#p538213 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Oh, I see. So the approach mention would be for something more precise, or something where the player can glide. Thank you. URL: https://forum.audiogames.net/post/538177/#p538177 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? @14Well, another take on that: sometimes you value always moving by exactly one tile. Sometimes you don't. If it's a first person shooter, you don't. If it's some sort of block puzzle game, you might.I think the problem is that you're looking for the answer. The answers I'm giving you here are an answer, not the answer. They're a pretty good answer, but there's lots and lots of other ways to answer it.That said, doing the if xyz_timer > value thing makes whatever you're doing entirely discontinuous. It's either done or it's not. This will disallow for small movements.@15Python doesn't autoconvert from double to int for indexing. Most languages don't, and you shouldn't rely on it when it does. URL: https://forum.audiogames.net/post/538152/#p538152 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? You can. Strictly speaking, a lot of older games had to do that to account for hardware limitations. But those were working at pixel precision. It's way simpler to do it the physicsy way, unless you're using integers for coordinates. And these days I'd still just use doubles even for a tile-based map, and convert to int when getting indeces (does Python do that automatically, or do you need to say int(x) etc?). You wouldn't use a timer per se, of course. You'd use a number, and update it with each tick. If you look at RAM maps for the original Super Mario Bros, you'll find there's a number of frames until Mario moves 1px x-wise, and the same for y. This is kinda how I did it with audio Mario, but with block precision instead of pixels (which is only partly why jumping is more awkward).In general, though, I'd recommend dx = dt * vx, as Camlorn described. URL: https://forum.audiogames.net/post/538149/#p538149 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Right. So, another question time. In post 6, you gave an example of how to calculate movement, quoted below for reference:camlorn wrote:And for player motion...I'm going to use the 1D case for this, but this also applies in 2D if you use unit vectors. Say vx is the player's velocity in meters per second, positive east, negative west. Then the movement from the last tick is delta * vx. The movement 3 ticks from now is 3 * delta * vx.It's like algebra. You can always remember/figure out where you have to divide by framerate, but it's easier to not use framerate and use delta.I have often seen if statements that look like this:if walktimer.elapsed >= 500: #Stuff... if firetimer.elapsed >= 2000: #Some more stuff...Why is it a bad idea to do this with frames? The sample clock code you gave in post six could be adopted to use the same approach, we would just need to convert the times to seconds, 0.5 for the former and 2 for the latter. So, again, why wouldn't we? URL: https://forum.audiogames.net/post/538098/#p538098 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Right, so give tick frames, compute delta as 1 / framerate as a constant somewhere, and pass it around. Don't use wait, pygame is (hopefully) smart enough to know how to account for the time the game code itself took to run if you use frames with it. URL: https://forum.audiogames.net/post/537939/#p537939 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Sort of. Tick sleeps but it uses frames as context. Weight can be supplied with milliseconds instead of frames. Also, wait will sleep the same value, or really close to it, regardless of how long your game loop executes, where as tick, again, uses frames to adjust as needed. URL: https://forum.audiogames.net/post/537937/#p537937 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? @10Yes, probably? Isn't tick what actually sleeps the game? I'm not overly familiar with pygame timing facilities offhand. URL: https://forum.audiogames.net/post/537935/#p537935 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? So do I still use the tick function in addition to manually calculating delta? Re, chasing accuracy. I’m not, I was just confused on the documentation. URL: https://forum.audiogames.net/post/537933/#p537933 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? So do I still use the tick function in addition to manually calculating delta? URL: https://forum.audiogames.net/post/537933/#p537933 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Bleh, also, double posting time. I think it's worth pointing out that if you chase accuracy here you're not going to get it short of a QueryPerformanceCounter spinloop, and probably not even then. The best OS timers are only accurate to a couple MS and there's enough stuff on every computer that you're never going to get it quite accurate to exactly 1/framerate of a second no matter what you do. If Pygame is giving you roughly 60 frames a second and isn't leting the loop go too fast, you can totally just entirely disregard it and pretend it's perfect and call it a day for anything you'll be doing now or for a good while yet. URL: https://forum.audiogames.net/post/537925/#p537925 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Yeah, that's pretty typical game timing code for an example, you just don't bother because it's a visual demo.Delta is only one name for the delta. I'm not sure if it has an official term. I've seen it called lots of things. Notice that Pygame doesn't even give it a name, and thinks that it's cute to call it get_time despite it, like, not actually getting a time on an object called a clock.My interpretation of what you're quoting is this: the clock locks the game to 60FPS (or whatever). Delta is 1/60 (or whatever). clock.get_time() returns the *actual* time between them that actually happened, not the theoretical time between them that you asked for. SO use delta = 1 / framerate and don't worry about get_time is my advice here. URL: https://forum.audiogames.net/post/537924/#p537924 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? What pygame.clock found here does is limit how fast your game runs. I.e, if you set it at 60 FPS and you finish before 16.66 ms were up, Pygame will call the wait function on it's own to keep the game at 60 FPS. This is what confuses me.Pygame Docs wrote:get_time()time used in the previous tickget_time() -> millisecondsThe number of milliseconds that passed between the previous two calls to Clock.tick().It seems like this already calculates delta under the hood... or am I misunderstanding this? I tried googling framerates in Pygame, but I haven't found anything helpful... most of what I found pointed me back to Pygame docs, which doesn't really help. In addition, the Pygame examples themselves seem to keep track of times in frames? If you look at aliens.py in the pygame examples folder, you'll find the following (Lines 55 - 61):# each type of game object gets an init and an # update function. the update function is called # once per frame, and it is when each object should # change it's current position and state. the Player # object actually gets a "move" function instead of # update, since it is passed extra information about # the keyboardHere is a sample of the alien classclass Alien(pygame.sprite.Sprite): speed = 13 animcycle = 12 images = [] def __init__(self): pygame.sprite.Sprite.__init__(self, self.containers) self.image = self.images[0] self.rect = self.image.get_rect() self.facing = random.choice((-1,1)) * Alien.speed self.frame = 0 if self.facing < 0: self.rect.right = SCREENRECT.right def update(self): self.rect.move_ip(self.facing, 0) if not SCREENRECT.contains(self.rect): self.facing = -self.facing; self.rect.top = self.rect.bottom + 1 self.rect = self.rect.clamp(SCREENRECT) self.frame = self.frame + 1 self.image = self.images[self.frame//self.animcycle%3]So again, no mention of delta anywhere which is surprising because, ur, that's supposed to be the core of each sighted game, right?Re, dropping milliseconds. I think it happens every second or so... the value is never exactly 2000. It's always somewhere at 2004, 2009, 2015 (highest I've seen it at), etc. URL: https://forum.audiogames.net/post/537916/#p537916 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? What pygame.clock found here does is limit how fast your game runs. I.e, if you set it at 60 FPS and you finish before 16.66 ms were up, Pygame will call the wait function on it's own to keep the game at 60 FPS. This is what confuses me.Pygame Docs wrote:get_time()time used in the previous tickget_time() -> millisecondsThe number of milliseconds that passed between the previous two calls to Clock.tick().It seems like this already calculates delta under the hood... or am I misunderstanding this? I tried googling framerates in Pygame, but I haven't found anything helpful... most of what I found pointed me back to Pygame docs, which doesn't really help. In addition, the Pygame examples themselves seem to keep track of times in frames? If you look at aliens.py, you'll find the following (Lines 55 - 61):# each type of game object gets an init and an # update function. the update function is called # once per frame, and it is when each object should # change it's current position and state. the Player # object actually gets a "move" function instead of # update, since it is passed extra information about # the keyboardHere is a sample of the alien classclass Alien(pygame.sprite.Sprite): speed = 13 animcycle = 12 images = [] def __init__(self): pygame.sprite.Sprite.__init__(self, self.containers) self.image = self.images[0] self.rect = self.image.get_rect() self.facing = random.choice((-1,1)) * Alien.speed self.frame = 0 if self.facing < 0: self.rect.right = SCREENRECT.right def update(self): self.rect.move_ip(self.facing, 0) if not SCREENRECT.contains(self.rect): self.facing = -self.facing; self.rect.top = self.rect.bottom + 1 self.rect = self.rect.clamp(SCREENRECT) self.frame = self.frame + 1 self.image = self.images[self.frame//self.animcycle%3]So again, no mention of delta anywhere which is surprising because, ur, that's supposed to be the core of each sighted game, right?Re, dropping milliseconds. I think it happens every second or so... the value is never exactly 2000. It's always somewhere at 2004, 2009, 2015 (highest I've seen it at), etc. URL: https://forum.audiogames.net/post/537916/#p537916 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? What pygame.clock found here does is limit how fast your game runs. I.e, if you set it at 60 FPS and you finish before 16.66 ms were up, Pygame will call the wait function on it's own to keep the game at 60 FPS. This is what confuses me.Pygame Docs wrote:get_time()time used in the previous tickget_time() -> millisecondsThe number of milliseconds that passed between the previous two calls to Clock.tick().It seems like this already calculates delta under the hood... or am I misunderstanding this? I tried googling framerates in Pygame, but I haven't found anything helpful... most of what I found pointed me back to Pygame docs, which doesn't really help. In addition, the Pygame examples themselves seem to keep track of times in frames? If you look at aliens.py, you'll find the following (Lines 55 - 61):# each type of game object gets an init and an # update function. the update function is called # once per frame, and it is when each object should # change it's current position and state. the Player # object actually gets a "move" function instead of # update, since it is passed extra information about # the keyboardHere is a sample of the alien classclass Alien(pygame.sprite.Sprite): speed = 13 animcycle = 12 images = [] def __init__(self): pygame.sprite.Sprite.__init__(self, self.containers) self.image = self.images[0] self.rect = self.image.get_rect() self.facing = random.choice((-1,1)) * Alien.speed self.frame = 0 if self.facing < 0: self.rect.right = SCREENRECT.right def update(self): self.rect.move_ip(self.facing, 0) if not SCREENRECT.contains(self.rect): self.facing = -self.facing; self.rect.top = self.rect.bottom + 1 self.rect = self.rect.clamp(SCREENRECT) self.frame = self.frame + 1 self.image = self.images[self.frame//self.animcycle%3]So again, no mention of delta anywhere which is surprising because, ur, that's supposed to be the core of each sighted game, right? URL: https://forum.audiogames.net/post/537916/#p537916 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Frames can either be early or late, depending. If your frame is *always* late it's a problem, but that doesn't mean it will always be late. I'm not sure if you're saying Pygame is off by a few ms per second or a few ms per frame, but if it's only off by a few ms every second, no one will ever notice.You can (and should) pass the actual delta, not the delta = 1/60 delta. But that's very hard because it turns out that in practice a lot of algorithms don't like it when you start feeding them time that's not always the same, in particular a good bit of the physics engines out there. This is also why you typically don't change framerate at runtime.If delta is 1 / framerate, you can change the speed of the game by changing framerate before game start and that will "just work". Delta is just the time between frames, it's not supposed to literally be a magic constant that's different from framerate.If your question is why not just pass framerate around, it's because delta is ridiculously convenient. You're going to eventually want to pause the game, for example, which means that the game stops ticking. And as soon as you want to do that you're going to want to write a little tiny clock, like this:class Clock: def __init__(self): self.time = 0 def get_time(self): return self.time def tick(delta): self.time += deltaAnd yeah sure, you could pass in framerate, but then you have to remember to divide by it.And for player motion...I'm going to use the 1D case for this, but this also applies in 2D if you use unit vectors. Say vx is the player's velocity in meters per second, positive east, negative west. Then the movement from the last tick is delta * vx. The movement 3 ticks from now is 3 * delta * vx.It's like algebra. You can always remember/figure out where you have to divide by framerate, but it's easier to not use framerate and use delta.Why not use a global, you ask? Because while a lot of algorithms explode when fed fluctuating delta/timestemp durations (Box2D, I'm looking at you), a whole other class of games fall over if you don't (rhythm games, frame-precise fighting games, I'm looking at you). it's also potentially nice to decide that some objects which are really computationally heavy tick slower than the rest of the game. For example enemy AI might only tick 1/3 of the time, but is still going to want an accurate time since the last tick (you might tick the first 1/3 game AI instances on tick 0, the next 1/3 of them on tick 1, etc...the point of that is that it spreads the computation out).As soon as you say "delta is global" or "delta is set at object construction", you never, ever, ever get to change your mind on the "everything ticks exactly 60 times a second, no variation ever" decision, not without refactoring half the game. Also, delta set at object construction is a bad idea for something like a giant online city-building empire strategy game with half a million objects because even in C++ you just wasted several megabytes of ram and became cache unfriendly and etc etc etc. Does that matter? No. But it's also entirely trivial to not waste several megabytes of memory and you're also keeping a bunch of other flexibility and in Python it's actually worse than in C++, so why not take the low-hanging fruit when it's trivial to do so?Also in general pygame is written for newbies, so just because Pygame does something not so great with respect to API design that you don't like that doesn't mean it's the best way and it's you who's wrong. In particular, I am not liking the weird implicit clock stuff you're showing me one bit. URL: https://forum.audiogames.net/post/537884/#p537884 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? So I'm updating this, because I need to continue the discussion.In pygame.time.clock I found this function and it has been bothering me:pygame.clock.get_timereturns the number of milliseconds between each frame, I.e, this works as expected:#Assume we've initialized pygame and created the necessary objects elapsed = 0 while True: elapsed += clock.get_time() #Other code... clock.tick(60)The tick parameter is for the fps, so we're at 60. The pygame.clock.get_time returns the amount of seconds between each frame. So, what's my issue?camlorn mentioned refactoring my code to look like this (assume all the necessary objects were created again):framerate = 60 while True: #Insert event handling code here entitys.update(1 / framerate) #We still have to limit the fps to 60 so... clock.tick(framerate)For me, this can be simplified by editing my first example and replacing all the references to 60 with framerate. That way I can change how fast the game runs at a drop of a hat. So, why should I use delta approach? The only advantage I would see is constant updates (pygame tends to lose or gain a few milliseconds here and there). I edited the first example to print the value of elapsed every 2000 seconds and reset it, and the output varied from 2004 to 2015 ms. Won't the second approach still technically lose or gain a few ms here and there because I used clock.tick?Again, I lament the fact that I made the mistake of starting with BGT and looking at the incorrect ways of doing things, but that just summarized my entire life so... can't be too sorry about that, LOL. URL: https://forum.audiogames.net/post/537874/#p537874 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? So I'm updating this, because I need to continue the discussion.In pygame.time.clock I found this function and it has been bothering me:pygame.clock.get_timereturns the number of milliseconds between each frame, I.e, this works as expected:#Assume we've initialized pygame and created the necessary objects elapsed = 0 while True: elapsed += clock.get_time() #Other code... clock.tick(60)The tick parameter is for the fps, so we're at 60. The pygame.clock.get_time returns the amount of seconds between each frame. So, what's my issue?camlorn mentioned refactoring my code to look like this (assume all the necessary objects were created again):framerate = 60 while True: #Insert event handling code here entitys.update(1 / framerate) #We still have to limit the fps to 60 so... clock.tick(framerate)For me, this can be simplified by editing my first example and replacing all the references to 60 with framerate. That way I can change how fast the game runs at a drop of a hat. So, why should I use delta approach? The only advantage I would see is constant updates (pygame tends to lose or gain a few milliseconds here and there). I edited the first example to print the value of elapsed every 2000 seconds and reset it, and the output varied from 2004 to 2015 ms.Again, I lament the fact that I made the mistake of starting with BGT and looking at the incorrect ways of doing things, but that just summarized my entire life so... can't be too sorry about that, LOL. URL: https://forum.audiogames.net/post/537874/#p537874 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Most modern games do not in fact use frames with timers anymore, because in actuality your display can be set to 30, 60, or 120 FPS. You want to convert to seconds with 1/framerate, then everything that takes tick takes a parameter called delta which is always 1/framerate in seconds.Why delta? Because in practice, if you go further, it can become important to limit the game to the framerate, but instead of passing the framerate in you pass the actual time since the last frame in. These can be wildly different if i.e. the aforementioned antivirus hates you. Does it usually matter? No, but it can (think a rhythm game for instance). And the standard naming for something that represents change mathematically is delta. For example deltaXZ, deltaY, etc. BUt since time is so common why deltaTime, when delta is more convenient.Also by using seconds, you can change the framerate. This is a free way to make your game take less resources.And working in time lets you say "2 meters per second" and then you get how much movement since the last tick with velocity_in_seconds*delta, and if the framerate does ever change it won't explode.Then you write a tiny clock class around this if you want a higher level piece that just increments delta in tick and calls whatever events you want called on whatever schedule. Or find one, maybe that's what Pygame gives you.Audiogames won't ever have to deal with it, but the sighted stuff can even have *multiple* framerates. One for graphics, which has to happen at the rate of the display, and one for simulation, which can often be done as little as 10 times a second and can also be incredibly expensive. XNA does this for example, not that anyone uses XNA anymore. URL: https://forum.audiogames.net/post/529224/#p529224 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? [cont]But converting from MS to frames is something I generally avoid. I still track movement and actions in seconds, partly because when I was working in Java, I got wildly different framerates on different versions / computers (which is why you had to specify frame length and units when running my java games from command line).So I just save the frame length, preferably as a constant but sometimes it has to be a variable (as with the Java issues). For clock.bgt, iirc, this is saved in the clock object's delay property. With pygame.time.clock, you are on your own. I've been saving the framerate as a global variable.Anyway, framerate is in frames/seconds. If you want the number of seconds, do 1/framerate.60fps = 60f / 1s, or 60f / 1000ms.so the time per frame is 1/60s, or 1000/60ms, or 16ms / 17ms (depending on how you round, and fwict, Pygame likes to round up).I prefer to calculate how much time passes once, in the main update function, then have individual methods for updating game-objects take the time as a parameter. That way, if anything screwy happens, or we need to do something weird like fast-forward or rewind, we still get the benefits of frames.So I usually define an action's duration in seconds, and the update function takes how much time passes between frames as a parameter, and I just update it in that way. URL: https://forum.audiogames.net/post/529139/#p529139 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
Re: Difference between frames and milliseconds?
Re: Difference between frames and milliseconds? Yes, frames are the mainstream solution, and have more or less always been. This is indeed one of the most troublesome things I notice people learning wrong from BGT. I tried doing it the BGT way, with timers for everything, in Sengoku Jidai, and with menus blocking everything ... and I kept failing to stop timers and this caused so many problems, like it being easy to starve / drown everyone by just pressing v and waiting.I think maybe one of the reasons frames come so intuitively to video games, and not audio games, is that video has always been done in frames, as a series of images displayed quickly enough to resemble motion. This is why you hear about framerate shenanigans with animation (24fps has been industry standard, but hand-drawing that is thrice as costly as 8fps, so lots of cheap anime use to go for 8fps whenever possible). For games, they had to build around the refresh rate of the hardware, which worked in frames due to RAM limitations: 200×300 pixels = 6px, and in the old days, storing all that in RAM, especially when televisions were made with video and its framerates in mind, was ridiculously expensive. So they had technically complex scan-patterns, limited colors, over-sized pixels, and 8x8 tiles, and games had to incorporate that into their timing. That, and if your animations work like any other animation...But, really, timers create a huge technical hurtle. The more realistic you want to be, and the more consistent you want to be, the more you need to standardize the time that things take to occur. Especially today, when computers have evil, schemy minds of their own, and when networks are quite chaotic, and you can never predict who will have how much lag when, you can't rely on timers not making a mess when your antivirus decides to ask if you're busy mid game, or when some random system service and a screen reader get in a fight, or when you get a Twitter message, or whatever. With frames, you guarantee that every entity in the game is on the same page, by standardizing how much time passes between updates: at 50fps, you're treating every update as though 20ms have passed since the last update, period. No matter how long anything in the game takes, or what lag comes from outside, everything stays in sync.And woe to anyone trying to use timers for online multiplayer. Getting online games to stay in sync is hard enough without letting milliseconds of drift accumulate.Java and _javascript_ timers are basically tickers with callbacks (or what passes for that in Java and its "everything is classes" attitude). You set a time, and it calls the function/method. You don't even write your own loop, because the timer does it in a separate thread. With Pygame.time.clock, you still need a loop iirc.I like the Java way, although you must keep track of your framerate, and take care if you ever decide to change it. To the extent that, if I ever did upload game.bgt in any of those include archives, that's what it's for (that and eventifying key presses). URL: https://forum.audiogames.net/post/529135/#p529135 -- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
