Why does he decide to use 1.0/12.0 for the update time he explains his logic on most of the other choices but I couldn’t think of a reason why for this? If someone knows can you please explain it to me.
Hi,
I’ve divided 1.0 by 12.0 and got 0.83333333333333.
made me a bit curious about what dT and updateTime looked like, so I added this code to the while loop:
//time since last frame
const float dT = GetFrameTime();
cout << "dT = " << dT << endl;
cout << "updateTime = " << updateTime << endl;
I got this for an output:
dT = 0.0162961
updateTime = 0.0833333
dT = 0.0165819
updateTime = 0.0833333
dT = 0.0168052
updateTime = 0.0833333
dT = 0.0164243
updateTime = 0.0833333
dT = 0.0163474
updateTime = 0.0833333
dT = 0.0163189
updateTime = 0.0833333
dT = 0.0163913
updateTime = 0.0833333
dT = 0.0162123
updateTime = 0.0833333
dT = 0.0173734
updateTime = 0.0833333
dT = 0.0169923
none of this said much to me so I decided to check runningTime and framebefore both were reset:
-edit- found this in the docs, which makes sense of dT to me now:
`float GetFrameTime(void); // Get time in seconds for last frame drawn (delta time)`
if(runningTime >= updateTime)
{
cout << "runningTime = " << runningTime << endl;
runningTime = 0.0;
cout << "frame = " << frame << endl;
frame++;
}
And got this (for some reason I’ve commented the code for update time and dT, even deleting the compiled .exe and still get the output in terminal, so sorry about the mess):
dT = 0.0171683
updateTime = 0.0833333
runningTime = 0.0848784
frame = 0
dT = 0.0159778
updateTime = 0.0833333
dT = 0.0171149
updateTime = 0.0833333
dT = 0.0162722
updateTime = 0.0833333
dT = 0.0168463
updateTime = 0.0833333
dT = 0.0164847
updateTime = 0.0833333
dT = 0.016324
updateTime = 0.0833333
runningTime = 0.0990199
frame = 1
dT = 0.0164829
updateTime = 0.0833333
dT = 0.0165136
updateTime = 0.0833333
dT = 0.0172264
updateTime = 0.0833333
dT = 0.0164165
updateTime = 0.0833333
dT = 0.0164343
updateTime = 0.0833333
dT = 0.0163605
updateTime = 0.0833333
runningTime = 0.0994342
frame = 2
dT = 0.0168833
updateTime = 0.0833333
dT = 0.0160529
updateTime = 0.0833333
dT = 0.0169637
updateTime = 0.0833333
dT = 0.0170222
updateTime = 0.0833333
dT = 0.0168689
updateTime = 0.0833333
runningTime = 0.083791
frame = 3
dT = 0.0165973
updateTime = 0.0833333
dT = 0.0164105
updateTime = 0.0833333
dT = 0.0164
updateTime = 0.0833333
dT = 0.0166775
updateTime = 0.0833333
dT = 0.0160128
updateTime = 0.0833333
dT = 0.0170305
updateTime = 0.0833333
runningTime = 0.0991286
frame = 4
dT = 0.0175419
updateTime = 0.0833333
dT = 0.0163184
updateTime = 0.0833333
dT = 0.0165048
updateTime = 0.0833333
dT = 0.0170927
updateTime = 0.0833333
dT = 0.0170399
updateTime = 0.0833333
runningTime = 0.0844977
frame = 5
dT = 0.0162795
updateTime = 0.0833333
dT = 0.0172897
updateTime = 0.0833333
dT = 0.0163938
updateTime = 0.0833333
dT = 0.0164487
updateTime = 0.0833333
dT = 0.0165154
updateTime = 0.0833333
dT = 0.0173111
updateTime = 0.0833333
runningTime = 0.100238
so it looks like dT is added to runningTime's value about 7 or 8 times (but it’s supposed to be 12, so my math is probably wrong) until the next frame is called, when the updateTime is reached.
1 Like
Thanks for the detailed response I kinda get it because update time is constant the .0833333 and we just want to reset frames if running time is higher than it and we use deltatime to judge it. I should have thought of printing out the functions but thank you.
1 Like
UpdateTime is the frame-rate of the animation. Or in other words, the speed at which we flip through each frame in the spritesheet. RunninTime is updated through DeltaTime (dT) so we know how much time has elapsed and check to see if we need to advance a frame in the animation.
The calculation of 1.0/12.0 can be expressed as X frames per second, so we are setting the frame rate of the animation at 12 frames per second.
2 Likes
It’s a bit of an add-on to this but, this is the frames per second of the animation. Persistence of Vision is also 12 frames per second, meaning that you need at least 12 images per second to trick the eye into thinking there is movement. If you have a sprite sheet that has more images then you can go to a higher frame rate and get smoother animations, but 12 is the minimum, below that and things get choppy.
1 Like
Hi,
I did some of the frame counting before the new image is displayed. And I got this:
// update running time
runningTime += dT;
countFrames += 1;
if (runningTime >= updateTime)
{
runningTime = 0.0f;
std::cout << countFrames << std::endl;
countFrames = 0;
// update animation frame
scarfyRec.x = frame * scarfyRec.width;
frame++;
if (frame > 5)
{
frame = 0;
}
}
And output:
5
6
5
6
5
6 …
I get 5 to 6 frames before the image is changed to frame with new image. So is this actually 6 frames per 1.0f/12.0f of a second? So if I multiply 6 * 12, this is actually 72 frames per second?
But if I multiply 5 * 12, its 60 frames per second as we set it in SetTargetFPS(60);
So its something between 72 and 60 frames per second.
So its not 12 frames per second, it is still 60 frames per second or a bit more?
Think of it this way, each sprite in the spritesheet is a “frame” and if we’re moving between each frame at 1/12th of a second then it would be at a rate of 12 frames per second.
Even if the game itself is generating 60 frames per second.