Thor C++ Library – An SFML extension

[Nexus]

Because [...]

I know, but I think overload resolution should occur at the point of template instantiation (i.e. inside main()). Especially because the function argument T() is clearly dependent on a template parameter.

OT: Is there a reason why i can't use one Zone (thor::Emitter::ZonePtr) for two emitters? -> Assertion fail !IsNUll

ZonePtr is not a shared_ptr, but a MovedPtr (it transfers its ownership). My thought was that every emitter keeps an own zone, independent of other emitters. I found shared ownership less intuitive, what do you think?

You can still copy the zone by using thor::CopiedPtr (I know it could be easier ):

Code: [Select]

thor::CopiedPtr<thor::Zone, thor::VirtualClone> a(...), b = a;
emitter1->SetEmissionZone( thor::Move(a) );
emitter2->SetEmissionZone( thor::Move(b) );

By the way, that is not offtopic, the template discussion is

[lakunar]

My thought was that every emitter keeps an own zone, independent of other emitters. I thought shared ownership might have been less intuitive, what do you think?

I'm not really into shared & moved pointer.

I am also of the opinion that it is more intuitive if every emitter has it's one zone. But if you want to make an really cool effect than more emitters are in the same zone and it might be easier if you have a shared zone.

Maybe you should implement both, this means that we can choose on constuction and/or later if the emitter has it's own zone or if it uses a shared one.
Then it's possible to constuct for example 3 emitters with a shared zone, and later I can say now i want emitter 1 to have its own zone to modify this and not modifying the other ones.

Edit:
Well, I saw that it isn't that often that two emitters use exact the same Zone, so for me it's fine how it is now.

[Nexus]

Maybe you should implement both, this means that we can choose on constuction and/or later if the emitter has it's own zone or if it uses a shared one.

This would be the shared approach. You can still have multiple independent shared pointers.

There is however the problem how to create one std::tr1::shared_ptr of another one, while copying ownership. Currently, this can be done using Zone::Clone(), but I don't know whether this method will last forever. In contrast, thor::CopiedPtr is smart enough to perform deep copies without Clone().

You can still copy the zone by using thor::CopiedPtr (I know it could be easier ):

Okay, it is now easier

Code: [Select]

thor::Emitter::ZonePtr a(new thor::Rectangle(...));
thor::Emitter::ZonePtr b = thor::Copy(a);
// a and b are now independent and both non-empty
I also improved the documentation of ZonePtr and emphasized the transferred ownership semantics.

[lakunar]

Shouldn't it be "affector" instead of "emitter"? in
include/Thor/Particles/Emitter.hpp, line 147

Code: [Select]

00147 void AddAffector(Affector::Ptr emitter, const RemovalTrigger& trigger);

---
Shouldn't this work?:

Code: [Select]

thor::ParticleSystem system(image);
...
thor::TargetEmitter::Ptr temitter( new thor::TargetEmitter(200.f, 2.f) );
...
temitter->Emit(system,10.0f); //Error
Error:

Code: [Select]

 'thor::Emitter::Adder' is an inaccessible base of 'thor::ParticleSystem'
Or did i misunderstood there something?

---

Okay, it is now easier

Ah this Copy Funktion looks nice and easy

[Nexus]

Shouldn't it be "affector" instead of "emitter"? in
include/Thor/Particles/Emitter.hpp, line 147

Yes, I just fixed this a few minutes ago

Shouldn't this work?:

Code: [Select]

thor::ParticleSystem system(image);
...
thor::TargetEmitter::Ptr temitter( new thor::TargetEmitter(200.f, 2.f) );
...
temitter->Emit(system,10.0f); //Error

No, you don't need to call Emit() directly. Just add the emitter to the system and update it every frame:

Code: [Select]

thor::ParticleSystem system(image);
thor::TargetEmitter::Ptr temitter( new thor::TargetEmitter(200.f, 2.f) );
system.AddEmitter(temitter);

    // later, in the main loop
    system.Update(frameTimeInSeconds);
    system.Draw(window);
You could also have a look at the Particles tutorial on my homepage.

[lakunar]

you don't need to call Emit() directly

mh
The Problem:
I want to emit particles on an event but just for a certain time.  And i thought that adding and removing(auto) emitters from the system isn't the best way to do this. So I searched for a fire, start func.
Problem with AddEmitter is that it causes a assertion fail if it is called to fast(as long the emitter is emitting) with the same emitter

[Nexus]

