Thor C++ Library – An SFML extension

[Nexus]

One last question: Is there a way to integrate mouse movement? Right now the only thing left in my onEvent function deals with MouseMove events. I may have missed something but I don't see a way to create an action that only involves mouse movement

You can do it like this:

Code: [Select]

void OnMouseMove(thor::ActionContext<std::string> context)
{
sf::Event::MouseMoveEvent movement = context.Event->MouseMove;
std::cout << "Mouse moved:  X = " << movement.X << ", Y = " << movement.Y << std::endl;
}

int main()
{
sf::Window window(...);
thor::ActionMap<std::string> map(window.GetInput());
map["mouse"] = thor::Action(sf::Event::MouseMoved);

thor::ActionMap<std::string>::CallbackSystem system;
system.Connect("mouse", &OnMouseMove);

for (;;)
{
map.ClearEvents();

sf::Event event;
while (window.PollEvent(event))
map.PushEvent(event);

map.InvokeCallbacks(system);

window.Display();
}
}
By the way, I think about providing a function that calls ClearEvents(), PushEvent() and InvokeCallbacks()... But that's not too important at the moment.

I really can't thank you enough for the work you've done so far.

You're welcome, thanks a lot for giving feedback and appreciating my work!

[gavintlgold]

Right... now that it's integrated with SFML that works! Excellent.

[Haikarainen]

Thor crashes for me, when trying to draw  a particlesystem.

stacktrace

Code: [Select]

#0 6699D948 sf::RenderTarget::SaveGLStates() (C:\WINDOWS\system32\sfml-graphics-2.dll:??)
#1 70ECCE66 thor::ParticleSystem::PushOpenGLStates() (E:\Work\c++\modernarcade\bin\Release\libthor.dll:??)
#2 70ECD21E thor::ParticleSystem::Draw() (E:\Work\c++\modernarcade\bin\Release\libthor.dll:??)
#3 00000000 0x0040748b in ??() (??:??)
#4 00000000 0x02179e38 in ??() (??:??)
#5 00000000 0x003f72e8 in ??() (??:??)
#6 00000000 0x43e40000 in ??() (??:??)
#7 00000000 0x00000000 in ??() (??:??)

code for the particlesystem

Code: [Select]


this->pImage.LoadFromFile("./data/particles/test.png");
this->pSystem = new thor::ParticleSystem(this->pImage);
this->pEmit = thor::DirectionalEmitter::Create(30.f, 5.f);
this->pSystem->AddEmitter(this->pEmit);

this->pAffect = thor::FadeOutAffector::Create(0.1f);
this->pSystem->AddAffector(this->pAffect);
this->pSystem->SetGlowing(true);

... And in loop:

this->pSystem->Update(this->EngineHandle->GetFrameTime());
//Crashes on this line
this->pSystem->Draw(*this->EngineHandle->GetVideo()->GetWindow());


[gavintlgold]

Did you clean the entire project and rebuild? If it helps you, Nexus, particles are working properly for me with somewhat similar code. I know I had a crashing problem earlier where a rebuild solved it.

[Haikarainen]

Did you clean the entire project and rebuild? If it helps you, Nexus, particles are working properly for me with somewhat similar code. I know I had a crashing problem earlier where a rebuild solved it.

Yep, still no luck. I'm having some other issues with SFML tho, the same project crashes when trying to run the debugtarget. Crashes when you try to clear the renderwindow.

Edit: The same code didnt crash in the debugmode before i reformatted my computer

Edit2: Fixed the other sfml-related issue, apparently i had to link -d libs to the debugtarget. No luck on thor tho

Edit3: Located the line in thor's sourcecode where it segfaults;

Code: [Select]

