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.
