Thor 2.0 released!

[Astrof]

I thought it became easier
What do you have to do in addition at the moment?

It's easier in the sense that if we want to make custom emitters we just have to pass functions instead of creating our own custom class; however it takes more work to do the simple emitters (Directional, etc) as now we have to "think" and figure out for ourselves what to do.  I know; it's so hard. 

[Nexus]

The main thing you can't do like before is this:

emitter->setParticleVelocity(v);
emitter->setEmissionAngle(a);

It's now

emitter->setVelocity( thor::Distributions::deflect(v, a/2) );

With the new approach, it is clearer which attribute (velocity) is modified. But I see it may look more complicated if you're used to the DirectionalEmitter

By the way, I've adapted Thor to the SFML modification.

[Astrof]

Ah I get it now; my problem was I was taking the same line of code to change the velocity and was throwing in random Distributions (like circle, rect, etc) so i was confused how that distribution was changing everything. 

[DJuego]

By the way, I've adapted Thor to the SFML modification.

Thank you Nexus!  The particle system cast a spell on me...

I am sure that you would encourage your addon (and SFML) by means of youtube videos with guides/samples for smoke, fire, water, snow/sand torments. It will be instructive and a exhibition of magic power 

DJuego

Sorry for muy defective English.

[Nexus]

That's a good idea, but I'll probably focus on such things if most of the functionality for the next version has been implemented

[eXpl0it3r]

I have two question about the resource manager.

1. When I had the resource key K and now acquire the resource with two diffrent resource pointers, do I get now twice a 'reference' to the resource or is it more like copying one resource pointer to another?

thor::ResourceManager<sf::Texture> Mgr;
thor::Resource::TextureKey K thor::Resource::TexutreKey::fromFile("image.png");
thor::ResourcePtr<sf::Texture> ptr1 = Mgr.acquire(K);
thor::ResourcePtr<sf::Texture> ptr2 = Mgr.acquire(K);
// What's the difference to this
thor::ResourcePtr<sf::Texture> ptr3 = Mgr.acquire(K);
thor::ResourcePtr<sf::Texture> ptr4 = ptr3;
 

2. If I had a LoadSprites() function with which I'd initialize all my sprites and I'd now go and acquire every resource I'd need and safe it in resource pointers which are local to that function, hand the resource over to the sprite object and then leave this function, will the resources now get freed (since the resource pointer get destroyed at the end of the function) and thus the sprites will have an invalid texture?
Maybe the question could also be ask like, do I have to store the resource pointers in the class, if I want to use it from diffrent functions?

sf::Sprite S;
void LoadSprites()
{
        thor::ResourceManager<sf::Texture> Mgr;
        thor::Resource::TextureKey K thor::Resource::TexutreKey::fromFile("image.png");
        thor::ResourcePtr<sf::Texture> ptr = Mgr.acquire(K);
        S.setTexture(*ptr);
}
void Draw()
{
        // ...
        window.Draw(S);
        // ...
}
}

I hope I made my questions enough clear...

[Nexus]

1. When I had the resource key K and now acquire the resource with two diffrent resource pointers, do I get now twice a 'reference' to the resource or is it more like copying one resource pointer to another?

Using the same key, acquire() returns the same resource, so yes, you could as well copy the resource pointer. But sometimes you don't already have a resource pointer, only a filename or something (which is stored in the key).

2. If I had a LoadSprites() function with which I'd initialize all my sprites and I'd now go and acquire every resource I'd need and safe it in resource pointers which are local to that function, hand the resource over to the sprite object and then leave this function, will the resources now get freed (since the resource pointer get destroyed at the end of the function) and thus the sprites will have an invalid texture?

Yes, the resources would be released. To ensure your resource stays alive, keep a resource pointer to it. I know the integration to SFML's classes is not seamless (since sf::Sprite only takes raw pointers), there's not much I can do about it except to provide an own sprite class, but that would only pay out if it combined other improvements (like thor::BigSprite).

By the way, the Resources module is probably the next part I'm going to refactor. The basic concept remains the same, but there will be std::shared_ptr and different resource keys. And I think I can no longer postpone the decision of C++11 support, I'll make it a prerequesite.

[eXpl0it3r]

Thanks for the answers!

By the way, the Resources module is probably the next part I'm going to refactor. The basic concept remains the same, but there will be std::shared_ptr and different resource keys.

What do you mean with diffrent resource keys?

And I think I can no longer postpone the decision of C++11 support, I'll make it a prerequesite.

I think it's okay to prerequesite C++11 as long as the common compiler (MSVC 2010 and GCC 4.8+) can compile it.

Since you're gonna refractor it, I wanted to asked if it was somehow possible to combine the resource manager into one class or provide another class which combines the other ones. It's just kinda of annoying if you have to keep track of three or more diffrent resource managers (one for loading fonts, one for loading textures, one for loading sounds, etc). I don't know how one would do this the best way but maybe you do!

[Nexus]

What do you mean with diffrent resource keys?

I thought about a single class template thor::ResourceKey<R>, where R is the resource. For example, thor::ResourceKey<sf::Texture> replaces thor::Resources::TextureKey. It can be initialized from a function returning a pointer to a resource (maybe unique_ptr) and a string representation to compare different keys. It also provides methods to actually load a resource and to get debug informations. Resource keys are more constrained (one must use thor::ResourceKey), but custom ones are easier to construct.

template <class R>
class ResourceKey
{
    public:
                             ResourceKey(std::function<R*()> loader, std::string key);
        std::unique_ptr<R>   load() const;
        std::string          getInfo() const;
};

Furthermore, there are free functions that create a resource key, for example:

template <class R>
thor::ResourceKey<R> thor::Resources::fromFile(std::string filename);

