Thor 2.0 released!

[Tresky]

Were the Thor smart_ptrs taken out of the library? I can't find them.

[eXpl0it3r]

Were the Thor smart_ptrs taken out of the library? I can't find them.

Yes!
You now should use the official C++11 std::shared_ptr<T>.

[Tresky]

My compiler isn't compatible with C++11. Unless there was a MSVS2010 update I'm not aware of.

EDIT: I take that back. Finally found them. Just had to do the right search.

[Nexus]

Were the Thor smart_ptrs taken out of the library? I can't find them.

Depends, which one do you mean? The following points have changed from Thor 1.1 to Thor 2.0 (and the library Aurora on which Thor depends):

• thor::CopiedPtr -> aurora::CopiedPtr (with other API)
  
• thor::ScopedPtr -> removed, might be re-implemented in Aurora
  
• thor::MovedPtr -> removed
  
• thor::ResourcePtr -> removed, use std::shared_ptr
  

[Nexus]

Most important changes in July:

• Added a FindThor CMake module (thanks to nokurn).
• Removed Animator::setDefaultAnimation(). This means a simpler interface without loss of functionality (you can still check if no animation is playing, and play a default one in this case).
  
• Split the module Multimedia into two modules Graphics and Shapes. I like to have small modules with specific application fields.
• Painted a better texture for the Animation example, and used a more complex animation.

For the swiss national day, I developed a new Fireworks example today. It shows how to write custom particle emitters and affectors and combines them with various utilities like thor::CallbackTimer or thor::PolarVector2f. I hope you like it.

[eXpl0it3r]

For the swiss national day, I developed a new Fireworks example today. It shows how to write custom particle emitters and affectors and combines them with various utilities like thor::CallbackTimer or thor::PolarVector2f. I hope you like it.

Awesome!
Are you Swiss too or was the more of a coincident?

I should defently take a look at particles at one point.

[Hiura]

Hahaha this is awesome ! 

[Nexus]

Thank you both! Yes, I am Swiss

Here is a small screenshot of the fireworks. To see them in action, build the Thor examples of the latest Git revision.

[Tresky]

Hey! I've begun using the Animation classes for Thor to help animate the ground on a map (water flowing, grass moving, etc). I was wondering, would it be best to have one Animator animating every single tile of grass (its a tile map), or to have each tile have its own Animator and just update them all?

It seems like the second method would be memory intensive, but I'm not expert with Thor yet, so I'm not sure how it goes about doing things.

[Nexus]

It depends on whether the animations are synchronized. If for all grass tiles, the same frame is shown at the same time, you can use a single animator and call animate() multiple times. If each tile has its own animation state, store separate animators.

[Tresky]

Ah! That makes sense. Thank you.

[Tank]

I think 50% of all SFML users are from Switzerland. I feel oppressed.

The fireworks look nice. I tried the other examples too for the first time (not only reading through the sources this time) and discovered a bug in the triangulation example. See attached file for a screenshot. The lower right point was added last. Besides of that I reaaally love the triangulation.

Are there any plans on your side to add the 3rd dimension? Imho it's easier to stick to 3D for the library and just ignore the Z component everywhere in 2D games instead of using 2D everywhere, which makes it impossible to use Thor in 3D games.

[attachment deleted by admin]

[Nexus]

The fireworks look nice.

Thanks! First I just used single particles (like in the Particles example), but it didn't look good and I spent some time to make "tails"

I tried the other examples too for the first time (not only reading through the sources this time) and discovered a bug in the triangulation example. See attached file for a screenshot. The lower right point was added last.

Assuming you mean the lines that exceed the convex hull: This is not a triangulation bug, but a SFML shape issue. I noticed this behavior already when I tested the triangulation, but considered it a SFML-given limitation and didn't think anymore about it. But I opened a thread now.

Are there any plans on your side to add the 3rd dimension?

Generally, Thor as an SFML extension doesn't really provide 3D functionality (apart from basic vector operations that might be useful for SFML sound spatialisation). I don't know if the generalization would complicate the algorithm a lot. If not, I might indeed reflect about it, but there are many more important points to be done before.

Thor's triangulation functionality was originally needed for thor::ConcaveShape, but I thought there might be more applications and as I already implement it anyway, I could put it into the API. But I'm not a graph theorist, so there are certainly more optimized implementations out there. Maybe LEMON (a very nice graph library I use) has something, I also heard that Delaunay triangulation might be a candidate for Boost.Geometry.

[Tank]

Assuming you mean the lines that exceed the convex hull: This is not a triangulation bug, but a SFML shape issue.

Okay I see. Just thought it's worth mentioning.

I don't know if the generalization would complicate the algorithm a lot.

More complicated? No. Different? Yes.

But I'm not a graph theorist, so there are certainly more optimized implementations out there.

I do know nearly nothing about any triangulation algorithms, and yours already looks quite good. Of course I don't know how good it performs etc., but I guess it's enough for a lot of cases, especially in the 2D area.

[frapa]

I tried to compile thor on my linux machine with g++ and I got this error:

Code: [Select]

/home/francesco/Downloads/Bromeon-Thor-05b0078/src/InputNames.cpp: In function ‘thor::{anonymous}::StringBimap<sf::Keyboard::Key> thor::{anonymous}::InitMap(aurora::Type<sf::Keyboard::Key>)’:
/home/francesco/Downloads/Bromeon-Thor-05b0078/src/InputNames.cpp:86:3: error: ‘Unknown’ is not a member of ‘sf::Keyboard’
make[2]: *** [src/CMakeFiles/thor.dir/InputNames.cpp.o] Error 1
make[1]: *** [src/CMakeFiles/thor.dir/all] Error 2
make: *** [all] Error 2

I tried to remove the line 86 and the compilation went fine.