Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Thor 2.0 released!  (Read 368892 times)

0 Members and 19 Guests are viewing this topic.

dragondgold

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: Thor 2.0
« Reply #180 on: May 01, 2013, 03:56:31 pm »
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
« Last Edit: May 01, 2013, 04:06:11 pm by dragondgold »

Lee R

  • Jr. Member
  • **
  • Posts: 86
    • View Profile
Re: Thor 2.0
« Reply #181 on: May 01, 2013, 04:50:55 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #182 on: May 01, 2013, 05:17:41 pm »
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!
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

FRex

  • Hero Member
  • *****
  • Posts: 1848
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: Thor 2.0
« Reply #183 on: May 01, 2013, 05:23:59 pm »
Actually I was wrong in what I just written here so I removed it. ;D

Quote
Thanks a lot, I'm really glad that people occasionally look at my code!
I sometimes do too, at Thor, Lua, SFG and SFML.
« Last Edit: May 01, 2013, 05:28:50 pm by FRex »
Back to C++ gamedev with SFML in May 2023

dragondgold

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: Thor 2.0
« Reply #184 on: May 01, 2013, 05:31:33 pm »
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 :D 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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #185 on: May 01, 2013, 05:38:02 pm »
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).
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

dragondgold

  • Newbie
  • *
  • Posts: 15
    • View Profile
    • Email
Re: Thor 2.0
« Reply #186 on: May 01, 2013, 11:34:26 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
[Thor] Color gradients
« Reply #187 on: May 05, 2013, 02:17:08 pm »
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?
« Last Edit: May 05, 2013, 02:19:11 pm by Nexus »
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #188 on: May 05, 2013, 02:35:43 pm »
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
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #189 on: May 05, 2013, 08:53:31 pm »
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.
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #190 on: May 06, 2013, 03:20:56 pm »
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) :P I think that using tabs for indentation is ok, but spaces should be preferred when you want to align things vertically.
Laurent Gomila - SFML developer

Nexus

  • SFML Team
  • Hero Member
  • *****
  • Posts: 6287
  • Thor Developer
    • View Profile
    • Bromeon
Re: Thor 2.0
« Reply #191 on: May 06, 2013, 04:09:21 pm »
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 :P

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) :P 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 ;)
Zloxx II: action platformer
Thor Library: particle systems, animations, dot products, ...
SFML Game Development:

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #192 on: May 06, 2013, 04:31:33 pm »
Ah, sorry, I didn't realize that setParticlePosition was taking a functor and not a value ;D

Quote
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.
Laurent Gomila - SFML developer

fstream

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: Thor 2.0
« Reply #193 on: May 06, 2013, 06:50:50 pm »
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;
}
« Last Edit: May 06, 2013, 06:57:29 pm by fstream »

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Thor 2.0
« Reply #194 on: May 06, 2013, 06:55:09 pm »
Thanks, this is exactly what I mean :D
Laurent Gomila - SFML developer