Note that it is a template. It should be able to load every class providing a method

bool R::loadFromFile(std::string filename);

Unfortunately, I would have to create a special case for sf::Music because of its openFromFile() function

thor::ResourceManager<Resource> itself doesn't require a second template argument, keys are always thor::ResourceKey<Resource>. Loading looks like this:

thor::ResourceManager<sf::Texture> manager;
manager.acquire( thor::Resources::fromFile<sf::Texture>("image.png") );

The thing I currently don't like is the need to specify sf::Texture again. I could avoid that by complicated return types with implicit conversions, but that's probably not good either

What do you think?

Since you're gonna refractor it, I wanted to asked if it was somehow possible to combine the resource manager into one class or provide another class which combines the other ones. It's just kinda of annoying if you have to keep track of three or more diffrent resource managers (one for loading fonts, one for loading textures, one for loading sounds, etc). I don't know how one would do this the best way but maybe you do!

Yes, I've already thought about this in Thor 1, but I haven't found a clean solution so far. However I'll reflect about it again, thanks for the feedback

[eXpl0it3r]

The thing I currently don't like is the need to specify sf::Texture again. I could avoid that by complicated return types with implicit conversions, but that's probably not good either

What do you think?

I like getting rid of the diffrent resource key classes.
I'm not sure what the resource key class contains, but it basically should only hold the information on how to load the resource, so wouldn't it be possible to just have one resource key class without the template, which holds that information. Since the resource manager know with which class he's dealing with, he only needs to know how to load the data, meaning which function to call on the template class.
The problem with that idea is that maybe someone would try to load a image with the music manager, since the keys no longer hold the type information.

Yes, I've already thought about this in Thor 1, but I haven't found a clean solution so far. However I'll reflect about it again, thanks for the feedback

Since you want to remove the type from the keys, removing it from the manager won't really work, except moving it to the manager functions, which would produce not so nice function calls mgr.acquire<sf::Texture>(reskey). Althought if you look at them they're very verbose (Manager acquire a texture with the reskey!)...

[Nexus]

Apparently, generic functions like fromFile() are more difficult than thought, as I didn't expect the SFML resource loading functions to have so different signatures

I hoped to provide at least the 3 basic functions to load from a file, stream and memory uniformly, however:

• sf::Music uses openFrom...() (ok, this is easy to hide in the implementation)
  
• sf::Texture has an additional parameter sf::IntRect
  
• sf::Shader has an additional parameter sf::Shader::Type or two equal parameters
  

So I currently tend to go towards the old approach... At the moment I'm experimenting with a class template which is specialized for the single SFML resource classes. Although the difference to independent key classes is not big. I don't know if template is even a good approach, since it suggests a genericity which is not really there...

thor::ResourceKey<sf::Texture> key = thor::Resources::Loader<sf::Texture>::fromFile(...)

On the other side, I don't think non-templated resource keys are a good idea, because you lose type safety. Since load() returns a pointer to the resource, it's better to know the type. I don't like to introduce casts or runtime checks and the corresponding error-proneness because I currently don't see the advantage of type erasure here

[Nexus]

Okay, I have pushed a first draft of the new resource API. Changes:

• Removed ResourcePtr, used std::shared_ptr instead
  
• ResourceManager has now only one template parameter (the resource)
  
• Added ResourceKey class template to specify how to load resources
  
• Added several functions in thor::Resources namespace to load SFML resources
  
• Removed old keys (thor::Resources::TextureKey, ...)

Example:

thor::ResourceManager<sf::Texture> mgr;

std::shared_ptr<sf::Texture> ptr =
    mgr.acquire( thor::Resources::fromFile<sf::Texture>("image.png") );

[MorleyDev]

So each Resource has it's own manager? Huh, different to my approach where I centralised it so a single resource manager can load any resource, even user defined.

Basically stores
-map of loaders for each type
-map of type/object pair for each name.

Internally it stores things as std::shared_ptr<void>. The awesome thing about std::shared_ptr<void> is it still calls the correct destructor.

Internally it then uses some form of templated Type-to-Identifier to determine which loader to use and make sure it's casting things back to the right type. This defaults to either RTTI or a really simple fake RTTI.

Externally a function like template<typename Type> std::shared_ptr<Type> getResource<Type>("filename") is exposed to the user.

Ideally this lets me store all resources in a central location, whilst keeping the end result type safe.

[Nexus]

Thank you! I've already thought about a centralized manager, the thing I had in mind was indeed similar to your approach, namely

std::map< TypeInfo, PointerToTypeErasedBaseClass >

The general resource manager would have the same API as the current one, just that the functions taking resource keys would be templates (for arbitrary keys). Maybe I'll still provide the specialized managers for full type information (they would probably be used internally anyway)... Or do you consider them useless?

Internally it stores things as std::shared_ptr<void>. The awesome thing about std::shared_ptr<void> is it still calls the correct destructor. It uses some form of templated Type-to-Identifier to determine which loader to use and make sure it's casting things back to the right type. This defaults to either RTTI or a really simple fake RTTI.

It doesn't use RTTI. It creates a deleter at initialization, where the dynamic type is known. Using type erasure, it can call it later. I've also implemented this technique in Aurora's CopiedPtr.

[eXpl0it3r]

The general resource manager would have the same API as the current one, just that the functions taking resource keys would be templates (for arbitrary keys). Maybe I'll still provide the specialized managers for full type information (they would probably be used internally anyway)... Or do you consider them useless?

I'd still vote for uniform manager too, because what I now do is packing three managers into one class, since I don't want to hand around three diffrent references to the manager, I now can rather just hand out the reference to this one resource class.

If the overhead of the uniform manager is quite bigger than that of a type specific manager, it would be good to provide the older ones too, otherwise it's kind of unnessesary.