Transition woes

Games
#1

I’m trying to build a “multiple transition” routine, using the transition library, for a smooth effect of acceleration. But something isn’t adding up.

The following code as follows:

transition.to( object, { time=4000, x=object.x-128, transition=easing.inQuad } )  
transition.to( object, { time=8000, delay=4000, x=object.x-256 } )

What this basically does is start an “accelerate” transition for 4 seconds. Thus, the “inQuad” easing. After that (note the delay on the second transition), a “normal” movement occurs for 8 seconds.

I’m using the common speed formula, which is: SPEED = DISTANCE / TIME

Using this equation, I determine the speed that the object should be moving at the end of the first transition. Then, using that speed, I reverse-calculate the time it should take for the second transition to reach its point. This should, in theory, produce an acceleration for 4 seconds, followed by 8 seconds of a steady movement at the same speed the object was moving after the first transition.

But there is definitely something wrong. The transition is not smooth. The “inQuad” easing does not reach the correct value by the end. It’s too fast at the ending time. And thus, when the second transition begins, there is a noticeable skip and slow-down. Does anybody know why the “inQuad” easing is not reaching the proper end value? I know this is a fairly technical question, perhaps best answered by Ansca, but I’d like to know why this is occuring so I can properly calculate a second transition for perfectly smooth motion.

Any ideas?

[import]uid: 9747 topic_id: 4180 reply_id: 304180[/import]

#2

when you call that second function, you know its going to be the current value of x-256 not the value at the end of the your first transition? ie it’ll end up at your current x-256, not x-384
[import]uid: 6645 topic_id: 4180 reply_id: 12994[/import]

#3

Feeling kinda silly here… I think I solved it jmp909, thanks to your pointer. I was assuming that when the second transition triggered, it would recalculate the speed based on that distance (256). Instead, it appears that the engine pre-calculates the second transition over the combined distance (384). So, instead of moving 384 pixels over 8 seconds, it’s effectively moving 256 pixels over 8 seconds, thus the noticeable slow-down. Once I factor out the initial “acceleration” distance (128) from the 2nd transition distance, the movement appears to be smooth, exactly what I need!

I appreciate it,
Brent
[import]uid: 9747 topic_id: 4180 reply_id: 13011[/import]