preventing out of bounds values in penner easing

Question

I'm working on a project that uses the following easing function to move objects on the screen:

function easeinoutquart(t,b,c,d) as float
    't=time, b=startvalue, c=change in value, d=duration
    d=d/2
    t=t/d
    if (t < 1) then 
        return c/2*t*t*t*t + b
    end if
    t=t-2
    return -c/2 * (t*t*t*t - 2) + b
end function

I keep running into situations where the values go rapidly out of bounds resulting in objects moving offscreen at dizzying speeds. The first situation seemed to be caused by truncating the results of the function to integer values, which I fixed. The next thing that triggered the exact same behavior seemed to be when the time value was not reset after the objects came to rest and a new easing distance was entered. Once I added a reset after changing the destination value (change=destination-start) this seemed to fix the problem completely.

Now I've added more code to the loop that downloads and swaps out images. It appears that the added execution time in the loop sometimes causes the values to go out of bounds, creating the same blur of images rushing off screen.

To describe the code briefly:

loop
   check for user input (up down left right select) 
      if so set new dest position for all images, reset timer for all images
      if a new image is selected on screen, load related content, reset related content timer

      is there an image in the queue to download? if so get initiate async download
      are any images downloaded? If so swap out temp image with final image

      call easing function for primary images (vertical movement on y axis)
      call easing function for related content (horizontal movement on x axis)
      draw all graphics and swap display buffer
end loop

Prior to adding the image download/swap (the actual swap is just changing a pointer) code, everything was working great with both preloaded images and temp images. Now that I'm loading temp images first and swapping, I think that the loop is somtimes executing in more than 1/30th of a second and perhaps this is causing timer values to get weird.

So essentially, I'm wondering if there are some kind of "governer" clamps I can put on values that will keep the easing function from generating crazy values that rapidly get out of control. For example, the total distance moved should never more than 250 pixels in a single iteration, in fact should always be just a few pixels towards the destination value.

Answer 1

While i'm certain I did not ask this question well, I have finally found the answer. The issue I was encountering was caused by the value of time being greater than the value of duration.

In the above function, you don't feed in the destination value, just the current value and the difference between the start and destination. The solution I came up with is: if execution time between calls to the easing function go beyond the maximum allowable duration value allowed for the easing to complete, then just set the start value to be equal to destination value.

time is the number of milliseconds since the easing function was initiated:

change=destination-currentposition
currentposition=inoutquart(time,currentposition,change,duration)
if time > duration then startarray[i]=destarray[i]

So this way, we clamp the output value to the destination position if time exceeds duration.