Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (480)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (547)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  When to Use Delta Time  (Read 9057 times)
0 Members and 1 Guest are viewing this topic.
Offline miga

Junior Member


Medals: 2
Projects: 1



« Posted 2012-02-10 03:54:50 »

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

Miga's Hobby Programming - http://www.migapro.com
Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #1 - Posted 2012-02-10 04:17:50 »

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.

Offline miga

Junior Member


Medals: 2
Projects: 1



« Reply #2 - Posted 2012-02-10 04:30:57 »

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

Miga's Hobby Programming - http://www.migapro.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #3 - Posted 2012-02-10 06:00:51 »

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

Offline miga

Junior Member


Medals: 2
Projects: 1



« Reply #4 - Posted 2012-02-10 06:24:26 »

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?

Miga's Hobby Programming - http://www.migapro.com
Offline ra4king

JGO Kernel


Medals: 345
Projects: 2
Exp: 5 years


I'm the King!


« Reply #5 - Posted 2012-02-10 06:57:04 »

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).

Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2012-02-10 10:08:01 »

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 Smiley

Offline dishmoth
« Reply #7 - Posted 2012-02-10 10:18:31 »

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. Roll Eyes  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.

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

Offline Roquen
« Reply #8 - Posted 2012-02-10 10:38:23 »

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.
Offline Cero
« Reply #9 - Posted 2012-02-10 15:37:01 »

yes, listen to the people above me.

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

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline miga

Junior Member


Medals: 2
Projects: 1



« Reply #10 - Posted 2012-02-10 16:28:07 »

How is it difficult to control?

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.

Miga's Hobby Programming - http://www.migapro.com
Offline Danny02
« Reply #11 - Posted 2012-02-10 17:11:57 »

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
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
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
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
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
Offline ReBirth
« Reply #12 - Posted 2012-02-11 02:59:28 »

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

Offline Danny02
« Reply #13 - Posted 2012-02-11 11:37:16 »

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

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #14 - Posted 2012-02-11 11:44:11 »

Fixed ticks are just dead easy to code...

Cas Smiley

Offline Roquen
« Reply #15 - Posted 2012-02-11 12:09:15 »

Take the most basic simulation (H.S. equations) and expand with (t) & (2t) and see what you get.
Offline Danny02
« Reply #16 - Posted 2012-02-11 14:23:41 »

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
Offline Roquen
« Reply #17 - Posted 2012-02-11 14:36:01 »

Try expanding.
Offline Danny02
« Reply #18 - Posted 2012-02-11 15:03:10 »

sry but which equation do you mean? Hunter-Saxon?(onlyone I could google with h.s.)
Offline Roquen
« Reply #19 - Posted 2012-02-11 15:10:47 »

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
Offline Danny02
« Reply #20 - Posted 2012-02-11 15:15:53 »

of course for something like this one would use a fixedtick rate of i.e. 100Hz
Offline ReBirth
« Reply #21 - Posted 2012-02-12 02:43:17 »

Fixed ticks are just dead easy to code... The best correct one of example are not

Cas Smiley
FTFY  Grin

Offline Roquen
« Reply #22 - Posted 2012-02-13 11:41:37 »

I can see I was as clear as mud..let me strip down what I'm saying and retry.

Motion equations are continuous functions and "require" integration to be correct (to the model).  Numerically integration is only correct if you are using the set of constraints that the given method was designed to handle.  For example the "wrong" way above is actually correct if velocity is constant for each time slice and the "correct" way is only correct if acceleration is constant for each time slice.  (Actually I'm over simplifying for a wider target audience here.)   So neither are ever correct as we would use them.  I don't care..and neither should you.  Correctness to a model is boring.  All that really matters is that it "feel" right and behaves as expected to the player in game.  What's I'm really babbling about is another feature that I desire: being deterministic.  Which is fancy speak for giving the exact same result each time it's run, assuming all the initial data is the same.  Now being correct to a model will give deterministic results...but it's a PITA when possible and usually it impossible.  So my suggestion is to not bother.  Use the simpliest equations that give the feel you want, run at a fixed simulation rate and move on (or better yet, use an existing library).
Offline miga

Junior Member


Medals: 2
Projects: 1



« Reply #23 - Posted 2012-02-13 18:08:43 »

Thanks guys.

I'm gonna go with fixed frame rate. I guess I really don't have a reason to go for variable frame rate. Fixed rate sounds much easier to control.

Miga's Hobby Programming - http://www.migapro.com
Offline ReBirth
« Reply #24 - Posted 2012-02-13 22:34:03 »

Yeah, it has sleep and will only go slow as princec said.

Offline Danny02
« Reply #25 - Posted 2012-02-13 22:56:43 »

instead of doing

1  
2  
3  
4  
5  
6  
7  
8  
int phase = 17
...
while(true)
{
  long now = getTime();
  tick();
  Thread.sleep(max(phase - (getTime() - now)), 0);
}



doing would fix the problem of missed frames, which result in slowdowns
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
int phase = 17
...
while(true)
{
  long now = getTime();
  int ticks = now/phase - last/phase;
  for(int i=0; i<ticks; ++i)
    tick();
  last = now;
}
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

atombrot (25 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (13 views)
2014-08-16 06:20:21

Tekkerue (20 views)
2014-08-16 06:12:11

Rayexar (58 views)
2014-08-11 02:49:23

BurntPizza (38 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!