When to Use Delta Time

Newbie & Debugging Questions
#1

Hello there.

I have been making a 2D Shooter game like Touhou. I use delta time in the calculation of x/y position. I add delta time up to represent the time a game object (ex: enemy, enemy bullets (danmaku)) has been alive. I control enemy’s movement and when to take a shot based on this time. I have to use this calculation if I’m moving the objects with delta time otherwise it will act differently on slow/fast pc. I round it up to the first decimal place. 0.1 second updates the game about 7 times/frames. I’m starting to have a doubt whether I should be using delta time or not. It would make things so much easier if I could just go by counting frames.

My question is… When is the appropriate situation to be using delta time? Is it important to use it?

Thanks

#2

DeltaTime is mostly used to keep track of exactly the amount of time that has passed. Going by number of frames means that your game loop guarantees you 16.6ms delta time all the time, any slow down and everything is thrown off.

#3

Right, going by counting frames throws me off on slower computers especially with lots of movements.

I’m trying to understand variable frame rate and fixed frame rate. My understanding so far is that fixed frame rate does not use delta time to calculate next position or anything else in the game. If you specify 60 fps, if needed, it sleeps to make it 60 fps. Variable frame rate uses delta time which updates whatever is missed at once. Is there more to it? Does it sleep?

For example, which frame rate is this game loop using? http://www.java-gaming.org/topics/basic-game/21919/msg/199509/view.html

#4

That one uses deltaTime, as seen from the update method.

#5

I’m very confused.

I’m trying to decide whether I should use delta time or not(ex: x += vx).

What I don’t like about delta time is that it makes it difficult to control the enemy and bullets’ movements by triggering. If I don’t use delta time and go with x = vx, the screen will pause if it lags, but that should be about it, right? Wouldn’t enemy objects pass through player if delta time takes long?

#6

How is it difficult to control?

And yes so the trick is to set a maximum delta time value and just call update(…) however many times needed to completely “send” the full delta time (note that this is not a good idea if the logic takes way too long).

#7

Don’t use variable length delta time for 2D games; it looks and feels absolutely awful. Use constant tick rate. Slowing down is actually better than skipping frames.

Cas :slight_smile:

#8

Using a fixed frame rate is the easiest approach, and I definitely recommend it for beginners. It simplifies the game logic (you just write x+=vx, not x+=deltaTime*vx), and it guarantees that the game’s behaviour is the same on all machines (which can be important if you’re doing any physics-type simulations).

The drawbacks are that your game can’t increase its frame rate to take advantage of more powerful hardware (I think that’s a very minor issue in practice; some people get very worked up about it though), and that the game will get jerky if the game loop struggles to maintain the frame rate for some reason (which is annoying, but forgivable for beginner projects).

Unfortunately, no one can agree on the best code for a fixed frame rate game loop in Java. ::slight_smile: Search the forums and you’ll find a lot of discussions. Just pick a bit of code (like the game loop below) and don’t worry about it too much.

That game loop runs (or attempts to run) at a fixed rate of 60 frames per second.

The reason why (as ra4king says) that game loop supplies the value of deltaTime to its update method is so that developer has the option of writing variable frame rate-style code in case the frame rate becomes erratic. But you’re free to completely ignore the value.

The deltaTime in that code is the measured time since the last frame. Ideally it will always be close to 17 (one 60th of a second in milliseconds), but that can’t be guaranteed. If you like, try printing out the value to see how reliable it is.

As I’ve said, in practice you can just ignore deltaTime and carry on making your game.

Simon

#9

Actually, for any simulation I’d suggest fixed update rate as well…equations become too hairy (bigger, harder to debug) if one allows variable rates.

#10

yes, listen to the people above me.

fixed frame rate - try to make sure that it runs 60 fps all the time.

#11

I was firing bullets at specific time for a danmaku. Using sum of delta time, I was only able to identify the hook at x.x seconds. (I’m sure there are ways to make it work, but I think it gets complicated.) With frame counts, I can specify for example, fire this one at 5th frame, every 2 frames, or etc.

Very interesting.

Now it makes more sense to omit delta time for my game.

I was wondering when would it be a case to use variable frame rate? I read that 3D games, networking games, and even busy 2D 60+ FPS games are examples of this case.

Thank you for the comments.

#12

I made for myself some game time manager class which manages fixed and varying time steps, I append just as many listener as I need and am happy with it.

I would say that there are cases for each approach(fixed varying). Varying time steps can produce smother animations but simulations can get unstable.

@miga to handle it with varying time steps you could do something like this


update(double delta)
{
  switch(state)
  {
    case preparing:
      double d = getGameTime() - starttime; // gametime is the global time
      if(d>0)
      {
          state = living;
          update(d);
      }
    case living:
      .. do normal update..
  }
}

PS:
as I define fixed timesteps, something like a game shouldn’t run slower or faster on different PCs with it also. I think the error a lot of people are doing is that they simulate with a fixed time steps but aren’t synchronizing it with the real time. Adding a Thread.sleep helps only stopping the programm from running faster but not slower.

PPS: what I use


public interface GameTickListener {
    public void update(int tickCount);
}
 
public interface GameTimeListener {
    public void update(double timeDelta);
}

...
public void update() {
        long start = Start.time;
 
        long now = System.nanoTime();
 
        long delta = now - start - elapsed;
 
        updatedTimeListener(delta);
        updatedTickListener(delta);
 
        elapsed += delta;
    }
...

http://pastebin.com/6hJFHMRF

#13

So, don’t you think it’s needed to use fixed tick on simple 2d game with libgdx?

#14

why should it be?
I don’t think that there is great of a difference between the two of them

#15

Fixed ticks are just dead easy to code…

Cas :slight_smile:

#16

Take the most basic simulation (H.S. equations) and expand with (t) & (2t) and see what you get.

#17

of course you have to do your math right. When doing some approximation based on iteration it doesn’t matter if you use fixed or varying time steps depending on your math you get right or wrong approximation. With varying time steps you have of course the problem that when you aren’t using a correct approximation you can get different results.

for example take a normal approximation for acceleration
often I see people doing it like this:
velocity += time * acceleration
position += velocity*time

but this is wrong, you have to do
new_velocity = velocity + time * acceleration
position += (new_velocity + velocity)/2 * time
velocity = new_velocity

#18

Try expanding.

#19

sry but which equation do you mean? Hunter-Saxon?(onlyone I could google with h.s.)

#20

Nah, I just mean pre-calculus versions. Expanding is fine…now add collisions. For deterministic you now have to properly deal with time-of-impact…now add friction. You see where I’m going?

(edit)
For an example: Varlet integration. SEE: Time corrected Varlet