Elysian Shadows

I've done little demos with time based movement, but mostly I've always used frame based. For the little stuff I do, I haven't noticed a difference, and am curious as to what the positive and negative aspects to each choice are.

The only thing I have really found through google, is that with frame based movement, a drop in framerate will cause things to move slower than they normally would. Although a time based movement solves this, doesn't things such as resizing the window, moving the window, etc screw up logic?

I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

Have i understood if right if i say that, with time based logic, you multiply stuff like velocity by time since last frame to get the new position, and with frame based you dont, but simply use a constant value every time?

GR33B wrote:I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

That's precisely my point - it WON'T be consistent if there is a drop in framerate...

But to me I think, if the frame rate is capped, then frame based would be the best choice.

@ismetteren - Yeah, that's pretty much what it is.

GR33B wrote:I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

If you're using time based movement you should update your animations in the same way.

And yeah time based is the way to go, especially if you start doing things such as network multi-player where inconsistency is just not gonna work out.

ismetteren wrote:Have i understood if right if i say that, with time based logic, you multiply stuff like velocity by time since last frame to get the new position, and with frame based you dont, but simply use a constant value every time?

Yes, time-based alters magnitudes based on how much time has passed. Frame-based typically delays updating/rendering until enough time has passed to count as a frame.

the issue with time-based motion is that, if it starts lagging, collision can be severely messed up. So time-based motion shouldn't really be used unless you NEED synchronization.

Ginto8 wrote:the issue with time-based motion is that, if it starts lagging, collision can be severely messed up. So time-based motion shouldn't really be used unless you NEED synchronization.

That's what I was thinking =D... Thanks that cleared it up =p

XianForce wrote:

GR33B wrote:I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

That's precisely my point - it WON'T be consistent if there is a drop in framerate...

But to me I think, if the frame rate is capped, then frame based would be the best choice.

I was assuming you would have the frame rate capped. Say you're going for a steady 60FPS, if it drops to 45FPS for a few seconds, the game and animations will visually slow down with a frame-based system. But if you used time based and the framerate drops to 45FPS, animations would happen before they're actually supposed to in the game, because the time based model is assuming the framerate is a constant 60FPS.

GR33B wrote:

XianForce wrote:

GR33B wrote:I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

That's precisely my point - it WON'T be consistent if there is a drop in framerate...

But to me I think, if the frame rate is capped, then frame based would be the best choice.

I was assuming you would have the frame rate capped. Say you're going for a steady 60FPS, if it drops to 45FPS for a few seconds, the game and animations will visually slow down with a frame-based system. But if you used time based and the framerate drops to 45FPS, animations would happen before they're actually supposed to in the game, because the time based model is assuming the framerate is a constant 60FPS.

0.o - Are you sure that's correct 0.o?

If that was the case, then time based motion/animation would never be used, because time based animation is supposed to allow the same game run (at the same speed) on faster and slower computers. It works off time, not frames.

If you had a motion system, which relied on a timing system, which in-turn relied on a FPS system... Why wouldn't you just go with motion based straight on the FPS System ?

GR33B wrote:

XianForce wrote:

GR33B wrote:I've found frame-based to be the best choice, because even though it is frame-rate dependent, it ensures consistency. And that's good when your animations have to sync up with another part of the game.

That's precisely my point - it WON'T be consistent if there is a drop in framerate...

But to me I think, if the frame rate is capped, then frame based would be the best choice.

I was assuming you would have the frame rate capped. Say you're going for a steady 60FPS, if it drops to 45FPS for a few seconds, the game and animations will visually slow down with a frame-based system. But if you used time based and the framerate drops to 45FPS, animations would happen before they're actually supposed to in the game, because the time based model is assuming the framerate is a constant 60FPS.

No because you'd control the ANIMATIONS with a time based system aswell.

Ginto8 wrote:the issue with time-based motion is that, if it starts lagging, collision can be severely messed up. So time-based motion shouldn't really be used unless you NEED synchronization.

You know, this is a REALLY REALLY good point that becomes a severe issue when doing physics simulations that nobody has really acknowledged.

I have yet to run across a physics engine that is NOT time based.

The bottom line is that when you get right down to it, decoupling game logic from rendering is just a wise idea. This can be a very elaborate process and really requires you to analyze the performance of your code. The main implication here has already been mentioned. You're going to achieve a much more accurate and smoother simulation from a time based model. The idea here is that IF...you do this right....it will NOT start lagging.....ever. That's the whole concept. It's an effort to slow down and meter the ENTIRE application so that your updates from all systems occur at specific intervals. (Get used to "time per frame" instead of "fps"....."Fps" is meaningless)

This is especially important when dealing with pipeline optimization. Alot of games do a sort of "pseudo vsync" behind your back An efficient renderer should be able to plaster frames up at around a 10-20ms per frame. Game logic updates are usually far under that figure. So you can see the disjoint.

So if that figure holds up and our renderer is sitting around 80-100FPS, which is around a 10-13ms per frame time, then we should be able to say that we're actually WASTING time by letting the renderer run all loosy goosy balls to the wall the whole way down simply because that sort of "high FPS" thing is a huge farse. I don't have time to go into THAT but by metering the renderer, we can actually perform pre-render steps for the next frame, get the game logic out of the way for the next frame, (better predictions) and actually achieve a much more "fluid" simulation....albeit at a slower speed.

So, we meter the entire game loop on a delta time. This time is picked on something that all major players can realistically meet. We know that 60Hz yields us about 17ms of time to play around with per frame. Therefore we would not choose a 17ms meter if we know that the renderer is coming in at 15ms and the game logic at 4-5 msec. We would have to skip rendering this frame entirely and save it for the next....which you don't want. However....if we clock in around 10-12ms on the renderer and 2ms on game logic (this is a realistic figure), then we've achieved a very nice equilibrium with some time to spare and a very fluid simulation running at 60Hz. (No burps).

However, this is under the assumption your code is running "optimally". If you look at the running graph of a poorly designed renderer you'll see it looks like an EKG (The heartbeat rhythm). It'll be nice & smooth, but at every 40ms or so you'll see a massive spike. This leads to alot of the "pitfalls" you see with a time based pipeline because you have to at this point actually defer that frame or get rid of it completely. Same goes for game logic. So you'll see that doing this really requires you to profile your code out and see how its looking under the hood before you start messing with the timing

Whoda thunk competitive game engines actually purposefully RETARD the FPS.

qpHalcy0n wrote:I have yet to run across a physics engine that is NOT time based.

Oh, I completely agree. I'm just saying that if you are coding a simple game that requires low specs (and isn't prone to framerate drops), having everything remain frame based is a million times easier.

When you're worrying about physics updates, you have shit like damping that becomes raising a float to a float power, making sure nothing flew through anything else, and all of that mess. Even moving the window around while things are moving (without specific code to check for that shit) completely fucks everything up and can send entities literally flying through walls.