Thor 2.0 released!

[dragondgold]

So is the libthor-d.so in the SFML directory?
Otherwise you'll also have to add /Thor/lib to the linking command.

Yes, the library is in SFML-2.0/lib as you can see here:

ls '/home/andres/Dropbox/Development/SFML-2.0/lib'
libsfml-audio.so         libsfml-network.so      libsfml-window.so
libsfml-audio.so.2       libsfml-network.so.2    libsfml-window.so.2
libsfml-audio.so.2.0     libsfml-network.so.2.0  libsfml-window.so.2.0
libsfml-graphics.so      libsfml-system.so          libthor-d.so
libsfml-graphics.so.2    libsfml-system.so.2
libsfml-graphics.so.2.0  libsfml-system.so.2.0

In my Thor folder I have no lib folder, the library was compiled directly in SFML lib folder.

/usr/local/lib is not set by default for the LD_PATH_LIBRARY, so you'll have to set LD_PATH_LIBRARY with /usr/local/lib manually first for the linker to search in that directory.

I have added it because SFML also have libraries in /usr/local/lib:

cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
include /usr/local/lib

Is very strange. To build Thor I have used this inside Thor directory:

cmake -G "Unix Makefiles" -D CMAKE_BUILD_TYPE=Debug -D CMAKE_INSTALL_PREFIX='/home/andres/Dropbox/Development/SFML-2.0' -D SFML_INCLUDE_DIR=/home/andres/Dropbox/Development/SFML-2.0/include -D SFML_ROOT=/home/andres/Dropbox/Development/SFML-2.0 -D THOR_BUILD_DOC=TRUE -D THOR_BUILD_EXAMPLES=TRUE -D THOR_SHARED_LIBS=TRUE .
make
sudo make install

I have it running OK on my Windows XP machine with Eclipse too.
Here you can see an image of how are my linker settings configured: https://www.dropbox.com/s/p0lp1jt2c2iqcq3/Eclipse.png

[Lee R]

Check this snippet, taken from 'ParticleSystem::computeVertices':

// Fill vertex array
AURORA_FOREACH(const Particle& p, mParticles)
{
    for (unsigned int i = 0; i < 4; ++i)
    {
        sf::Transform transform;
        transform.translate(p.position);
        transform.rotate(p.rotation);
        transform.scale(p.scale);

        mVertices.append( sf::Vertex(transform.transformPoint(positionOffsets[i]), p.color, texCoords[i]) );
    }
}

There is no need to re-construct the transform for each iteration of the inner loop. I'm guessing this is a refactoring artifact?

[Nexus]

The problem is when I try to run my program using Thor I get this:

Try sudo ldconfig to update the linker paths. Is there a reason why you link to the release version of SFML, but the debug version of Thor?

There is no need to re-construct the transform for each iteration of the inner loop. I'm guessing this is a refactoring artifact?

Maybe I just overlooked it

Thanks a lot, I'm really glad that people occasionally look at my code!

[FRex]

Actually I was wrong in what I just written here so I removed it.

Thanks a lot, I'm really glad that people occasionally look at my code!

I sometimes do too, at Thor, Lua, SFG and SFML.

[dragondgold]

Try sudo ldconfig to update the linker paths. Is there a reason why you link to the release version of SFML, but the debug version of Thor?

You are amazing Nexus It worked perfectly! Seems that something messed up!
Actually, I don't know what is the difference between Release and Debug libraries, I have always used libraries simply putting #include in my program is the first time I have to use a library and don't know why and haven't found nothing about it 

[Nexus]

In general, you should use the release libraries. If you build Thor with CMake, set CMAKE_BUILD_TYPE to "Release". To link Thor, choose the library without -d prefix; in your linker settings, you can just specify "thor".

On Linux, the debug libraries are only needed if you need debugging symbols (i.e. you want to debug the library).

[dragondgold]

In general, you should use the release libraries. If you build Thor with CMake, set CMAKE_BUILD_TYPE to "Release". To link Thor, choose the library without -d prefix; in your linker settings, you can just specify "thor".

On Linux, the debug libraries are only needed if you need debugging symbols (i.e. you want to debug the library).

Nice, thank you for the info ! I have seen also that debug libraries have much more file size than release libraries (sorry my bad english)
Thank you very much for your help!

[Nexus]

Recent changes

• ActionMap no longer stores the window, it is passed in update()
  
• ParticleSystem is constructed using const sf::Texture& instead of std::shared_ptr<const sf::Texture> -- should be closer to SFML
  
• Animator has now a function getPlayingAnimation() that returns the animation currently being played
  
• The class RefAnimation has been added to reference (instead of copy) another animation
  

New color gradient API

Since a long time I want to redesign the ColorGradient API. Currently, one specifies relative transition times between colors. In the following example, the transition from red to blue is 3 times longer than the transition from blue to cyan.

thor::ColorGradient gradient = thor::createGradient
(sf::Color::Red)
(3.f)
(sf::Color::Blue)
(1.f)
(sf::Color(0, 255, 255));

Despite being short, it may be somehow unintuitive, and it makes it difficult to use specific functions that take RGB (or HSV, in later Thor versions). Therefore I tend to named functions, two possibilities to achieve the same functionalities would be:

thor::ColorGradient gradient;
gradient.color(sf::Color::Red);
gradient.transition(3.f);
gradient.color(sf::Color::Blue);
gradient.transition(1.f);
gradient.rgb(0, 255, 255);

thor::ColorGradient gradient = createGradient()
.color(sf::Color::Red)
.transition(3.f)
.color(sf::Color::Blue)
.transition(1.f)
.rgb(0, 255, 255);

The second option would allow for more type safety, since I can enforce that transitions and colors are specified alternately. Additionally, one cannot change the gradient after construction.

Basically, do you consider the alternating transition-color chain meaningful? Or should I go with another model, like specifying points instead of transitions? The equivalent functionality would then look as follows (conventional methods or map style):

thor::ColorGradient gradient;
gradient.color(0.f, sf::Color::Red);
gradient.color(0.75f, sf::Color::Blue);
gradient.rgb(1.f, 0, 255, 255);

thor::ColorGradient gradient;
gradient[0.f] = sf::Color::Red;
gradient[0.75f] = sf::Color::Blue;
gradient[1.f] = sf::Color(0, 255, 255);

The disadvantage is that one always needs to specify 0.f and 1.f, and it becomes more difficult to express ratios between different partial gradients. Before, it was immediately clear that the first transition had 3 times the length of the second.

Maybe another idea?

[Laurent]

The second API has its own benefits that should be considered in my opinion:

- it's kind of standard (I've never seen an API similar to the first one for defining gradients)
- it allows to give points in arbitrary order
- it may be more intuitive to associate the color and its position in the same function call, rather than giving them alternately

[Nexus]

Thanks for the feedback. I chose the following variant, its syntax pleases me most:

thor::ColorGradient gradient;
gradient[0.f] = sf::Color::Red;
gradient[0.75f] = sf::Color::Blue;
gradient[1.f] = sf::Color(0, 255, 255);

There might be users forgetting to set 0.f and 1.f, but it's highlighted in the documentation and verified with assertions.

[Laurent]

I was looking at Thor/examples/Particles.cpp, and noticed something about the MousePosition functor: it is used only once, and it is "incorrect" (you should call window.mapPixelToCoords, not cast the vector to float directly). So maybe you should just remove it?

And by the way, tabs in the middle of lines look very ugly (at least on github) I think that using tabs for indentation is ok, but spaces should be preferred when you want to align things vertically.

[Nexus]

Thanks for the remarks!

it is "incorrect" (you should call window.mapPixelToCoords, not cast the vector to float directly)

You are right. I only had sf::Window, so I replace it with sf::RenderWindow and call sf::RenderWindow::mapPixelToCoords().

it is used only once [...] So maybe you should just remove it?

If you mean I should directly insert a value, this won't work, since I need to poll the mouse position continuously -- that's why I use a functor and no constant. What I could do would be to set the position each frame, but that somehow defeats the purpose of showing the distribution functors. On the other hand, I also do that for the velocity

In fact, this stuff is all quite old, with C++11 I could simply use a lambda expression. Some parts might become also simpler if I performed the Particles refactoring which I have in mind: To go away from shared-ownership and inherited emitters and affectors, towards functors that are copied -- very similar to the Animation API. Instead of:

thor::UniversalEmitter::Ptr emitter = thor::UniversalEmitter::create();
emitter->setEmissionRate(30.f);
system.addEmitter(emitter);

One would write:

thor::UniversalEmitter emitter;
emitter.setEmissionRate(30.f);
system.addEmitter(emitter);

However I'm not quite sure yet, I still have to investigate some points...

And by the way, tabs in the middle of lines look very ugly (at least on github) I think that using tabs for indentation is ok, but spaces should be preferred when you want to align things vertically.

I guess you mean

        sf::Vector2f            position;
        thor::PolarVector2f velocity(200.f, -90.f);
        bool                            paused = false;

That's indeed ugly, and it's not my way to define variables anyway. So I'll just go with one space.

What I always do, is using tabs inside class definitions, to align (return) types and declarations. It may be unconventional, but I won't change this just because sites like GitHub are not capable of displaying it correctly. Seriously, they can't just assume everybody uses tabs of width 8

[Laurent]

Ah, sorry, I didn't realize that setParticlePosition was taking a functor and not a value

It may be unconventional, but I won't change this just because sites like GitHub are not capable of displaying it correctly. Seriously, they can't just assume everybody uses tabs of width 8

The problem when you use tabs to align things, is that you assume that tabs have a certain width, because you may mix whitespace (variable width) and characters (fixed width). It can work only with the tab width that you assumed when you wrote the code.

In your example above, "::PolarVector2f " takes 16 characters, therefore you use 2 tabs to align what's below if your tab width is 8, but in an editor where tab width is 4, alignment is broken.

[fstream]

For the record, tabs are used for indentation, spaces are used for alignment.

int main()
{
____printf("Indented!\n");
____int foo____= 3,
________barbaz_= 8;
____return EXIT_TAB_SUCCESS;
}

[Laurent]

Thanks, this is exactly what I mean