🔒 Locked

Re: Timing

Started by LagunaCloud Nov 1, 2005 at 6:54 AM 1 replies 500+ views

Original Post

Nov 1, 2005 at 6:54 AM

Scanning the forums I've heard arguments about locking frames per second and timing. I've been locking frames per second and haven't thought about timing until I read those, so while I was at work I began to think that instead of measuring it in frames, I should measure how long it takes to move to a specific spot, reading the seconds and if it is a Sprite that I'm maneuvering, I can take 1Second / SpriteFPS and get the timing of the frame change, without locking the frames per second, am I right or should you guys slap me and call me a moron?

dave

Nov 1, 2005 at 7:59 AM

Well if you lock the framerate then it is easier to do calculations for movement etc because the increase/decrease is always going to be the same. The other solution is letting the game run as fast as possible and calculating the movement amount on the fly etc. I would prefer the latter. It seems less of a shortcut to me than the fixed fps. The only problem that arises with fixed fps is that if it gets run on a machine that is so lame it cant handle say 60fps then the game becomes slow-motion, which sucks.

ace

DIB

Nov 1, 2005 at 12:05 PM

I have always had great luck calculating the time since the last frame. Then all time-based calculation know how long it has been since they moved last, and move the appropriate distances. Locking the frame rate only works if the application is always running at that frame rate. Often, you can run slower than this ideal rate due to calculations, drawing, etc. When you do, all your physics/motions are wrong. Calculating the time since the last movement is fairly cheap anyway.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.