Thor C++ Library – An SFML extension

[Nexus]

It is possible to not throw an exception during the load of a resource if its extention is not supported ?

Yes, take a look at ResourceManager::SetLoadingFailureStrategy().

Another request.
Is that possible you give an minimal code to implement custom ressource to be integrated by Thor ressource manager ?

Sure.

Code: [Select]

// --------------------------------------------------------------------------------------------------------------
// Given: An API for a custom resource, e.g. 3D Mesh

// Custom resource class
class Mesh {};

// Factory function returning a pointer to the resource
Mesh* CreateMesh(std::string filename)
{
return new Mesh(...);
}

Code: [Select]

// --------------------------------------------------------------------------------------------------------------
// Your part: Write a resource key
#include <Thor/Resources.hpp>

// Resource key class, stores information for loading
class FileLoader
{
typedef thor::MovedPtr<Mesh, thor::NoCopy> Ptr;
std::string filename;

public:
FileLoader(std::string filename)
: filename(filename)
{
}

// Function that actually loads the resource
Ptr Load() const
{
return Ptr( CreateMesh(filename) );
}

// Less-than operator as global function to compare two keys
// Here, it just compares the filenames
friend bool operator< (const FileLoader& lhs, const FileLoader& rhs)
{
return lhs.filename < rhs.filename;
}
};

Code: [Select]

// --------------------------------------------------------------------------------------------------------------
// Use it
int main()
{
// Create the resource manager
thor::ResourceManager<Mesh, FileLoader> mgr;

// Acquire resources (note that a and c acquire same resource, since keys are equal)
thor::ResourcePtr<Mesh> a = mgr.Acquire( FileLoader("first.mesh") );
thor::ResourcePtr<Mesh> b = mgr.Acquire( FileLoader("second.mesh") );
thor::ResourcePtr<Mesh> c = mgr.Acquire( FileLoader("first.mesh") );

// That's why the smart pointers a and c refer to only 1 resource, in total 2 resources have been loaded
assert(a == c);

}
Note that I don't really like thor::ResourcePtr, and even less I like thor::MovedPtr. I realized that the current smart pointers in Thor are far too complicated, yet not flexible enough. This is going to be simplified a lot in the near future, see also some posts earlier where I explained all the changes I've planned.

Finally, I would like to have your opinion about the singleton in the management of resources. Currently I use this pattern that I don't love so much, but I would like to know if you've got another approach.

Generally, I'm not a big fan of global variables and singletons, I've already written something about it here. If possible, you should prefer keeping thor::ResourceManager in a dedicated class and passing around thor::ResourcePtr instances.

[Hubert]

Hi,

Thank you for your answer !

Shame on me ! I've seen the enum thor::Resources::LoadingFailureStrategy
when I read the tutorial concerning the ressource management.

Actually, I think that I don't see your point about the Singleton. I've the same opinion about this "trick" overused but I don't see how you would implement your solution.

[Nexus]

I've the same opinion about this "trick" overused but I don't see how you would implement your solution.

Well, resources needn't be everywhere. It's enough to have them in the places where the SFML frontend classes (like sf::Sprite, sf::Text, sf::Sound) are used. And normally, these places aren't spread over your whole project, rather in a few classes, which have access to the resources.

In one project, I use two big classes for rendering and playing audio. I pass the ResourceManager to them by reference in their constructor, so they can later acquire texture/sound resources on demand. For this, the access to the resources doesn't have to be global. That's just one example, there are many possibilities.

And I have only tried out very few, that's why I'm still happy about feedback concerning usability.

[Nexus]

As Laurent pushed the new naming convention, I can now begin to adapt Thor.

I plan to release Thor 1.1 compatible to CamelCase functions for people still using the old convention. So if there's anything important for this version, tell me now

New features and bigger API changes won't be implemented in 1.1, they're planned for the next version (probably Thor 2.0, as it will break backwards-compatibility in several places). Again, don't hesitate to express ideas, especially concerning the improvement of existing features (new ones can still be added later). Thank you!

[eXpl0it3r]

As Laurent pushed the new naming convention, I can now begin to adapt Thor.

Go for it! :-P
I checked the SVN repository if you've updated Thor already, before I saw this post, just because I know how fast you were at other times. ^^

I plan to release Thor 1.1 compatible to CamelCase functions for people still using the old convention.

