Thor C++ Library – An SFML extension

[Nexus]

Does the the latest Thor version work with the latest Git snapshot yet?

Yes.

[Orwel]

Finnaly, i will stop to postpone to update THOR  

[BlueMagic]

Just a small question: How good is the development version of the particle system? Is it still under heavy, constant changes?

BTW, I started using the particle system but I can't seem to find a way to emit particles with an angle offset. I thought SetEmissionAngle() would be the answer, but it doesn't do what I'm saying. Is there any way to do it?

[Nexus]

Just a small question: How good is the development version of the particle system? Is it still under heavy, constant changes?

When the SFML API is broken as a result of the new naming convention, I will exploit the opportunity to modify some things. This concerns especially the smart pointer ownership, I am probably not going to use thor::ResourcePtr in the future. Details are explained in my recent post. I have also thought about making thor::Emitter more abstract (at the moment, many properties are already predefined, decreasing flexibility for own derivates).

What do you think about this, are you annoyed of ResourcePtr? Should I use shared_ptr instead, or something completely different to hold the textures?

And are there other suggestions about the Particles API? Now is a good moment to announce them

BTW, I started using the particle system but I can't seem to find a way to emit particles with an angle offset. I thought SetEmissionAngle() would be the answer, but it doesn't do what I'm saying. Is there any way to do it?

The emission angle determines how "spread" particles are emitted, i.e. if they're just thrown towards a line (0°), in a half circle (180°), etc.

To influence the direction, use thor::DirectionalEmitter::SetVelocity(). This function expects a vector, you can construct one with a specific angle using thor::PolarVector2f, for example:

Code: [Select]

thor::PolarVector2f direction(10.f, 90.f);
// length 10, angle 90°
// i.e. the same as cartesian sf::Vector2f(0.f, 10.f)

thor::DirectionalEmitter::Ptr emitter = ...
emitter->SetVelocity(direction);
And finally, there's also the option to create a custom emitter class by deriving from thor::Emitter.

[BlueMagic]

Just a small question: How good is the development version of the particle system? Is it still under heavy, constant changes?

When the SFML API is broken as a result of the new naming convention, I will exploit the opportunity to modify some things. This concerns especially the smart pointer ownership, I am probably not going to use thor::ResourcePtr in the future. Details are explained in my recent post. I have also thought about making thor::Emitter more abstract (at the moment, many properties are already predefined, decreasing flexibility for own derivates).

What do you think about this, are you annoyed of ResourcePtr? Should I use shared_ptr instead, or something completely different to hold the textures?
And are there other suggestions about the Particles API? Now is a good moment to announce them
 

As for ResourcePtr, I barely got to use it when trying out the Particle System and all I can say is that it did the trick well. The concept of shared_ptr is also very functional so I guess that would work well too. They're all good since they are improvements from simple pointers anyway. I think it makes sense that you work with ResourcePtr since it's part of your framework. As for suggestions for the API, I've got none (except that I've been meaning to ask how optimal is the way that the particles are rendered, especially when compared to something like vertexarray which I believe would work quite well if I'm not mistaken).

BTW, I started using the particle system but I can't seem to find a way to emit particles with an angle offset. I thought SetEmissionAngle() would be the answer, but it doesn't do what I'm saying. Is there any way to do it?

The emission angle determines how "spread" particles are emitted, i.e. if they're just thrown towards a line (0°), in a half circle (180°), etc.

To influence the direction, use thor::DirectionalEmitter::SetVelocity(). This function expects a vector, you can construct one with a specific angle using thor::PolarVector2f, for example:

Code: [Select]

thor::PolarVector2f direction(10.f, 90.f);
// length 10, angle 90°
// i.e. the same as cartesian sf::Vector2f(0.f, 10.f)

thor::DirectionalEmitter::Ptr emitter = ...
emitter->SetVelocity(direction);
And finally, there's also the option to create a custom emitter class by deriving from thor::Emitter.

I think I may have expressed myself badly. I meant that I wanted the texture to appear with an angle offset, as in rotated X degrees (rotation relative to the center of the texture or so), in a way that I can set a random angle so not all the textures appear exactly alike at first. Kind of like the torque modifier but when they are created. I believe the API doesn't give me that option.

