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?

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.

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?

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?

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

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

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.

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.

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 accelerationoften I see people doing it like this:velocity += time * accelerationposition += velocity*time

but this is wrong, you have to donew_velocity = velocity + time * accelerationposition += (new_velocity + velocity)/2 * timevelocity = new_velocity

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

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