Hmmm I don't know if this makes much sense... I mean people using SFML 2.0 now have to change to lowerCase functions anyway, why not just adapt Thor too?

New features and bigger API changes won't be implemented in 1.1, they're planned for the next version.

Is there more info about when it will be comming? And dare you give me the 'soon' answer!

What do you think about this, are you annoyed of ResourcePtr? Should I use shared_ptr instead, or something completely different to hold the textures?

Yes I'm kinda annoyed by the ResourcePtr too and I think just using std::shared_ptr should work (or std::tr1::shared_ptr).

[Nexus]

Hmmm I don't know if this makes much sense... I mean people using SFML 2.0 now have to change to lowerCase functions anyway

That's true, but I thought there might still be a few people who are content with the current convention or have huge projects depending on it which don't pay out to be adapted. Additionally, I'm not sure how much longer the SVN repository will exist, so a finished version might be ok. Having only Thor 1.0 as a release is not so good, as many things have been improved since then.

I reflect about switching to GitHub, however I have quite few experience with Git and mainly use GUI clients. Also, some features of GitHub don't please me (like the issue tracker where one cannot delete tickets, or no edits are marked).

Is there more info about when it will be comming? And dare you give me the 'soon' answer!

If I've found a hoster for version control and installed everything, I can directly begin to commit (or push) changes. The refactoring itself shouldn't take much time (hopefully I can perform it this or next week), it's rather the other changes (split of some features, some API modifications). However they can be gradually adapted.

Yes I'm kinda annoyed by the ResourcePtr too and I think just using std::shared_ptr should work (or std::tr1::shared_ptr).

Thanks! Finally a user statement

[BlueMagic]

If I were to suggest features, they would be (in order of importance to me):

-Z Buffer: Only trouble I see in SFML. As someone who is trying to develop a top down game, I find that the method I'm using to sort depth (which is basically to order the list of entities by y position) is quite slow for a decent number of objects. I'm guessing this would be much faster.

-Initial rotation of the particles: There's that workaround you mentioned about rotating the emission zone, but it would be good to have an initial rotation so we can achieve better 'randomness'.

-I guess simplifying the ptr situation to using just std::shared_ptr would be nice too.

Let me know if you are planning to implement any of this because it would help me immensely!

[Nexus]

I have already planned all the three points

Concerning the initial particle rotation, I'm not sure how to provide it in the API. Originally, I thought one could unify everything to use transforms (sf::Transform). However, it has some disadvantages: The user cannot extract rotation/scale, and applying a generic transform for a time interval dt is complicated and slow.

So probably, there will just be a DirectionalEmitter::setParticleRotation() method.

[BlueMagic]

Amazing news then!
I'll make sure to follow the development closely. Thanks and let us know if we can help you with feedback or whatever.

[GamingGod]

Greetings.

I'm trying to compile using VS 2010 compiler and CMake, but this bug occurs :

Code: [Select]

CMake Error at CMakeLists.txt:92 (message):
  SFML directory not found.  Set SFMLDIR to SFML's top-level path (containing
  "include" and "lib" directories).

My SFMLDIR in CMake is valid, but when I'm trying to setup valid path for SFML_DIR (then I press generate) it keeps changing to SFML_DIR-NOTFOUND and I can't generate with CMake. Any ideas?

PS. If someone has latest Thor compiled with VS 2010, please upload it somewhere. Thanks in advance.

[Nexus]

SFML_DIR

You should just change SFMLDIR (without the underscore). It seems like XY_DIR is the usual CMake convention, maybe Laurent should add an underscore to the variable to reduce confusion...

PS. If someone has latest Thor compiled with VS 2010, please upload it somewhere. Thanks in advance.

Just a few hours ago I released version 1.1, you can find the binaries on my homepage

[Laurent]

Where does this SFML_DIR come from?

[Nexus]

Where does this SFML_DIR come from?

Now that I looked again at the advanced variable list, I saw SFML_DIR is not there. But it's not the first time I hear of this variable, probably because CMake error messages contain it, like here.

[Laurent]

That's right, I remember now.

If SFML_DIR was defined, CMake would expect it to contain the path to a SFMLConfig.cmake configuration file. Configuration files are another way of handling external libraries; SFML doesn't use it.

So what I should do instead is to rename my own variable to a totally different name, like SFML_ROOT.

[GamingGod]

Thank you good Sirs.

PS. Where I can find the 1.1 binaries? I can see only 1.0.