void ParticleSystem::PushOpenGLStates(sf::RenderWindow& target) const
{
// Switch to manual OpenGL handling, save SFML's state
target.SaveGLStates(); <<----- THIS LINE
target.SetActive();

It's line 250 in ParticleSystem.cpp


Edit4: Last edit: Read http://www.sfml-dev.org/forum/viewtopic.php?p=34122

[panithadrum]

I can actually use your code, but not without converting all my QPointF to thor::Vertex and thor::Triangle<thor::Vertex> to QVector<QPointF> back again. Maybe it's not a need at all to make the triangulation work with Qt directly (at least is not critic for sure).

Ah yes, it is a little bit unfortunate that you need to convert these types. Inside the algorithm, I need a type like thor::Vertex that I know, I can't work with arbitrary template parameters because I don't know their interface (besides, the whole algorithm would have to be written in the header).

Yeah, you are right. I will convert my structs to thor::Vertex, but just wanted you to know that you can abstract an interface with some sort of macros (I don't know how exactly). Here is an example: http://geometrylibrary.geodan.nl/x01__qt__example_8cpp-example.html.

Code: [Select]

// Adapt a QPointF such that it can be handled by GGL
BOOST_GEOMETRY_REGISTER_POINT_2D_GET_SET(QPointF, double, cs::cartesian, x, y, setX, setY)
With this line the library can access to QPointF!

[Nexus]

Thanks, that's an interesting way to do it. It is typical for Boost to be generic at all costs

Nevertheless, I don't want to do it that way because

• Every single function and class of my triangulation algorithm needed to be a template. This makes code more complex, increases compile time at the user and may lead to code bloat when used for many, slightly different instantiations.
• I don't know whether the usage of triangulation would really become simpler. You also have to consider that thor::Vertex is not the whole story, there is also thor::Triangle<V> and thor::Edge<V>. To be fully generic, I needed to accept user-defined triangles and edges, too, which again requires to define all their interfaces via macro. Error messages get very complicated, besides there is no way to find out the element type behind an output iterator, so users would have to specify that too. In the end, it may happen that there is even more code necessary to tell Thor the interface of user classes than to write a conversion function.
• The conversion speed shouldn't be the issue: std::copy()/std::transform() is fast compared with the work done by the triangulation.
• Boost.Geometry is also more generic with respect to mathematical algorithms. I don't want Thor to become a math library, it should primarily provide functionality often used together with SFML plus some utilities like smart pointers. Note that the triangulation was originally intended for the implementation of thor::ConcaveShape. I thought that users might find it useful in other situations, so it became part of the API. For more elaborated, generic and optimized functionality, one would anyway use a library specific for that field of application.

[Groogy]

• The conversion speed shouldn't be the issue: std::copy()/std::transform() is fast compared with the work done by the triangulation.

I can kind of verify that. The models in my engine is "compiled" which actually transforms the vertexes in a more suitable way to be drawn to speed it up. The conversion is really fast and simple. The "compiled" version is never shown outwards and only make sense to the renderer in the engine.

And let's say we have:

• MyLib::Vertex
• thor::Vertex

It would be a trivial task to convert input and output, also preferable in the long run because of the points Nexus made.

[gavintlgold]

I'd like to mention that the particle system is really great for me. I wrote a new affector that just scales the image every step (I'd like to suggest that's included in thor by default actually, as it's sort of the only obvious thing missing from the particles package). Here's an example of it in action with a nice particle texture I made:

[Haikarainen]

I'd like to mention that the particle system is really great for me. I wrote a new affector that just scales the image every step (I'd like to suggest that's included in thor by default actually, as it's sort of the only obvious thing missing from the particles package). Here's an example of it in action with a nice particle texture I made:

Lol, was just about to post that as a feature request
Also, can you iterate thru particles and get their global position, size etc? Need simple collision detection for rain/skillsystem/waterfall/realistic smoke etc.

[gavintlgold]

Scale affector is really trivial (Nexus, please excuse me for not obeying your naming style):

Header

Code: [Select]

#include <Thor/Particles.hpp>

class ScaleAffector : public thor::Affector
{
  public:
    typedef std::tr1::shared_ptr<ScaleAffector> Ptr;