I want to emit particles on an event but just for a certain time.  And i thought that adding and removing(auto) emitters from the system isn't the best way to do this.

It was indeed not the best approach until recently. But now, there is an AddEmitter() overload that takes a functor to remove the emitter upon a certain condition (see documentation). There is even a predefined functor for a time-limited emission:

Code: [Select]

thor::ParticleSystem system(...);
thor::Emitter::Ptr emitter(...);
system.AddEmitter(emitter, thor::ParticleSystem::TimeLimit(0.5f));

Problem with AddEmitter is that it causes a assertion fail if it is called to fast(I think) with the same emitter

Yes, the assertion should prevent you from adding an already added emitter by accident.

[lakunar]

Yes, the assertion should prevent you from adding an already added emitter by accident.

Ok.

I have another Problem :?
I don't know if this is a thor or sfml bug.

But the following Code doesn't copy the Image because image2.Copy check if image2 is not 0 (Width,Height) which it is after construction.

Code: [Select]

sf::Image image;
if (!image.LoadFromFile("Media/particles.png"))
  return EXIT_FAILURE;
sf::Image image2;
image2.Copy(image,0,0,sf::IntRect(0,0,32,32));

So this causes a problem with:

Code: [Select]

thor::ParticleSystem system(image,sf::IntRect(0,0,32,32));
which tries to copy the Image in a new constuctet one

[Nexus]

Thanks a lot for the report, partial images should work now. It was indeed my mistake, I hadn't allocated enough space before calling sf::Image::Copy().

[Kened]

First of all, I'm C#.NET-spoiled guy so this is my first time doing something like building libraries. Therefore it's very likely I've made some dumb mistake along the way.
I built and installed sfml2 (the recommended version) without issues and tested some basic stuff.
Then I made makefile (following the tutorial) for the Thor library (the latest from SVN), but when I tried to build it (MinGW 4.4.1) I got this:

Code: [Select]

c:\dev\thor-build>mingw32-make
[  2%] Building CXX object src/CMakeFiles/thor.dir/Random.cpp.obj
C:\dev\svn\thor\src\Random.cpp:96: error: 'Uint64' in namespace 'sf' does not name a type
C:\dev\svn\thor\src\Random.cpp: In member function 'sf::Uint32 thor::<unnamed>::Engine::operator()()':
C:\dev\svn\thor\src\Random.cpp:71: error: 'Uint64' in namespace 'sf' does not name a type
C:\dev\svn\thor\src\Random.cpp:73: error: 'x' was not declared in this scope
C:\dev\svn\thor\src\Random.cpp:73: error: 'a' was not declared in this scope
C:\dev\svn\thor\src\Random.cpp: In member function 'void thor::<unnamed>::Engine::seed(sf::Uint32)':
C:\dev\svn\thor\src\Random.cpp:80: error: 'x' was not declared in this scope
mingw32-make[2]: *** [src/CMakeFiles/thor.dir/Random.cpp.obj] Error 1
mingw32-make[1]: *** [src/CMakeFiles/thor.dir/all] Error 2
mingw32-make: *** [all] Error 2

[Nexus]

It seems like you use an SFML revision which doesn't have sf::Uint64 yet. Update to the newest Git revision of SFML, then it should work.

The SFML version provided on the website is recommended only for Thor 1.0. Maybe I should clarify that.

[Kened]

Oh, so that was the stupid mistake I made. Thank you, it works now.

[Haikarainen]

GREAT Project! dont know if i posted here before, but i just now checked out your lib in detail, and i have to say i am very impressed! It really is more too it than what meets the eye at first glance.

Really fell in love with your particle system, and geometrical capabilities

[Nexus]

Thank you

I have already thought about extending the Geometry module (for example to provide a Polygon class and a ContainsPoint() function, which would not be difficult to implement by means of the triangulation functions). But I believe for this kind of functionality, there are much more specific and optimized libraries around, among others Boost.Geometry coming with Boost 1.47. Maybe I am going to use Boost one day, it would simplify a lot...

Anyway, I still have to find a more generic design of the animation system, allowing sprite modifications apart from subrects. And this in turn may require modifications of the Resource module (especially ResourcePtr). At the same time, I have to keep pace with SFML's modifications

[OniLinkPlus]

Hey, Nexus, if you're interested, I implemented a concave point detection algorithm in my Terra Game Engine. It goes through all of the points in a shape and creates a list of the points which are concave. Maybe you could use it for triangulation?