I'm not sure if it's a basic element, but I think a library manipulating 2d and 3d vectors would make SFML more complete to achieve being the base for any kind of multimedia stuff.

Here is the idea point by point: - have a separate library for this, that would depends only on the positioning types, and the time system; - basic time-based movements; - bezier curve movement; - maybe "paths", made of several movements - maybe some procedural generators to build paths ( around shapes? )

Then, the other interesting kind of movement would be behavioural: steering behaviours.A basic steering behaviours library that works with SFML types would be very very helpful as basic bricks for more complex behaviours.

Two problems with this idea: 1. I'm not sure if it's a good idea to have it in SFML itself, but I believe it is the only thing that SFML miss for me (not even graphic animations). What do you think? 2. Steering behaviours can be hard to get right if you start implementing more advanced algorithms, so I would only implement the most basic ones and maybe have ways to combine them.

I would love to make such a library myself but I am stuck with projects not using SFML at this very moment, so I might participate later in this, even if it's not an SFML library.

Oh by the way I forgot to say something: this would help to quickly build nice graphic applications in current modern OSs that use and abuse from movement ( that is the only thing that makes graphics durably efficient and memorable).

It's not. But it could be a good external add-on; maybe it could even be integrated to Thor

Can you, please, point me to what is Thor?

Quote

This is so true. I recently wrote a small demo application for an expo (using Qt and QML), and everybody wanted to try it because of the nice UI animations.

It would also, in my personal case, fix the recurrent problem I have when I try to do a game-jam with SFML: I have a hard time remembering or reimplementing movement algorithms and they most of the time don't work in an emergeant way. So I loose ton of time on movement code because I prefer moving colored flat shapes than having to do sprite animation.

Quote

By the way, QML animations could be a good inspiration to design such a library.

Yes, this kind of thing, also some cocos2d-x "actions", Open Steer library, the library associated with AI for Games book and some other inspirations - ActionScript tweening libraries too. I guess common basic (movement-related) features can be easily spotted and implemented using only SFML constructs.

I'll not that as a side project to start if nobody could start it yet once I get more free time.

My libs Zoost and Zoom are able to do everything you are talking about.Zoost allows you to use geometrics objects, including Bezier curves, and they can be animated and visualized using the Zoom library (Kinetic class).

Can you elaborate a bit? I mean, time-based movement is used in almost every game, what exactly do you imagine to outsource in a library?

Well examples would be "tweeners" or "easing". In Cocos2d(-x) they have a set of easing classes that might be interesting to look (even if it's really bad C++). There are libraries in ActionScript that provide tweeners.

Here is a good video showing why it is important: http://www.youtube.com/watch?v=Fy0aCDmgnxg

In the past, I have already thought about this kind of functionality, also about splines (or interpolations in general). It is a good candidate for a later version.

I don't know Zoost/Zoom yet, but it looks very interesting. Since it has the features you need, you should probably not wait for Thor to provide it ;)

I know other libraries like that but the problem is that they use their own vector types.It wouldn't be a problem if the code wasn't relying on this type instead of working in a more generic way, assuming only basics about the vector type ( aka a template library ).

An SFML-specific library would be simpler though, that's why I ask here.

That being said, wouldn't the licence allow you to just take the code from zoost/zoom and change it to adapt to SFML types?

Otherwise the "best" way would be to make zoost/zoom a meta library. That would need some work...

I know other libraries like that but the problem is that they use their own vector types.It wouldn't be a problem if the code wasn't relying on this type instead of working in a more generic way, assuming only basics about the vector type ( aka a template library ).

An SFML-specific library would be simpler though, that's why I ask here.

The SFML has good tools, but too basic for a geometric lib such Zoost. Indeed, like its name suggests, SFML graphic module is just designed for graphics when Zoost can be used in order to compute collisions i.e, that requires a better precision than simply graphics.

Quote

That being said, wouldn't the licence allow you to just take the code from zoost/zoom and change it to adapt to SFML types?

Of course you can reuse the code and adapt it to your needs, but according to the licence you just should quote the author of the original lib.

Quote

Otherwise the "best" way would be to make zoost/zoom a meta library. That would need some work...

In a first time, Zoost was a meta lib using templates, but It was too complicated to handle... so I had to simplify it. :(

The other solution would be to add an automatic caster between both vector types, It would be easy to do, but It will add one extra dependency to Zoost (SFML-system).

In a first time, Zoost was a meta lib using templates, but It was too complicated to handle... so I had to simplify it.

I understand fully as I have tried the same several times by the past. Any way, it is simpler to use specific types. Boost have a geometric representation library but I don't know if it is worth using it in a game, I think it's better for graphic design applications.

Anyway, your library seems generally useful, I don't try to say otherwise. I'm focusing on the specific case of projects based on SFML.

Someone is writing a tweener library (extracted from another set of libraries) that is candidate for boost.I will try to help the writer of the library by using the library.

I think that if it's good enough for my project, and it gets released, it could be extracted and imported into SFML. As it is very lean library -it does only interpolation between to values, using a given update function- I think it don't need to be in an extension of SFML and could be a simple way to just tween SFML values and build complex behaviours over it after.With some functions provided to associate tweening to SFML clocks, it would be very lean code.

I believe however that anything more complex, like steering behaviour, should be out of SFML.

Anyway I will report here later (in few months I hope) about this library.

Are you talking about Claw (http://libclaw.sourceforge.net/index.html)?

Although this differs strongly between the Boost libraries, some of them tend to be over-engineered as a result of excessive genericity, which stands in contrast to SFML's philosophy. Apart from that, how would you integrate such functionality to SFML (which module, what API, how is it used, ...)? If it is too specific, Thor might still be an alternative, even if the next library version is still under construction ;)

Yes it is extracted from Claw but I suggested some changes to make it more generic.

Actually it is a simple library to me. It's not like he is making a compile-time compiler implementation (I'm looking at you Boost.Spirit...) so it's mostly a generalization of the same.For example the original Tweener in Claw works exclusively with double. I suggested to change it to any scalar type. That way it even works with Boost.Geometry, so it's easy to make it work for Ogre's Vector classes and SFML too. You just need it to be a scalar type.

You can check the code there but it's WIP: http://libclaw.git.sourceforge.net/git/gitweb.cgi?p=libclaw/boost-tweener;a=summaryThe discussion on Boost : https://groups.google.com/forum/#!topic/boost-developers-archive/eS5PhphX3D0

Just to update: I don't think it's ok to have tweening out of the core library, one of the reasons being that it's actually the simplest procedural animation you can make and it's everywhere in any modern multi media library. There are several examples of such successful and easy to use libraries or frameworks like Cocos2D-X, Cinder or Open Frameworks.

In my experience, they all allow faster feedback on the development just because of having immediately at least basic procedural movement bricks to use. However, these ones are not really c++-idiomatic in the design AND they mostly force you to use a complete framework instead of composing your application with totally separate libraries. That is why I prefer to use SFML.

But really, it's deeply annoying to have to setup non-core libraries just to have basic movements, even if it's just for prototyping. Strangely, that's always hitting me each time I make something with SFML.

I really believe this is the only core missing feature/library.

I also believe it's not like it's an experimental feature or that there isn't enough knowledge about the subject or design of such features. It's basically providing an object to update or a starting point and applying a function on each update, the function being one of the general easing equations or anything else really.

Coming from a cocos2d(-x) background, tweening is the one thing I miss. I thought there would be much more, but working through the SFML book has really improved my C++ and SFML is great! At the same time, being able to say to a multimedia library, "put this sprite here, over the next 5 seconds, move it to here and scale it to this value" seems reasonable.

In the same time, I'm not actually advocating using time as reference because it would imply providing an update loop.

Instead, I'm advocating providing tools to quickly setup your own tweening by calling some system regularly with an update of where between the beginning 0 and the end 1 of the animation (this is the general term for this) the generated/animated values should be.

That way, it would be easier to setup tweening for your specific context of use of SFML (which carefully avoid providing a framework but just provide building blocks).

In the same time, I'm not actually advocating using time as reference because it would imply providing an update loop.

Instead, I'm advocating providing tools to quickly setup your own tweening by calling some system regularly with an update of where between the beginning 0 and the end 1 of the animation (this is the general term for this) the generated/animated values should be.

That way, it would be easier to setup tweening for your specific context of use of SFML (which carefully avoid providing a framework but just provide building blocks).

Agreed, the time/update loop shouldn't be required, it's just an example of what I'd want to be able to do with tweening classes.