3
\$\begingroup\$

I know that deltaTime is the time the last frame took to be rendered. However, I have no idea why we have to put it inside the parameter of the render method. I also don't know how the render method takes use of the deltaTime.

\$\endgroup\$
  • \$\begingroup\$ It's hard to speculate without hard facts. Perhaps the statement "deltaTime is the time the last frame took to be rendered .. put it inside the parameter of the render method" is not correct after all? \$\endgroup\$ – Kromster Feb 15 '17 at 5:25
2
\$\begingroup\$

It allows you to compensate for jitter in rendering using gpu-side prediction. For example you have an object moving at a constant speed.

You add the speed to the uniforms used when rendering the object and the delta time. Then in the vertex shader you can do worldPos = worldPos + speed * deltaTime before doing the camera and perspective transforms (or fold it into the transformation matrix).

Example:

absolute    deltaTime   render      (calculated)
time        (last frame)position
0           0           (w+0)+0     0
10          10          (w+10)+10   20
20          10          (w+20)+10   30
110         90          (w+110)+90  200
120         10          (w+120)+10  130
130         10          (w+130)+10  140
140         10          (w+140)+10  150
200         60          (w+200)+60  270
210         10          (w+210)+10  220
220         10          (w+220)+10  230
230         10          (w+230)+10  240
| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ Could you clarify, how is "the time the last frame took to be rendered" supposed to compensate jitter? E.g. previous frame lagged and took 50ms instead of 16ms. \$\endgroup\$ – Kromster Feb 8 '17 at 9:10
  • \$\begingroup\$ @Kromster that's the second paragraph \$\endgroup\$ – ratchet freak Feb 8 '17 at 9:20
  • \$\begingroup\$ Sorry, is it true to assume that worldPos changes after each frame? \$\endgroup\$ – Kromster Feb 8 '17 at 9:25
  • \$\begingroup\$ @Kromster yeah, based on the last render or deltatime can get accumulated from the last update. \$\endgroup\$ – ratchet freak Feb 8 '17 at 9:32
  • \$\begingroup\$ I have written in notepad both options - jitter does not seem to be compesated that way. In fact, it seems to become even worse - frame after the last laggy one jumps ahead and then next one jumps back. Could you please provide an example of how it supposed to work in a table with 5-8 frames timings? \$\endgroup\$ – Kromster Feb 8 '17 at 9:34
2
\$\begingroup\$

The delta variable can be used for many things. Mainly it is used to make your game framerate independent. Framerate independent means that your game behaves the same no matter how many frames per second your game is running at.

For example; let's say you want your player to move at 600 units per second. Since we know our game updates at 60 FPS we calculate that we should move at 600 / 60 = 10 units per update. So we write this code:

public void render() {
    position += 10; // Move 10 units per update = 600 units per second.
}

Fantastic, our player is now moving at 600 units per second, just like we wanted! But wait, there's more! Let's say we encounter some lag and our game drops down to 40 FPS. Now our code will move us 10 * 40 = 400 units per second! Yikes, not good!

But what if we instead took actual time elapsed into account and used this to calculate our speed instead? The code would change to something like this:

public void render(float delta) {
    position += 600 * delta; // 600 units per >second<.
}

Now, since speed is calculated in "per second" instead of "per update" we will always move at a constant speed no matter the framerate! Hurrah!

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.