Ticks vs. FPS

[ghostsoldier23]

I've heard of the concept of using ticks and FPS in animation.  I assumed "ticking" is updating the game logic where as FPS is, obviously, the frames rendered per seconds.  So FPS measures the frames rendered per second and TPS is ticks per second.

I tried implementing this into my indev game, but it seems that making the tick count be lower than the FPS (which theoretically it should be), hurts performance (i.e. flashing/not rendering correctly).

Is this what ticks are supposed to be used for?  Are they even necessary?  Or should I just be updating game logic with each frame render?

[ra4king]

Logic should be kept at a steady pace while rendering can be either set at the same pace as the logic or let loose.

[ghostsoldier23]

Ok.  So its ok to have 120 "ticks" (logic updates) per second at 300 fps (renders) per second?

Games published by our own members! Check 'em out!

[ra4king]

Yep that's fine.

EDIT: by the way, you said "second" twice: 300 fps (frames per second) per second

[lhkbob]

Usually when you separate logic ticks from rendering, you don't just render more frames if you can.  If you don't do anything extra, those additional frames should render the exact same images so the player can't notice and they will perceive updates at the logic rate.

However, you can interpolate between logic and rendering so you can do logic updates at 30 times/second and render at 60 times/second.  Every other rendered frame is a blend between the previous logic state and the one just computed.  This works well with physics that needs to be computed at a fixed time interval.

Alternatively, separating the logic and the frames gives you the benefit of dropping rendered frames when it's impossible to render as fast as the logic requires.  If you can't get 60 updates/second with 60 fps, you can render at 45 but still update at 60.  This can produce a better experience for a player, especially in a multiplayer setting where everyone needs to update the game state at the same rate, or in physics where you need the simulation to step at realtime.  You can't just update physics with larger time deltas or the error in the simulation increases. 

Dropping frames allows you to increase the time delta between visual updates while maintaining a more consistent physics/ai update rate.

[ghostsoldier23]

Yep that's fine.

EDIT: by the way, you said "second" twice: 300 fps (frames per second) per second

Oops 

Nice catch.

[MunchGamer]

I found this tutorial really useful for separating the idea of updates/ticks from frames: http://www.java-gaming.org/topics/game-loops/24220/view.html

I'm currently running a variable timestep loop in my implementation (seemed preferable to having a 1 frame latency via fixed timestep interpolation)