Computer Science Canada Delay-Free Animation |
Author: | Insectoid [ Wed Jun 12, 2013 10:57 pm ] | ||||||||
Post subject: | Delay-Free Animation | ||||||||
Most of the projects that get posted here have at least one delay in them to attempt to regulate the game speed. This may work on your computer but as soon as you try to share it, your timing will be completely messed up due to the different clock speeds. This can be mitigated somewhat with Time.DelaySinceLast, but why not let your computer do something in that spare time instead of waiting? Why design your program around a static framerate when you could just let it run as fast as possible? Instead of waiting to draw the next frame, why not just draw more frames? This is relatively easy to do, though it does take a little extra work. Most students will assign their objects a static speed- maybe 10 pixels per frame. We're going to do the same, except we'll measure our speed in pixels per second. In our game loop, we will calculate how much time has passed since our last frame and then decide how far our object should have moved in that time. Let's start with a couple variables:
I'm sure you recognize X and Y, although usually they're integers. In this example, we'll be using reals because our objects can actually move less than a pixel per frame. Our speed in pixels per second is one hundred. It should take us about 4 seconds to move from the bottom of the standard output window to the top, regardless of how fast your computer is. Now we need a way to decide how much time has elapsed between frames. Turing has a Time.Elapsed function that shows how long the program has been running. If we record the Time.Elapsed in one frame, and then the next frame record it again, we can subtract the first from the second and get the time in between.
Now that we can calculate our time between frames, we can start moving things. In your bog-standard animations, you simply add your speed to your x or y variable: x := x + speed. We do the same thing here, but first we have to multiply the speed by the number of seconds since the last frame. Also, since our speed is in pixels per second and our time is in milliseconds, we need to divide it by one thousand. So to move up, our equation would look like 'y := y + speed * time_since_last_frame / 1000.0'.
Now all that's left to do is put it all together. I've added a variable delay so you can see what it would look like on a slower computer. Press 'w' to increase the delay by 10ms and 's' to decrease it. Use the arrow keys to move around. There's a timer at the top so you can see that the time it takes to move across the screen doesn't change, no matter the delay.
|
Author: | Insectoid [ Wed Jun 12, 2013 11:32 pm ] | ||
Post subject: | RE:Delay-Free Animation | ||
You can also apply this to variable-velocity movement models, where the object accelerates instead of moving at a constant speed. In this case, we swap out our speed variable for an acceleration variable measured in pixels per second squared. We also gain X and Y velocity variables measured in pixels per second. This again takes a little more work- we need to account for time elapsed when calculating how much we've accelerated in this frame as well as how far we've moved. In this sample, you can press the spacebar to return the ball to the starting position in case you lose it.
|
Author: | Tony [ Wed Jun 12, 2013 11:44 pm ] |
Post subject: | RE:Delay-Free Animation |
Nice. A caveat is that this assumes constant speed. Things get somewhat more complicated when one wants to animate say... a jump. (edit: that has already been addressed above) The basic idea is still the same -- figure out where along the expected trajectory the objects should be at time t, and draw them there. All the relevant formulas are available from a standard high school physics textbook. One has to be careful though then steps average/round intermediate calculations. This shouldn't be a problem when the entire jump's trajectory can be calculated ahead of time, but if it's done step by step (because maybe there's in-air movement/collision), then one ends up with things like Quake3 where the frame rate affects the height of the jump -- http://www.psycco.de/125fps/UpsetChaps%20Quake3%20Guide%20-%20Why%20Your%20Framerate%20Affects%20Jumping.htm |
Author: | Insectoid [ Wed Jun 12, 2013 11:55 pm ] |
Post subject: | RE:Delay-Free Animation |
I made sure only to round when actually drawing the object. All calculations are done on the raw floats, though there may be floating point errors involved. Actually, I do round it off in deceleration, and this was causing an issue initially at high values of _delay as I mentioned in the comments in the code. I've already fixed that in my own code so the X & Y values are adjusted before setting velocity to 0. |