Time Based Animation - the best practice?

Getting Started Newbie Questions
#1

Hi,

after looking at the animation tutorials i understand that there are 2 possible ways of animation: time and frame based. So if i want to have my app running at constant speed with sound and everything synchronized and not dependent on the frame rate i have to use time based.
After looking at the different animation functions i realized that they are all time based anyway. (You can set an amount of time to complete the animation like with transition.to.)

But what’s with scale function? Is the best practice here to just calculate how much time a frame needs and then calculate how much frames 1000ms are and then use this factor for scaling on every frame? Are there better solutions?

Second, if i use time based animation and every (animated) object on the screen has an event listener and a enterFrame callback function it looks to me like quite a task to make all of these functions time based and they would measure all the time measured by the others as well. Is this the correct way to do it? Another approach which came to my mind is to just use a gigantic Runtime enterFrame function and do all the drawings and animations there, with only one time synchronisation for everything. I could split the various asset dependent animations into classes which would make it a bit more modular. Soooooooo… what’s your best practice on this?

Cheers!
aleeri

[import]uid: 11772 topic_id: 3994 reply_id: 303994[/import]

#2

okay okay, I just found out that all the tweens (scale, rotation, translation, …) can be done with the transition.to / transition.from function but it isn’t really documented which parameters it accepts, on a quick look one might think that it’s only usable for translations. :slight_smile:

so if anybody runs into the same problem: You can pass almost everything to the transition function:

transition.to( object, { time=1500, xScale=2, yScale=2, rotation=180, alpha=0, x=50, y=50, transition=easing.inExpo, onComplete=yourCallbackFunctionNameGoesHere } )
No thoughts on the second issue with the architecture anyone? Is it too far off? [import]uid: 11772 topic_id: 3994 reply_id: 12447[/import]

#3

It seems like you’re already on the right track. You can get by using multiple runtimes, but you’d have to make sure you game design supports those kinds of independent workings.

Corona’s animation is time-based already and all the transitions work on their own without you needing to both calculate the movement and draw the updates.

The runtime itself is capped to the config framerate, so I guess that would make calculations and logic frame-based, which is why when making manual transformations in there, you would need to account for proportions in time. Using multiple might be a better idea since you’d get more updates than it’s limited to and you’d be able to work on different aspects of the game separately. [import]uid: 11024 topic_id: 3994 reply_id: 12471[/import]

#4

Thanks for the reply, I think I might understand now.
Since all the animations (in my case) can be done with the transition function, I might not need to implement a enterFrame function at all. Just the various event listeners that trigger of the appropriate animation (which I can pack into nice little modules:)) since it’s a very state-based game. [import]uid: 11772 topic_id: 3994 reply_id: 12550[/import]