Re: Possible limitations with Trident's implementation
- From: Burt Alexander <burt.alexander@gmail.com>
- To: dev@trident.kenai.com
- Subject: Re: Possible limitations with Trident's implementation
- Date: Fri, 17 Jul 2009 18:16:28 +1000
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; b=mNZKU/STbT6D9qRQmoDLjhqMi1yMl3wnuRfAk4DoDWO2IPizZeJxqS2nhMRZymj0Ax K0Q5GmU+cC2b42BwG/C7KiYx9Bqrx0H2fWxfXJvRe8J7uPsXz/kuYiQdtNFOc0ygxvcU PZhihmvE00W7yLLYI7IxIWosa5uR0sF1wtZZ8=
|
Thanks Kirill, for simple animations I can certainly see an advantage.
I do however see two issues with the KeyTimes/KeyValues. The first you
mention - its not terribly pretty to scale & could lead to some
quite unreadable code, but can be mitigated with a helper method or
utility. The second is a limitation of this approach in scenarios. If
one were to have multiple animations running on an object (as I do with
my testbed
class) it is impossible to know, in this example, the exact position of
the floating ball ahead of execution time. The
'addPropertyToInterpolateTo' method of Timeline caters for this,
however KeyTimes/KeyValues are not catered for in this manner and as
such it would not be possible to chain them for smooth transitions
between timelines. With enough mix & match & clever
implementation I'm sure it would be possible to circumvent if required,
but then there's the readability to consider... While I've not fully implemented (or fully tested!) TimelineChain to behave as your full-featured Scenario class, it does give me a consistent API with which to work, and lends itself to quite readable & maintainable code. For instance, this is the code to bounce the ball to a standstill: private TimelineChain getFarPositionTimeline() { TimelineChain chain = new TimelineChain(schwartzBall); double height = schwartzBall.getY(); TimelineEase ease = new Sine(); chain.addTimeline(500, ease); chain.addTransition("y", getPreferredSize().getHeight() - 50); height = height / 0.9; while (height < getPreferredSize().height - 50) { chain.addTimeline(500, ease, RepeatBehavior.REVERSE, 1); chain.addTransition("y", height); height = height / 0.9; } return chain; } Not a physics engine, but it is a reasonable approximation. And the implementation is consistently similar with the code to flash the splash screen and is easily readable. "It indeed can only play the added timelines forward - no skipping, no backward, no looping"...and no explicit repeating of individual timelines (something else that testbed class of mine requires). Certainly, I believe this type of functionality would be very useful in TimelineScenario. As a developer I would wish to use the classes as follows: 1. Create each Timeline with its behaviour defined ahead of execution time, either externally to TimelineScenario or thru helper methods a la TimelineChain. With no restrictions on behaviour! 2. Add them in order I wish to see them executed to a TimelineScenario instance. 3. Play the scenario when appropriate in the code. Number 1 is really the only sticky point; the rest are already there. Nice to haves: 1. Ability to reset the scenario (automatically after playing - state for the scenario prior to execution). 2. Ability to play the scenario in reverse A possible starting point could be making TimelineScenario a TimelineScenarioActor? Anyways, as I mentioned I've got my solution! Hope my perspective has been of assistance. Thanks again. Burton. Kirill Grouchnikov wrote: 861295.11580.qm@web110814.mail.gq1.yahoo.com" type="cite"> |
| Burt Alexander | 07/16/2009 | |
| Kirill Grouchnikov | 07/16/2009 | |
|
Re: Possible limitations with Trident's implementation |
Burt Alexander | 07/17/2009 |





