Thanks for clarifying,
Remember, there’s no problem with not understanding some stuff. And sorry if in my previous post I was kinda ignoring that.
If you move linearly, yes.
If you are making a player movement system with some kind of acceleration, it will require more maths (here’s a great video explaining advanced delta time usage)
To would be really helpful if you could find that video and link it here
Remember, in videogames there’s not really such a thing as “movement”, but it’s an illusion achieved by teleporting object frequently. When player has low FPS, you either choose to keep all the movement/animation values etc. the same (the version without delta time) and the player ends up in slow motion.
It’s quite different for when we talk about something like 10 FPS and 30 FPS
In the former case, the game either will be a slide show (with delta time) or a super slow-mo version (without delta time). For game centered around precision etc. The latter would maybe actually be better. However, if you decide to not use delta time, you end up with problems I described in points 3 and 4
It is very important for you to understand than (as I said before) any movement in games is, in fact, teleporting. So yes, while it is possible for the player to teleport through the wall when they have something like 2 FPS and when the game has delta time,
it can (and does) also entirely happen for example when the player is just moving very quickly, no matter the FPS or delta time or not
(example - see the video here)
But remember, it’s just how movement in games works (by teleporting), and physics programmers know that well and consider that when programming physics engines. That’s why we have things like continuous collision detection, which is a system for making sure that when the object teleports over a big distance between two frames (when moving quickly or when low FPS + delta time) it doesn’t skip any obstacles on its way
I know all movement is teleporting, what I mean is “perception” of teleporting… I’m talking about the “appearance” of a ball bouncing off walls slowly, vs the appearance of a ball randomly jumping between unrelated positions…
How we read such a room, will produce 2 very different understandings of what is happening.
Well I have gravity in my game, and movement acceleration…
… I specify 60 frames per second, and fixed timestep, and v-sync… I thought this had me covered.
… This whole thing is strange, because I have been using this framework for so many years, and I don’t seem to SEE people using it…
So guys, at the end of the day… Are we (all of you as individuals) using *delta_time in all your update dmethods for your 2d side-scrollers, angry_bird clones, etc.?
I just have NEVER seen people caring about it, but I also don’t know any other programmers.
I thought this was done in init / load phase, where I specify desired framerate?
I mean, I got a new pc a few years ago, leaving an ancient one, and when I moved all my old projects over, sure they needed to be modernized a bit, but their FRAMERATES were all the same…
When I made games BEFORE monogame, I would use the computers timer to time frames, but I just figured monogame had this built in, foreseeing this need in EVERY game…
Maybe I am missing something here? Or you guys are overcomplicating it
If you are using fixed frame rate you probably don’t have to use delta time. But you must note that if your frames start to take more than 1/60 of a second to finish, you will have problems with game suddenly becoming slow-mo.
Because of that, I usually go for unfixed frame rate and delta time, with the exception being physics calculations or camera movement
I would recommend reading this blog post by Shawn Hargreaves (one of the original XNA developers) which explains the differences between fixed and variable timesteps and the reasoning behind the way they are implemented.
Programming in movies: Have an AI skim the net for content, and drop it in the game in real-time, as the player with the headset moves around an endless procedural world, mirroring reality.
Programming in real life: How bout this frame timing. Anyone have a link?
Lol, this was the random video suggestion that had me questioning.
I guess the bottom line here, is for a metroidvania game that uses WELL under 10% cpu on a normal house hold PC, you can just set it to fixed update and enjoy life.
It’s up to you. Reading through the Shawn Hargreaves blog above you will get your updates eventually so you have a choice. I wouldn’t get hung up on the 10% cpu utilization for two reasons…
That might be true for your computer but not true for others.
You can’t predict when something might take up CPU time.
With fixed timestep you’re supposedly going to get those updates eventually, you just might get multiple in a frame. As long as the time to perform a single update is less than the average time per frame you will catch up. If you calculate your movement based on delta time, your character will just appear in the right place after a slowdown. Of course, this can make collision detection and response tricky.
There’s merits to both and, to be completely honest, I would just utilize both approaches. Use a fixed time step but also calculate position as a function of time.
I’m a bit worried you may have missed the point but ultimately it’s your code. If you don’t want to do the multiplication with delta time and assume a fixed framerate by all means, do so. You’ll likely be fine in almost every case.
You can have the best of both worlds: a variable frame rate game with “slow down syndrome” (as we call it in our studio) where the game does not advance faster than a fixed frame rate and runs slow to the user.
Yea thanks all you guys… Good to see everyones thoughts on this, and get a feeling that I am at least not alone with these thoughts… I’m not WASTING my time, thinking on this, and that is a nice foundation.
I get a little upset over some of these things on a personal level, because I am one of those people who feel violated by modern technological development, like it hurts me to see the pressures of smart phones and social media stuff, so I feel REALLY bad, when hearing that I, on the other hand, a small little solo nobody, am “expected” to bend over backwards for a non existent potential client
It’s nothing serious guys, this is just me venting some frustration at the water cooler. - I am here to work, not gossip. Good day to all, and thanks again for your participation.
The more I think about this the more I agree with you ( for games that aren’t networked). Except they used to do this and old games now run way too fast to play so on different hardware your game would run at different speeds. So I would still use Delta time but pause updating if you were missing draw calls.
Also having a set update time in second allows physics calculations with “real” numbers.
In this case I think it will be ok since it just runs multiple Updates in a frame until it catches up. If the computer is running too quickly, it will still wait the appropriate amount of time until the next update call.
If I’m understanding it correctly, the only difference is that after a slow down you’d see characters zipping about vs. catching up in one big step.
However, I do think there’s something to be said for physics being done in a fixed time step anyway so you don’t have to worry about unwinding complex collisions that could have happened in a 1s lag spike haha.
I would still do the deltatime calculation myself anyway, but if it’s always going to be 1/fixedFrameRate then I suppose it’s going to be the same.
I was always in the “*deltatime” camp and presumed this meant a fixed time step was unnecesary. In fact i still feel this is correct for 3d games.
But then i did that “neon shooter” xna tutorial and noticed the author did not take that approach and how it simplified all calculations (and there are an obscene amount of cpu particles) to the point that it was obviously going to add a great deal of strain to also add in the delta multiplication to everything. It made me question why i would be using delta time in a 2d game that must run at 60fps vsynced or be damned.
If you assume the machine its running on is capable of running it at 60fps, then all delta time should be constant anyway and you’re pretty much wasting cpu cycles for nothing.
I know this is not the way you’re supposed to do it and then along come 144hz monitors to spoil the fun but perhaps these odd outliers also at least support 60hz or Variable Refresh Rates?
For devices that cannot run your 2d game at 60, i would suggest giving options to simplify shaders/options so that they either can or just admit defeat, do as microsoft windows 11 does and insist they get a new computer.
