Meanwhile I have finished to adapt the naming convention, additionally I have modified a few other things (see here for detailed list). In short, I have switched to GitHub and split a part of Thor into a separate library called Aurora.

Now I begin to work on changes announced earlier. To separate current development from Thor 1, I have opened a new thread. Here I am going to frequently inform you about updates. Please post suggestions and design discussions also here

Nexus, do you know that you can add it as a Git submodule instead of copying it? A submodule is a link/shortcut to an external repository, at a given revision. As a result, the submodule appears as if it was directly included in the main repo, but in fact you get its files from its own repo directly.

Yes, I originally wanted to do it like this. However I've had some trouble setting it up with local repositories, and I've read at different places that submodules wouldn't be a very mature concept (for example, one cannot easily delete them). If I remember correctly, a Git clone doesn't clone submodule directories, leaving more work to the user. Currently I use the subtree approach described here.

Or have you made other experiences and can you recommend Git submodules?

With submodules :- you can't just do git clone (have to add --recursive)- the zip archive provided by GitHub won't include the submodules- you still have to manually update the submodule head against which you want your own sources to be updated (if modifications are done in SFML repo, they won't be automatically transferred to your repo for example)

Thanks for the information, Ceylo. I have switched to the git-subtree tool, it works good so far. And the advantage over git merge -s subtree is that I can have one commit and a merge (because in subtree merge, --squash hides the merge message). And of course it's easier, I don't need a separate branch.

Hello, I switched to Thor 2.0 (after hours of pain with boost::python in order to make aur::CopiedPtr work... ) but I get a std::logic_error when loading an image : "No copy allowed".Same error in the Resources example.

I should note that I disabled C++11 support (commenting "aur/Config.hpp", as it provoked compile errors in cmath (MinGW build : , i.e. TDM-GCC 4.6.1), I guess the problem is there

In some cases, aur::CopiedPtr doesn't have to be copied, for example when you pass a temporary object to a function or return an object from a function. In C++11, this is very easy to achieve with move semantics. In C++98, I hoped that compiler optimisations (like RVO) could lead to the same result, but in fact it's too unreliable to make semantics depend on it. The std::logic_error approach is an interim solution, it's not my style to throw exceptions upon logic errors.

Unfortunately, there is no elegant way to transfer ownership in C++98. In Thor 1, MovedPtr was designed to achieve this, but I realized the whole design got too complicated and unintuitive (a user didn't know when to use which smart pointer, had to invoke thor::Copy() manually in some cases, and was surprised by implicit ownership transfer). That's why I simplyfied the Aurora.SmartPtr module a lot -- and interestingly -- made it far more powerful at the same time.

I see two solutions to deal with the problem:

Enforce C++11. That would be very nice anyway.

In the specific case of Thor.Resources, use raw pointers. Although I don't like them, it might be justified in this case. However, this doesn't solve the problem of unnecessary (and possibly expensive) copies in other situations.

You say C++11 support provoked compile errors, can you give more details?

The first bigger refactoring has been done, it concerns the design of the particle emitters. I wrote the new UniversalEmitter class, which is far more powerful than the existing emitters. As the name implies, you can set every initial particle attribute using a functor. That is, you specify a function that is called every time a particle is emitted. For example, you can specify a random distribution for the initial position. Or set the position according to the mouse or another game object. Hereby, the predefined distributions in Math/Distributions.hpp may be of help.

This new design also has an impact on other parts of the library, namely:

The complete Geometry module has been removed. For a long time, I thought about a redesign of the Zone class hierarchy. I have never liked the asymmetric treatment of initial position (determined via Zone) and initial rotation (not possible to set at all). While searching for alternatives, I came up with the distribution approach.

Removed classes DirectionalEmitter and TargetEmitter. They are too specific, UniversalEmitter outperforms them easily in terms of flexibility.

Turned Emitter class into a stateless interface. For custom emitters, no more attributes are dictated by the library, so you can implement whatever you want.

Renamed emitter methods. Instead of setParticleVelocity(), it's now just setVelocity().

I'm having a problem trying to compile Thor with CMake. Specifically I'm getting the same SFML_DIR-NOTFOUND error (whether I change SFMLDIR or SFML_DIR it always comes out with the same error). I have SFML installed from the git tutorial.

EDIT: I got it fixed; for some reason the FindSFML.cmake file wasn't copied to the Modules folder in CMake. Copying it over seemed to fix it. While compiling however I get an error when trying to compile the examples:

I'm having a problem trying to compile Thor with CMake. Specifically I'm getting the same SFML_DIR-NOTFOUND error (whether I change SFMLDIR or SFML_DIR it always comes out with the same error). I have SFML installed from the git tutorial.

EDIT: I got it fixed; for some reason the FindSFML.cmake file wasn't copied to the Modules folder in CMake. Copying it over seemed to fix it.

Yep! I confirm the problem and the solution (thanks Astrof!) with Bromeon-Thor-9b4b3d9.tar.gz.

CMake Warning (dev) in CMakeLists.txt: No cmake_minimum_required command is present. A line of code such as

cmake_minimum_required(VERSION 2.8)

should be added at the top of the file. The version specified may be lower if you wish to support older CMake versions for this project. For more information run "cmake --help-policy CMP0000".This warning is for project developers. Use -Wno-dev to suppress it.

I'm having a problem trying to compile Thor with CMake. Specifically I'm getting the same SFML_DIR-NOTFOUND error (whether I change SFMLDIR or SFML_DIR it always comes out with the same error). I have SFML installed from the git tutorial.

I think you have to install SFML, not just build it (the CMake install command copies the FindSFML file). You have to type make install (using g++) or compile the INSTALL project (Visual Studio).