[Nexus]

thor::ResourcePtr is currently just a thin wrapper around std::tr1::shared_ptr, so I could directly use the latter (I kept ResourcePtr to allow more functionality, but I currently don't exploit it). And I have already planned to check how well a sf::VertexArray version would perform compared to the direct OpenGL approach, but I guess some options like SetGlowing() won't be available anymore.

The initial rotation of particles is the same as the emission zone's rotation, so you can modifiy it with

Code: [Select]

emitter->GetEmissionZone().SetRotation(rotation);
However, this does also rotate the shape of the zone (which is not relevant for points or circles, but for other shapes). Maybe I should also allow a rotation relative to the zone, same for position and maybe also scale.

The design dates back to a time before sf::Transform and sf::Transformable, I believe reflecting over it in consideration of the new SFML API might make things simpler and more intuitive.

[BlueMagic]

Isn't rotating the shape of the zone kinda slow?

[Nexus]

No, the rotation is just a transform, the actual zone points are not changed.

But the zone orientation and the particle's texture rotation are two different things, I should separate them anyway. Hopefully, I can embed sf::Transform/sf::Transformable in a nice way...

[dydya-stepa]

is it possible to catch events like Shift+P or Alt+F4 with thor event system?
If yes, can you provide a sample how that would look like.

[Ockonal]

is it possible to catch events like Shift+P or Alt+F4 with thor event system?
If yes, can you provide a sample how that would look like.

Shift + P? Why not. But not Alt+F4, this is system binding.

[Nexus]

Shift + P:

Code: [Select]

thor::Action shift = thor::Action(sf::Keyboard::LShift) || thor::Action(sf::Keyboard::RShift);
thor::Action p = thor::Action(sf::Keyboard::P, thor::Action::PressOnce);

thor::ActionMap<std::string> map;
map["shift+p"] = shift && p;
With Alt + F4, you can also try that, but I think SFML also fires a Closed event. So you should rather catch this one.

[StormWingDelta]

I thought it would be easier to download the current version than it is.  Why didn't you just zip file the things needed for it? Just wondering since all I see are text files and it is going to take forever to do this one at a time or did I click the wrong link to get to the current version.?

[dydya-stepa]

cool, what about double mouse click ?

[Nexus]

I thought it would be easier to download the current version than it is.  Why didn't you just zip file the things needed for it?

The current version is a SVN revision. I would have to zip it everytime I make a commit. But I'm planning to release a new version soon, one that's still compatible with the current SFML API.

But you're probably making it more complicated than necessary, have you tried an SVN client (such as TortoiseSVN on Windows, or also direct commandline svn)?

cool, what about double mouse click ?

You can have a callback that measures time since the mouse was clicked last time. If this time is shorter than a specific threshold, recognize it as double click.

Code: [Select]

struct Callback
{
    void operator() (thor::ActionContext<std::string> c)
    {
        if (*c.Event == sf::Event::MouseButtonPressed)
            return;

        if (clock.Restart() < sf::Seconds(0.5))
            DoubleClick(c);
    }

    sf::Clock clock;
}

[Hubert]

Hello Nexus,

First of all, thank you for that very useful library.

I have a question that I hope you will be able to answer.
It is possible to not throw an exception during the load of a resource if its extention is not supported ?
Let me give you an example. I have a resource loader which try to load all ressources contained in specific folders without any regard concerning the extension.
With the way supplied by the SFML to load an Texture for instance, the non-loadable ressource is just ignore and we get a NULL pointer.
I would like to have the same behavior because currently my application is closed as soon as a non-loadable is found.

(I guess I can specify to load only file whose the extension is contained in an enum for instance, but it would be more interesting if it can be possible with Thor directly).

Another request.
Is that possible you give an minimal code to implement custom ressource to be integrated by Thor ressource manager ?

Finally, I would like to have your opinion about the singleton in the management of resources. Currently I use this pattern that I don't love so much, but I would like to know if you've got another approach.

Thank you for your attention and excuse my english. I don't speak as well as I would like.