next »

[pixeltao]

I'm a self taught programmer and I've got no formal education in maths or programming, so I might lack some notions to understand this.

However, I've been making games for years and yet I don't fully understand why you'd use frame-independent movement if your timesteps (game logic loop) are already fixed.

So far, I've always been using fixed timestep (at 60 fps) + frame-dependent movement and these are the pros and cons in my opinion:

Pros:

• The movement maths are simple
• I've always found pixel per step/frame to be more intuitive than pixels per seconds (especially when accelerations are involved)
• If the game slows down, your physics don't explodes, it only slows down
• You don't have to worry about your game running too fast/slow on some machine because timesteps are fixed

Cons:

• If you decide to change the fps of your game to something else (from 60 to 30 for example), you have to rewrite your movement code.

And from what understand about using fixed timestep (at 60 fps) + frame-independent movement, the pros and cons would be:

Pros:

• You can easily change the frame-rate of your game without re-writing any code
• Pixels per second can work better with some game engines that are time based
• Movement always look constant (creates skipping instead of slowdowns)

Cons:

• Your movement maths are more complex
• Calculations (using Euler, Verlet, RK4) to compute your movement (especially with acceleration involved) can give variable results depending on your framerate. This can cause weird issues such as characters not jumping at a constant height or collision bugs.
• Doing calculations for non-linear acceleration is a nightmare

Personally, I think that the benefits of using frame based movements outweigh the benefits of using time based movement. For me, frame based movement is simpler and more predictable (worst case scenario: I prefer slowdowns over unpredictable behaviors). However, except maybe for Game Maker developers, time based (frame-independent) movement has been widely adopted and seems to be a general consensus among programmers in the games industry. You often read that your movement calculations MUST be frame-independent without a detailed explanation given.

I've read dozens of posts and articles about this and I still can't find a satisfying argument to convince me to start using delta-time with pixel per second values. Can anyone explain this better to me?

[oahda]

If you decide to change the fps of your game to something else (from 60 to 30 for example), you have to rewrite your movement code.

I don't have an answer to your main question, but isn't this very easily fixed by having some global variable that all movement is multiplied by, so that you can change it in just one place if you ever decide to change the FPS?

[pixeltao]

You're right. This one is a tiny disadvantage if your code is well structured.

[Richard Kain]

Well, for starters, not all game logic is gated by frame updates. It's entirely possible to rig up an application to update as often as possible, but only draw to the screen at given increments. With this, you can have far more granular logic for interactions, while still gating the drawing of your application in order to optimize performance.

But for me, there is an even better reason. Disconnecting your game logic from an frame-drawing loop allows you to alter and scale the timing logic of individual scenes and/or objects as you see fit. This allows you to fast-forward or slow-down elements in your application as you see fit, whenever you please. There's a lot of neat stuff that can be done with that.

[pixeltao]

