Ill try one more time but im not sure really how to explain it different than that.
What it is saying in a summery i that u get the value of time_step by doing 16 divided by your fps. If you have an fps of 20, time_step = .8, if fps is 10 time_step = 1.6. So to put this in an example ill just use time_step for the value instead of doing 2*time_step like they did,
my.pan += time_step; Its adding the value of time_step to our pan.
Lets assume that we are running at a steady rate of 50fps. 16 divided by 50 is .32. So in the first frame of that second our pan is set to .32, the next frame it adds .32 more to our pan, know its .64. It is going to do that 50 times per second. So we can know figure out how many degrees our my entity is going to turn each second, by doing that 50 times luckily i got a calculator and its 16.
here is another example that doesn't just use time_step,
assume we are running at 50 fps again we will set our pan to
my.pan += 2*time_step;
In the last example we just used time_step for our value but know we must times that by 2, so instead of pan being equal too .32 on the first frame of the second we must multiply that by 2 so it is .64. Know the pan equals .64. Do the equation again, on the second frame of that second (our pan)is equal to .64 += 2*.32, to shorten the equation we can just do .64 += .64, know the pan is 1.28. Keep going with that and you will get 32 after 50 frames. Know since i used the same example with a different frame rate go to the tut and look at his example, he used a fps of 200 and i used a fps of 50 both were my.pan += 2 * time_step; and we both got 32 degrees a second. Then he just shows you that you can divide 360 a full rotation by 32 to see how long it will take you to turn all the way around.
Sorry if you still don't get it did my best.lol
Thank you for your persistence. It is appreciated. For a bit there, I thought I was starting to get it... then you got into explaining all the math, and it lost me again xD
I think it's because there seems to be 4 things at play.. the FPS, the time_step, the degrees per step and the "per tick" thing.
See, when I'm doing something in a 3D app, and I want an object to complete a rotation in 3 seconds at, say 30fps, I would do the following:
1. Calculate the FPS * the number of seconds (3), which would give me 90 frames.
2. Divide 360 by 90 to get the amount of degrees the object must rotate each frame, in this case it's 4 degrees per frame.
3. Then, to make sure the cube rotates smoothly and doesn't "pause" at frame 1 because the first and last frames of the animation are overlapping, I want to end the animation 1 frame increment earlier than the full 360 degrees.
4. So I would subtract 4 from 360 degrees and get 356 degrees; and I'd subtract one frame from 90 and get 89.
So in 89 frames, the object must rotate 356 degrees in 4 degree increments.
Ideally, if all is done right (that's off the top of my head), when looped it will simulate a smoothly rotating object.
That's how I would look at it and it makes sense because there's only 2 things I'm really concerned about.. the total number of frames and how many seconds I want it to complete the rotation in. From there, the math is easy.
But this whole time_step, FPS, per-tick and rotation thing is really messing me up lol. I realize you can't "hard code" a FPS on every computer (thus the entire point of the workshop), but that's clearly the bit that's throwing me off.
I do appreciate the effort to explain it.
I think it's just going to have to "click".
