Bézier curves

[Nexus]

As for working with **sf::Vector2** only, this won't work, it's lacking operators taking simple numbers (you'd have to remove all multiplications).

It doesn't lack the operators, you just have to use the correct types.

The literal 3 is not a float, take 3.f instead. Something you should do anyway when you work with specific types, don't rely on implicit conversions

And concerning STL containers, std::vector is usually the default choice because it's the most efficient in many situations. Only in special cases, it can be outperformed by std::list. Also, it provides random access.

[MorleyDev]

Just personal preference. Use whatever you want to implement it (should be easy to replace/update) and what you think fits your specific use case.

Unfortunately it's incorrect. The way to view according to  Bjarne Stroustrup himself is that vector is the default list storage, whilst list is an optimisation and should not be used prematurely.

Source: The Bjarne C++11 Keynote

[Mario]

The literal 3 is not a float, take 3.f instead. Something you should do anyway when you work with specific types, don't rely on implicit conversions

You're right, didn't scroll below addition/subtraction (silly me ).

Updated the wiki, so it uses the Vector2 operators as well as vectors rather than lists.

[Jove]

I only skim-read the post so forgive me if this is off the mark, but the Claw Library features support Bézier curves.

http://libclaw.sourceforge.net/index.html

Good library, I use it principally for the Tweener.

[Mario]

Perfectly fine to mention it, really depends on whether people want to include another dependency or not.

Edit: Just saw it's using Boost. Nothing wrong in that, but IMO it's a horrible dependency, that can turn compiling a small program into compiling a whole afternoon, if you don't have precompiled binaries.

Although I really like that tweening library. Think I'll adapt it for my own projects.

[Halsys]

Nice Mario! The code is extremely usable and oddly enough I was too using a AS3 Example. I will try making a class for it and then add few modifications to give it more functionality. Because yours is more kind to what I wanted. Here is basically what I'm aiming for...
~Can draw sprites in place of points and you may have random rotation for it if you want.(You give the sprite)
~Can draw dots or boxes on the calculation points.(You give the shape)
~Color and opacity morphing from starting point to end point.(With different modes)
~Updates the curve geometry only when a value was modified.
~base rotation and offset.(So you can move and rotate it without doing another calculation)

Any suggestions?

[Klaim]

Just a shameless plug to this thread: http://en.sfml-dev.org/forums/index.php?topic=8010.0

Because the more I try to use SFML the more I really think that today a multi-media basic components library without anything for tweening is problematic. (or at least it makes development slower than it could make - and that's only one feature missing in my opinion)

So if Bezier curves implementation manage to convince Laurent that it's worth putting it in the core (and now I am sure it is, but that's my opinion), then tweening should be the next feature. It's simple, there are tons of code already existing in other frameworks that shows how to do it. So basically the problem would mainly be to convince Laurent and having a surprisingly simple, efficient and elegant interface.

Also, as libclaw has been mentioned, see the comment on lilbclaw author working on Boost.Tweener which is a generalization of libclaw.


@Laurent I'm not sure I agree with the float type only argument, in particular when both bezier curves are often used in non-graphic works too (mostly doubles for example in wide space simulations involving multi-scale positionning, or even non-plannar geometry prediction stuffs). But I guess float only would be a good start.

[Mario]

I already have a simple tweening class, but I'm still not 100% happy with it, plus I want more complex tweening (like VertexArrays or Colors) before releasing or suggesting anything.

It can essentially be used for creating bezier curves as well, so not that much off-topic, but it's only time dependent so far.

Usage would be something like this:

sfx::Tweener<float> x(0, 10, sf::seconds(5), sfx::TweenRepeat | sfx::TweenSine);

x can then be used just like any float variable, but it will change its values "on its own" (when retrieved; from 0 to 10 using a sine curve). Same can be done with pretty much any data type like sf::Vector2f and others.

[eXpl0it3r]

The goal of SFML's graphics module is to provide a very simple API to get some 2D graphics going. The fact that we have classes such as sf::Sprite and essentially sf::Transformable and sf::Drawable, is only for convenience, because all we essentially would need now to draw 2D stuff is some kind of render target, a transformation and vertices. How much convenience will get added to SFML is up for discussion, but the only person that can make a final decision is Laurent.

Personally I see the benefits of a Tweening class, but I don't think, that it would fit into SFML's "philosophy", because if we would add it, why not add feature x or feature y or feature z? And which point will SFML be blown up so much, that you essentially have to drop the Simple from it's name?

[FRex]

And which point will SFML be blown up so much, that you essentially have to drop the Simple from it's name?

The acronym will still hold!

[Laurent]

Super Fat Multimedia Library

I'm currently busy with other very important tasks (bug fixing, iOS port, more important features, ...) for a while, so if I ever consider adding such features, it won't happen before a few months.

So feel free to continue the discussion (that will help me decide), but don't expect immediate feedback from me.

[Klaim]

The goal of SFML's graphics module is to provide a very simple API to get some 2D graphics going. The fact that we have classes such as sf::Sprite and essentially sf::Transformable and sf::Drawable, is only for convenience, because all we essentially would need now to draw 2D stuff is some kind of render target, a transformation and vertices. How much convenience will get added to SFML is up for discussion, but the only person that can make a final decision is Laurent.

Tweening is not supposed to be a graphic part, it's value-animation. I wouldn't add tweening to SFML graphics library, that would be dumb. Value-animation is a basic brick which is important for tons of different kind of stuffs, the most visible being moving graphics.

Personally I see the benefits of a Tweening class, but I don't think, that it would fit into SFML's "philosophy", because if we would add it, why not add feature x or feature y or feature z? And which point will SFML be blown up so much, that you essentially have to drop the Simple from it's name?

You can dump this argument at each request too, it's not a valid argument. What would be an argument against adding value-animation in a separate library which is part of SFML because it uses it's basic types?

[eXpl0it3r]

You can dump this argument at each request too, it's not a valid argument. What would be an argument against adding value-animation in a separate library which is part of SFML because it uses it's basic types?

It's my personal opinion and yes it will work for mostly all feature request, which only shows, that I personally think, SFML's current state is enough and doesn't need any more core features.

[Klaim]

Ok but that's not an argument either. I personally think it would be too much to add another feature than value animation tools, so it's just one feature more I think is really missing. I also think that it's surprising that there are threading features to SFML if I follow the logic of not adding anything other than basic building blocks of multi media library (and threading is anything but "simple").

My argument is: for a multimedia library, it quite lack features helping implementing dynamic changes of the basic bricks it provides. A generic value animation feature would be, in my opinion, a generic tool to quickly plug together all these bricks to make something that change, like moving a sprite through a curve or changing dynamically the music volume, even sprite animation can be implemented using it - all that without defining in SFML how to do these, just providing the tool to animate values (for examples floats or better: aggregates).

EDIT> Just to complete my thinking: I believe it would be a minor addition technically, a set of simple tools, but it would help a lot combine other features with anything that "moves" or is animated.

[Nexus]

I also think that it's surprising that there are threading features to SFML if I follow the logic of not adding anything other than basic building blocks of multi media library (and threading is anything but "simple").

This has already been discussed multiple times, and threads are only provided because they are needed in the SFML implementation. That's also the reason why requests for more elaborated multithreading features are constantly rejected.

When SFML ports its code to C++11 one day, sf::Thread will probably be removed.