If your game updates as fast as possible, then you're talking about variable timestep rather than fixed timestep, right? In that case, I understand why you'd want to use frame-independent movement. What I'm not sure to understand, is why you'd use frame-independent movement if your timestep is fixed. Does it make your life easier with some other aspects of developing a game (such as networking, or if you're making a 3D game, for example)? Or is it just a matter of preference?

The examples you give are really interesting though. I never thought of having game logic at various speeds in different scenes or objects. Maybe I'm just too used to thinking in terms of frames for everything when I code.

[Richard Kain]

A common use-case in modern 3D gaming has always been performance scaling. Having a fixed timestep doesn't do you much good if your game hits a performance hiccup, and your update loop drops below where you targeted it at. Situations like that will cause your whole application to stutter and slow down, updating based on the rendered frames that are now lower than you originally intended.

Now, you don't see that sort of scenario as much these days. Modern hardware has reached a point where smaller developers can usually play it a little more fast and loose with performance. The majority of smaller indie games frequently tick over at 60 fps no problem, even on an under-powered laptop or tablet. But if you try to push enough elements at once, or have a scene that becomes overly complex, there is always the danger of forcing the platform below your targeted timestep. If the hardware is pushed hard enough, the update loop will falter. A target timestep does not guarantee that you will always hit that mark.

Frame independent-movement is a way of insuring that the logic of the game is consistent, even if the framerate is not. Engines built on that principle will continue to update their game logic correctly, even if the update loop drops below where you want it. The framerate might falter, but the game will continue to run as expected.

But as I said earlier, it's more of a case-by-case basis. For some games a fixed timestep might make more sense, or be necessary to implement specific features. Some fighting games are so frame-dependent that they HAVE to be designed around that loop. I generally go for the frame-independent approach, but I also tend to be a bit paranoid and like to future-proof things.

[ThemsAllTook]

Frame independent-movement is a way of insuring that the logic of the game is consistent, even if the framerate is not. Engines built on that principle will continue to update their game logic correctly, even if the update loop drops below where you want it. The framerate might falter, but the game will continue to run as expected.

This hasn't been true in my experience, and I'd consider it the primary reason to use a fixed timestep. Since floating point numbers have finite precision, rounding will affect your outcome in subtle ways if you run with different time scales. Even if all of your math is phrased perfectly to adapt to any timestep size, the reality of how numbers are represented in a computer makes it impossible for behavior to be consistent when run at different intervals.

If you're OK with nondeterministic behavior, this can work. However, if you need your game to behave consistently for the same inputs (for example, if you want to implement a replay system, or to have networking, or if fine details of your simulation are crucial for gameplay), this isn't the way to go. A fixed timestep categorically solves the nondeterminism problem (at least from a time scale point of view; floating point calculations give different results between CPUs and operating systems, but that's a separate topic).

What I've done in the past when I wanted time scaling was to implement graphical interpolation on top of a fixed timestep. That way you can slow down and still see things move smoothly, even though not every frame you see has its own timestep behind it. There is still the potential problem of not being able to keep up with your chosen timestep if the simulation gets too complex; that's the tradeoff you make for stability. As you say, modern hardware is pretty capable, so unless you're doing something extremely expensive, this might not ever end up being a problem. If it is, you can still scale back on the number of ticks per second and let your game slow down without changing anything else.

[powly]

If you decide to change the fps of your game to something else (from 60 to 30 for example), you have to rewrite your movement code.

I don't have an answer to your main question, but isn't this very easily fixed by having some global variable that all movement is multiplied by, so that you can change it in just one place if you ever decide to change the FPS?

Technically yes, but if you want to retain the feel of your movement you’ll have to change a bunch of things — for example doing friction as ”velocity *= 0.98” will become ”velocity *= sqrt(0.98)” if you double the frame rate.

[Polly]

One of the problems frame-independent movement fixes is stuttering / jerky-motion.

- If your game delivers 60fps on a 60Hz monitor, you're golden.
- If your game delivers 60fps on a 120Hz/240Hz/300Hz etc. monitor, that's fine.
- If your game delivers 60fps on a 30Hz monitor, that's fine too ... who the heck has a 30Hz monitor though.
- If your game delivers 30fps on a 60Hz monitor, that's ( sort-of ) fine ... might be time to upgrade your computer though.

However, the following situations aren't as great.

- If your game delivers 52fps on a 60Hz monitor, that's bad.
- If your game delivers 60fps on a 75Hz monitor, that's bad.
- If your game delivers 60fps on a 144Hz monitor, that's still pretty bad.

Let me explain that last one specifically ( 60fps on 144Hz monitor ). Lets say you have a game running at 60fps on a 60Hz monitor where you're walking at a constant speed towards a wall. The first 8 frames might look something like this ..



Now if you run that same game on a 144Hz monitor you'll end up with duplicate frames ( obviously ). Duplicate frames aren't a problem in itself, however take a look at the pattern in which they appear ( basically 3-2-3-2-2 over-and-over ).



The fact that some frames are displayed for 3 frames and others only 2 frames creates a sense of jerky motion. Using frame-independent movement is one of the solutions to solve that

+ Obviously if can also alleviate the sense of slow-down when your game can't reach the desired frame-rate, but that's another problem.

[[bk]door.maus]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

The game is based on a client/server architecture (hence the low updates per second). The client builds a scene graph, which is then interpolated between this frame and the previous. Thus rendering is simply interpolating things like position and rotation by the 'frame delta'. Very simple, technically, and it looks great.

[ProgramGamer]

So you use frame interpolation then?

[Polly]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

That's another solution yes There are a couple of ways to tackle this issue .. each have their pros and cons.

[J-Snake]

I don't fully understand why you'd use frame-independent movement if your timesteps (game logic loop) are already fixed.

Companies do it so that they are able to change the fixed time step per platform. For example, the game can be set to run in 30hz on xbox one, and 60hz to run on the more powerful xbox one x.

Frame independent-movement is a way of insuring that the logic of the game is consistent, even if the framerate is not.

Replace "logic" with "speed" and you might have a point. Consistency in game logic can only be achieved with a fixed time step in general, it is a mathematical necessity.

[pixeltao]

Thanks for all the answers. It definitely helped understand some of the reasons why you'd choose one approach over the other.

I think, in my case, I never really needed to uses frame independent movement because the type of games I've been making and their target platforms could work without any issue while being frame based (also, I've always made sure that my timestep was fixed). On top of that, the fact that I've learned programming through Game Maker over 10 years ago really made pixel-per-frame movement an habit in the way I code games.

[Daid]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

Won't input feel laggy? As it can take up to 100ms to start seeing the result if your input.

[Ordnas]

In case it can be useful:

http://gameprogrammingpatterns.com/game-loop.html

[[bk]door.maus]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

Won't input feel laggy? As it can take up to 100ms to start seeing the result if your input.

It doesn't feel laggy, but it's a slower-paced RPG.

RuneScape has a 600 MS delay between input & action and you get used to it quickly.

[Daid]

Ah, yes, then input delay isn't much of an issue. (But, "getting use to it" is a bad excuse IMHO)

Last thing I made that other people played was a platformer, and there I had some input delay of 1 frame due to the mistake of doing input-handling, rendering, updating instead of doing updating before rendering. And someone did notice that. I fixed it, and silently updated it, and then that person came asking if I fixed it, as he noticed a difference.



So I think the awnser to the main question here is, depends on what you are making.

[Ordnas]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

Won't input feel laggy? As it can take up to 100ms to start seeing the result if your input.

It doesn't feel laggy, but it's a slower-paced RPG.

RuneScape has a 600 MS delay between input & action and you get used to it quickly.

10 updates per seconds feels a bit too extreme and curious, in case it is an online game or a heavy graphics game, I can't think any benefit from that. It is just an IMHO, if it works for you, good! 

[[bk]door.maus]

My game runs at 10 updates per second, but using frame rate independent rendering, can run smoothly on a 144 Hz monitor. It runs smoothly at 30 FPS, 60 FPS, whatever, and doesn't feel like the game updates only 1/10th a second.

Won't input feel laggy? As it can take up to 100ms to start seeing the result if your input.

It doesn't feel laggy, but it's a slower-paced RPG.

RuneScape has a 600 MS delay between input & action and you get used to it quickly.

10 updates per seconds feels a bit too extreme and curious, in case it is an online game or a heavy graphics game, I can't think any benefit from that. It is just an IMHO, if it works for you, good!  

There's going to be online play in the future, hence the 10 updates per second.

The gameplay is smooth:



If it proves to be a problem it's literally a single line of code I need to change, but no players have complained about it thus far.