Game Timing

Discussion in 'Game Development (Technical)' started by Sean Doherty, Nov 20, 2005.

  1. Sean Doherty

    Original Member

    Joined:
    Jul 31, 2004
    Messages:
    433
    Likes Received:
    0
    I have been playing around with delta Time and it appears that it creates a lot of challenges! I was wondering if people prefer delta time over fixed framerate; if so why or why not? I am primary interested in people writting action and arcade games, it probably does not matter when it comes to puzzle or turn based games.

    Thanks
     
    #1 Sean Doherty, Nov 20, 2005
    Last edited: Nov 20, 2005
  2. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    You'd be surprised. Puzzle games have a lot of effects and flashy bits that need to run at the proper speed.

    I prefer delta time but that's just me. I've never done anything too fancy in terms of physics so I don't know if fixed frame rate is better for that sort of thing or not.
     
  3. ogracian

    Original Member

    Joined:
    Dec 10, 2004
    Messages:
    23
    Likes Received:
    0
    Hello,

    After getting some "bugs" which only pressent at low fps, I decide to go for
    a fixed timestep and I could not be more happy, now my game (woring title :D ) is really solid and behaves consistently independent of framerate.

    I suggest the following document, which explain really well how and why use a fixed timestep:

    http://www.gaffer.org/articles/Timestep.html

    Hope that helps you, regards
    Oscar
     
  4. Savant

    Original Member

    Joined:
    Feb 8, 2005
    Messages:
    1,674
    Likes Received:
    0
    That should happen regardless of the timing method you use. That's the whole purpose behind a timing method. If you weren't seeing that before, are you sure you were doing it right? :)
     
  5. Kestral

    Original Member

    Joined:
    Oct 3, 2005
    Messages:
    74
    Likes Received:
    0
    I use fixed point vars for my 2D position, velocity, and accel vectors - 32-bit ints with the lowest 8 bits being the fractional part. My projects feel and play the same using the "dt = newTime - currentTime" method whether I am running at 10 fps or 100 fps. The author of this article might have felt that the errors introduced by this method were significant in his case (physics simulation), but I do guess that this is "good enough" for a high percentage of indie game projects.

    Thoughts?
     
  6. Sean Doherty

    Original Member

    Joined:
    Jul 31, 2004
    Messages:
    433
    Likes Received:
    0
    Oscar,

    If memory serves, fixed Time step is a combination of Delta Time and only rendering at certain intervals. It is not really fixed frame rate.

    I guess what I have noticed is that there are a fair amount of bugs that appear at low frame rates with delta time.
     
  7. Chris Evans

    Moderator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,162
    Likes Received:
    0
    If you're doing an action/arcade game and you want your game to be playable on a wide range of systems, definitely go with delta time. I learned the hard way...

    My first game release (Pow Pow's Great Adventure) is framed-based and I definitely regret it now. Frame-based updates are good for console games or if you're targeting a fixed platform spec. But if you want your game to be playable on a wider range of PC systems, then I definitely recommend using delta time. With frame based updates, if someone is only getting 7-10 fps, but the game is meant to run at 30 fps, the game will play like molasses and pretty much be unplayable. With delta, someone at 7-10 fps may have choppy visuals, but it at least the game will run at proper speed and be mostly playable (albeit slightly less responsive).

    So earlier this year, I switched all my in-development games to delta time. Changing a frame-based game to delta time is a lot of work, but if you use delta time right from the start of the project it's pretty painless.

    Just remember even though you're using delta time you still need to put caps on your movement increments. So even though your space ship might move 20 pixels per second, put a maximum limit of 30 pixels per update so the space ship doesn't jump across the screen if the user's computer stutters for a couple of seconds.

    I also use some physics in my current game and still use delta time. Yeah it's a bit tricky, but worthwhile in the end. For example, the physics engine updates at 30fps (or every 30 milliseconds). If on a slow computer it's been 72 milliseconds since the last update, then I run the physics engine twice and store the remaining 12 milliseconds in a variable. Use that value from the variable to offset when the next update should occur. There's a lot more math I'm leaving out, but that's the basic idea and it works great! :)

    So bite the initial learning curve and use delta time. :D
     
  8. Chris Evans

    Moderator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,162
    Likes Received:
    0
    Like I said, use caps on all your movement increments, so your sprites won't jump across the screen on low frame rates and stutters. Also, always check your collision detection before you actually move your sprites/entities.
     
  9. svero

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    3,392
    Likes Received:
    6
    I use fixed timing in all my games except Space Taxi 2. That was the only one where the thrusting didn't seem quite as smooth as I'd have liked.
     
  10. Sean Doherty

    Original Member

    Joined:
    Jul 31, 2004
    Messages:
    433
    Likes Received:
    0
    Did you fix the issue by using delta time or did delta time cause an issue with the trust? I assume it fixed the issue?
     
  11. svero

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    3,392
    Likes Received:
    6
    Space taxi uses fractional time, which is essentially a delta time system.
     
  12. ogracian

    Original Member

    Joined:
    Dec 10, 2004
    Messages:
    23
    Likes Received:
    0
    Well, as Sean says, using a fixed timestep is not relly a FIXED FRAME RATE, like locking your game to run at a fixed frame rate like 18 FPS,which in my humble opinion is not a good solution for pc games, it could work on consoles but not on pcs due to different system configs.

    The method suggested in the "Gaffer" article, shows how to update your game at a fixed time step, so this way all your game behaves exaclty the same way no matter your frame rate, obiously at higher fps, your game will be more smooth.

    So for example, using a VARIABLE TIME (delta time), here is how the works:

    You move all your game objects using deltaTime (to keep it framerate sync), in the following way:

    player.pos += vel * deltaTime;

    Using the traditional deltaTime, this approach gives you a variable increment in your players pos because deltaTime change frame by frame so if your game is running at 60 FPS, your deltaTime is 1/60, then at other point in your game, runs at 30 FPS, so the player will move twice the last frame!.

    This "jumps" in your delta time could cousetroubles like miss collisions, desync, and so on.

    By other hand using the fixed time step you avoid all this behaviour, because you use a fixed timestep in the above example if your game runs at 60 fps and your fixed timeStep is 0.01, the player will move exactly the same increment per update (not by frame, because the method could update your game more than one time per frame), so if your game runs at 4 FPS (0.25), and using a fixed timeStep of 0.01 the game will be update 25 times to keep it frame sync.

    Worth mention that I use a slightly differen arpoach than the "Gaffer", to avoid a remainder, here is how I handle it:

    Code:
    const int FIXED_TIMESTEP = 1.0f / 100.0f;
    
    //
    // Clamps deltaTime
    if (deltaTime > 0.25f)
    	deltaTime = 0.25f;
    
    //
    // Updates game using a fixed time step
    float timeStep;
    while (deltaTime > 0.0f)
    {
    	//
    	// Update time step
    	timeStep = deltaTime;
    	if (timeStep > FIXED_TIMESTEP)
    		timeStep = FIXED_TIMESTEP;
    
    	//
    	// Updates current state
    	m_pGameStatesMgr->Update(timeStep);
    
    	//
    	// Dec deltaTime (to match fixed time step)
    	deltaTime -= timeStep;
    }
    
    //
    // Draw Game
    m_pGameStatesMgr->Draw();
    
    
     
    #12 ogracian, Nov 21, 2005
    Last edited: Nov 21, 2005
  13. Chris Evans

    Moderator Original Member

    Joined:
    Jul 26, 2004
    Messages:
    1,162
    Likes Received:
    0
    This is what I use as well.
     
  14. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    Every retail game I've worked on has used delta time for the main game and maybe a fixed rate for the physics where applicable. It takes a little getting used to but it's straightforward really. And it lets you introduce things like a slow as you like bullet time while still being completely smooth.

    My biggest issue with a fixed rate is where the bottleneck lies. If it lies in the rendering then it's a great solution but if it lies with the update you can be in trouble. (As far as I'm aware). Basically, if you've timed everything so your update runs at 120 times per second but the CPU can't handle that, then where do you go?

    And just to be fair, a problem with the delta version lies in over compensating. Imagine the following code
    Code:
    ball.dy = 9.8f * delta;
    ball.y -= ball.dy;
    
    if (ball.y < 0.0f ) 
    {
        ball.dy = 0.0f;
    }
    You can't guarantee how far the ball would go less than zero. ball.y might end up as -0.1f or -0.9f or -10000.0f depending on what your frame rate is like.

    You end up ensuring the ball is where you want it to be.
    Code:
    if (ball.y < 0.0f)
    {
        ball.dy = 0.0f;
        ball.y = 0.0f;
    }
    I hope that makes sense. It's 3.15am and late so blame that if it's wrong!
     
  15. princec

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    4,873
    Likes Received:
    0
    I use fixed time, mainly because it's loads easier, and it looks much better in 2D games. The trick is to pick a fairly poor spec that runs it at full framerate.

    Cas :)
     
  16. Mike Wiering

    Original Member

    Joined:
    Jul 28, 2004
    Messages:
    246
    Likes Received:
    0
  17. gosub

    Original Member

    Joined:
    Sep 10, 2005
    Messages:
    151
    Likes Received:
    0
    Use both

    I use fixed time for movement and hit detection, so all games run exactly the same on all systems regardless of the frame rate. Then I interpolate to the nearest millisecond for rendering so everything runs smoothly regardless of all the weird frame rates you can encounter.

    There's a bunch of problems with variable delta timing, such as having an object jump over another object without detecting a collision (hiccup) or having the game run differently depending on the frame rate. The problem with purely a purely fixed delta is that a 100th of a second (or any reasonable fixed delta you choose) won't render smoothly at 60FPS.

    So my vote is to use both.

    -Jeremy
     
  18. Sean Doherty

    Original Member

    Joined:
    Jul 31, 2004
    Messages:
    433
    Likes Received:
    0
    Hi Gosub,

    I don't follow? You say your using fixed time but everything is running at the same framerate? Can you expand?

    Return
     
  19. luggage

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    2,132
    Likes Received:
    0
    gosub: if you use delta timing and it behaves differently at different framerates then you have implemented it wrongly. Seriously - there wouldn't be a 'which one's best' question if one method worked and the other didn't would there?

    At the end of the day it's a matter of preference.
     
  20. dima

    Original Member

    Joined:
    Feb 7, 2005
    Messages:
    345
    Likes Received:
    0
    The point of fixed step is so everything runs the same. If you want your logic running at 1000 FPS, it will, and it will do so on every PC no matter the framerate. You still render every frame, but update code at different frequency, so you get fixed step updates with frame rate independence.

    I personally find that fixed step timing is the BEST way to go. Benefits are mostly in stability in timing and reproducing behaviours. You still use delta-time with fixed step timing, except it never changes. Code runs at the same speed on every machine and you can have much higher precision for phisics and such. Definitely the way to go. If you use low frequency updates, might be worth looking into interpolation for silky smooth animations. I made small test which ran at 10 fps and interpolated the animations, ran as smooth and silky as a 1000 fps game.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer