Thor 2.0 released!

[vgambit]

Does Thor 2 work with SFML 2.0.0 or do I have to use the latest version from Git?

[eXpl0it3r]

Since there are only bug-fixes and certainly not API change between SFML 2.0 and the latest Git version, Thor 2.0 does work with SFML 2 itself.
If you're on Windows you could also take a look at my Nightly Builds.

[Nexus]

Thanks for the feedback, it's really appreciated!

It's nice that the functionality of several callback systems is there, it could get useful in a real app, like letting different menus, game modes, etc. have different callback systems but using same action map

That's a good example. Even if the callback systems are not used concurrently, one can switch between them.

A few years back, I used boost::program_options and I liked the way you can set it up [...] Maybe something similar could be done (for the connect part) ?

Interesting idea, but I'm not sure if the flexibility the operator() provides is needed for callback registrations -- these are all (key, function) pairs. I had such an API for the old color gradients, where you could specify an arbitrary amount of colors, but now I replaced it with something more expressive...

[FRex]

Boost API is sometimes quite WTF-inducing, chaining operator () or % for doing something very different than usual meaning of them.

[Sonkun]

That's not a big deal but I noticed an unnecessary line in the StopWatch implementation. Line 74, it should work without the clock restart.

mClock.restart();

[Nexus]

Indeed, thank you!

[Nexus]

I added the function thor::projectedVector() which returns the projection of a vector onto an other.

Additionally I wrote an example for the Vectors module, which shows some of the vector algebra functions in action: length(), signedAngle(), unitVector(), perpendicularVector(), rotatedVector() and projectedVector(). The class thor::Arrow is used to visualize the vectors.

[Silvah]

I found a while to rewrite it to make use of makepkg git support, so the AUR package is maintained again.

[Nexus]

Okay, good to know! Thanks!

[FRex]

I just noticed that stop watch reset and restart don't return elapsed time like clock does. Is that on purpose or oversight from time when clock didn't return time on restart too?

[Nexus]

It's not only restart() and reset(); the member functions start() and stop() would have to return the elapsed time for consistency, too. In contrast to sf::Clock, the classes thor::StopWatch, thor::Timer and thor::CallbackTimer have many attributes (not just the time), so it is not immediately clear what the return type represents. Especially for timers, it may not be obvious that the returned value would be the remaining and not the elapsed time. That's why I prefer the explicit getters -- in most classes, modifiers and getters are separated anyway.

This might change in the future, but by keeping void for the moment, I'm not going to break any code, in case I should once find a more appropriate return type than the elapsed time.

[Kojay]

Is it necessary that thor::ParticleSystem be initialized with a sf::Texture, which in turn must have already been loaded? I find it impossible to have a system as member of a class without allocating it on the heap.

[Nexus]

It's not strictly necessary -- I did it for the sake of class invariants.

However, as soon as I allow multiple textures or texture rects in a particle system, it will be possible to specify the texture later. I have planned to implement this feature, in order to allow variations of particles with a clear shape, such as debris.

[Lee R]

I added the function thor::projectedVector() which returns the projection of a vector onto an other

You can get rid of the normalization step using the following definition (where a1 is the projection of a onto b):

template <typename T>
sf::Vector2<T> projectedVector(const sf::Vector2<T>& vector, const sf::Vector2<T>& axis)
{
    assert(axis != sf::Vector2<T>());
    return dotProduct(vector, axis) / squaredLength(axis) * axis;
}

[Nexus]

However, as soon as I allow multiple textures or texture rects in a particle system, it will be possible to specify the texture later.

Done. It is now possible specify different variants of a particle by using multiple texture rects:

thor::ParticleSystem system;
system.setTexture(texture);
system.addTextureRect(rect1);
system.addTextureRect(rect2);

As you see, the texture is specified later. If addTextureRect() is not called, the whole texture will be used. The particle class has a new member variable textureIndex that specifies which texture rect is used:

thor::Particle particle(...);
particle.textureIndex = 1; // use rect2

I also optimized the particle system a bit, such that it's not necessary to completely recompute 4 vertices from the texture rect for every particle every time.

You can get rid of the normalization step using the following definition (where a1 is the projection of a onto b)

Done. Thank you very much for the hint!