Re: [boost] Interest in a tweener library

Subject: Re: [boost] Interest in a tweener library
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-07-15 05:29:06

On Sat, Jul 14, 2012 at 9:17 PM, Julien Jorge <julien.jorge_at_[hidden]>wrote:

> Le Fri, 13 Jul 2012 17:29:47 +0200,
> Klaim - Joël Lamotte <mjklaim_at_[hidden]> a écrit :
>
> > 3. My understanding of the tweening concepts isn't complete, but
> > maybe you can light me up: isn't there special maths that need to be
> > supported if you want to "tween" an orientation value? (I mean any
> > object that represent an orientation). Interpolation of
> > orientation/rotation is as useful as other values to me.
>
> When I use the tweeners in my games, I interpolate the position, the
> orientation and rotations independently. In this situation, there is
> no need for special maths.
>

What I meant isn't that they would be done in the same time, but that
interpolation for rotation required different kind of interpolation, in 3D
at least (I don't know if it can be generalized).

> > 4. I see in tweener_group/sequence that the insert function take
> > a const reference to a tweener. This is a bit obscure: does it imply
> > a copy of the tweener or does it mean that I have to keep the
> > lifetime of the tweener during the existence of the group/sequence?
> > If it is a copy (I hope it is) then making the copy in the interface
> > would be both useful and explicit. If not, using smart pointers would
> > be necessary (to me at least).
>
> Indeed, the group and sequence store a copy of the tweener. I did not
> want to expose pointers on the interface, thus the tweener class
> stores a pointer to a base_tweener and duplicates the instance when
> copied. The goal of the const& is to avoid some copies but I do not
> mind to remove it.
>
>
I would have done the same without recent mindshifts due to the new
standard, it was just not clear to me if there was a copy (maybe just
documenting is enough).
I agree using pointers here would have been a bad idea.

For the case of more complex types like 2D and 3D vectors, I think
> they could be used for T but, as a user, that is not the way I would
> use the library. Instead, I guess that I would write a helper function
> that builds a tweener_group containing a single_tweener on each
> dimension of the vector.

I see but I think it is overkill compared to a vectorized aproach, as Rhys
Ulerich suggest, that is more generic and I think easier to use.
I'm just not certain what would be the concept of a vectorized type.

> For the performance, I don't think they should be inlined. First, I
> have no measure to tell that there is a performance bottleneck in the
> use of the ease functions. Then, the functions are passed as an
> argument to the constructor of single_tweener. I don't see how the
> compiler could inline a function used this way.
>

I don't know what you mean exactly, but i'm not a specialist either and I
didn't benchmark anything.
By the way, you suggest that the library would not be header-only? Or you
don't mind if it is asked to be?

Thanks, your answers are helpful.

Id

>