  public:
    static Ptr Create(sf::Vector2f scaleFactor);

  public:
    explicit ScaleAffector(sf::Vector2f scaleFactor);

    virtual void Affect(thor::Particle& particle, float dt);

    void SetScaleFactor(sf::Vector2f scaleFactor);

    sf::Vector2f GetScaleFactor() const;

  private:
    sf::Vector2f m_scale_factor;
};


Source

Code: [Select]

#include "affectors.hpp"

ScaleAffector::Ptr ScaleAffector::Create(sf::Vector2f scaleFactor)
{
  return Ptr( new ScaleAffector(scaleFactor) );
}

ScaleAffector::ScaleAffector(sf::Vector2f scaleFactor)
: m_scale_factor(scaleFactor)
{
}

void ScaleAffector::Affect(thor::Particle& particle, float dt)
{
  particle.Scale += dt * m_scale_factor;
}

void ScaleAffector::SetScaleFactor(sf::Vector2f scaleFactor)
{
  m_scale_factor = scaleFactor;
}

sf::Vector2f ScaleAffector::GetScaleFactor() const
{
  return m_scale_factor;
}

No, there's no way to iterate through all the particles. I think a better way for you to do what you want would be to make a physics affector that checks the particle's position in Affect and does any physics calculations there. It should be very simple with a format similar to the code above. You can see the properties of a particle that you can modify here

[Haikarainen]

No, there's no way to iterate through all the particles. I think a better way for you to do what you want would be to make a physics affector that checks the particle's position in Affect and does any physics calculations there. It should be very simple with a format similar to the code above. You can see the properties of a particle that you can modify here

The thing is I need collisions for more than the particles properties itself. I think iterating through all the particles would also be a powerful function in this lib.

[Nexus]

I'd like to mention that the particle system is really great for me. I wrote a new affector that just scales the image every step (I'd like to suggest that's included in thor by default actually, as it's sort of the only obvious thing missing from the particles package).

Hehe, I thought about implementing a ScaleAffector before the first release, but I wasn't sure whether it would be used often, and I didn't want to bloat the interface. But if you find it useful, I will add it

The thing is I need collisions for more than the particles properties itself. I think iterating through all the particles would also be a powerful function in this lib.

With an affector, you can iterate through the particles, even if this happens implicitly (no for loop). I don't like to give access to the internal container, as it is an implementation detail.

By the way, should I hide the public constructors of the affectors and emitters? This might prevent mistakes because you can only use emitters/affectors within shared_ptr objects, so the Create() factories would be enough...

[Haikarainen]

But if you find it useful, I will add it

Good news!

With an affector, you can iterate through the particles, even if this happens implicitly (no for loop). I don't like to give access to the internal container, as it is an implementation detail.

Ok, thats understandable, but how would you do that? All i found is ComputeNbParticles ?

By the way, should I hide the public constructors of the affectors and emitters? This might prevent mistakes because you can only use emitters/affectors within shared_ptr objects, so the Create() factories would be enough...

Probably would be a good idea

edit: Oh, Btw; Is there any possibility to configure the glow-option? Like strength, color etc? Or is it just on/off in the lower level too?

[Nexus]

Ok, thats understandable, but how would you do that? All i found is ComputeNbParticles ?

Derive a class from thor::Affector and override the Affect() method. You can also pass information about other entities (e.g. a collision manager reference) to the constructor of your class. ComputeNbParticles() is just needed for custom emitters.

Code: [Select]

class PhysicsAffector : thor::Affector
{
public:
virtual void Affect(thor::Particle& particle, float /*dt is ignored*/)
{
DoSomething(particle.Position)
}
};

edit: Oh, Btw; Is there any possibility to configure the glow-option? Like strength, color etc? Or is it just on/off in the lower level too?

No, it is currently just on/off. Do you have a suggestion how I could make it more configurable? I don't know how to set the strength, because the glow just influences the OpenGL blend mode (ParticleSystem.cpp, line 300).