Re: [boost] [tweener] Preliminary Submission

Subject: Re: [boost] [tweener] Preliminary Submission
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2013-03-02 15:00:47

On Sat, Mar 2, 2013 at 7:54 PM, Michael Marcin <mike.marcin_at_[hidden]>wrote:

>
>
>>  Why are all the callbacks boost::functions? It's already a template can't
>>> I just use my own callback type without paying for the type erasure and
>>> dispatch of a boost::function if I don't need it?
>>>
>>>
>>>  I think the functions should be template but inside they still have to
>> use
>> boost::function for storing the callback.
>>
>>
> I don't think that's necessarily true. You can just store a copy of the
> callback in the tweener so long as the type of the tweener depends on the
> type of the callback. Although I could be convinced it might just be easier
> and cleaner to pay the overhead for the type erasure here.
>
>
So basically the question is: is it frequent to store tweeners with
different callback types in the same container?
Not sure about this.

>
>
>
>>  init/end seems like a strange name pairing. Maybe from/to, begin/end,
>>> initial/final? Although using end here at all seems a bit dubious as it
>>> is
>>> so often used in the as a semi-open interval [begin,end) whereas here it
>>> is
>>> a closed interval [init,end].
>>>
>>>
>>>  I quite agree, I'm just not sure begin/end wouldnt be misleading. I
>> tend to
>> prefer "target" as the end value name, as it should be modifiable (moving
>> target).
>>
>>
> I'm not sure how mutable target works. If t=0.5 with a linear tween from
> from 0 to 10 (so current position is 5), what happens when I change the
> target to 20?
>
> Does my t stay at 0.5 and my position change to 10?
> Does my position stay at 5 and my t change to 0.25?
> Does something else happen?
>
>
In my experience, and old implementation I used in previous projects, both
the intial state and target state would be modifiable at any time, either
by calling
the update callback, or by modifying one of these states. It's the callback
that, in the end, define the behaviour but basically, it's exactly like
modifying bezier curves points:
if you change either the initial or target state, the current state is
recomputed given these new data and the current position (from 0 to 1).

In your example, the current state would be changed to 10.
If the user wants a variant of this, he can change the initial state too,
maybe setting it to the current state before changing the target state.

I did this a lot and it was intuitive, but I don't know if it would be
intuitive to others.

Anyway good remarks.

Joel Lamotte