• Advertisement
Sign in to follow this  

Managing assets

This topic is 4704 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Alright, what I have right now is a CTextureManager, which handles loading textures, keeping them in a texture list, etc... it works great. I also have a CModel class, and I am going to have to have a manager for that as well, to make sure I don't load the same model 40 times. Now, when I get to sound, I'm going to have to do the same thing. My question is, would it be more beneficial do have seperate managers for each one? Or should they all be incorporated into one CAssetManager class? I can see benefits to both methods of doing it. CAssetManager would be simple to use on the outside, but really messy on the inside. If I did them seperately, I could mess with them seperately, in case they need to be managed differently, and might make debugging a bit easier. Any input or advice? I'm not an uberprogrammer, so lets try to be a bit basic and not through out polymorphism options and things like that, if possible, heh. I'm not sucky, but not rad either. Any help is greatly appreciated.

Share this post


Link to post
Share on other sites
Advertisement
I'd either make the manager templated, or I'd explicitly make each one since there's not so many. Since you say you're not so experienced, and loading resources is pretty vital, I'd suggest just taking the time to impliment each one.

Share this post


Link to post
Share on other sites
I would create a templated asset manager. std::map or std::hash_map makes managing this pretty easy for the simple cases. You probably also want a shared_ptr or ref-counted pointer class to manage lifetime of the assets.

Beware case sensitive string compares on non-case-sensitive file systems, though -- you might want to lowercase all names/paths that come into the asset manager (and do the same to your asset file names).

Share this post


Link to post
Share on other sites
But what is the need of making a templated base manager or whatever? I'm not writing Half-Life 3. I'm making a small game, i'm the only programmer. Spending all my time writing complex managers will do me no good, and will keep me from making the game.

I'm not trying to write something that will be 100% versatile no matter where I use it. My scope for this game is minimal. Again, it's not half-life 3.

So, that being said, any other suggestions? Remember, im trying to be simple with this, templated base managers seem to be overkill for this project.

Share this post


Link to post
Share on other sites
Consider the scope of your project and code accordingly. You can do it any way you like, and you seem to have a good grip on the benefits and shortcomings of either method. If it's a small game there's no harm in keeping things seperate and somewhat hardcoded. By then end of the project you'll have encountered the problems you'll want to solve next time around.

Share this post


Link to post
Share on other sites
You know what, i encountered this exact same problem and put an end to it a few days ago.

In the past i had a MeshManager, TextureManager. At that time i realised that i was rewriting the asset management part for these 2 managers. But since i was lazy and short of time, i said it's only 2 Managers, it won't be worth rewriting. Then came a MaterialManager which loads Materials. In the future when i implement shaders, there will be a ShaderManager, then a SoundManager and a Manager for any resource which can be used by more than 1 entity.

Since i have a couple of weeks of leave, i finally did something about it. It took barely and hour to get everything done.

First, I made, Textures/Meshes/Material classes inherit from a Resource class.


class Resource
{
Resource()
{
ResourceManager::getResourceManager().addResource(this);
};
String filename;
int ref;
}

//same for meshes/materials.
class Texture: public Resource
{
....
};

/*
This only took 5 mins.
Now the Manager part. I removed all the individual managers from the project. and did this. Tada, any class which inherits from Resource will be automatically added and managed by ResourceManager upon creation.
*/

class ResourceManager
{
void addResource(Resource* r);
std::list<Resource*> resources;
}

Share this post


Link to post
Share on other sites
Thanks gamer, that helped. That's about the kind of system I need. I think I will implement something like that, thanks a bunch.

Share this post


Link to post
Share on other sites
One more point i forgot. I moved all the resource-file loading code from individual managers into the class itself as a static function.

class Texture : public Resource
{
static Texture* loadFromFile(String filename);
}

In this way the file loading routines are abstracted away from the ResourceManager. So it is possible for anyone to make their own Resource type without having access to the code of Resource/ResourceManager.

Also, to check if a resource is already loaded, you could add a function to do this in the ResourceManager.

class ResourceManager
{
//returns a resource if it already is loaded, else returns 0
Resource* isResourceLoaded(String name);
}

in your Texture.cpp,

Texture* Texture::loadFromFile(String filename)
{
Texture* t = isResourceLoaded(filename);
if(t)
{
return t;
}
else
{
load the resource from file.
}
}

Share this post


Link to post
Share on other sites
Well that's how i prefer to do it. Because i find file loading a utility function. Main reason being that previously the TextureManager used to do the same thing, it returned a Texture* object. In this way i could just copy the entire function and not have to make changes to anything other than the function definition.

Static
Texture* t = Texture::loadFromFile("face.jpg");

as opposed to
Non-Static
Texture* t = new Texture();
t->loadFromFile("face.jpg");

It makes little difference if it is static or not.

Share this post


Link to post
Share on other sites
Oh, sweet, I see. Thanks :D You've been a big help, much appreciated.

Share this post


Link to post
Share on other sites
In my case, I haven't written anything like that. I also say thanks for the ideas. I've always just hard loaded into the arrays in an Init function. Probably reminds you of NEHEs tutorials.

Share this post


Link to post
Share on other sites
For my last project I chose to go with a single manager for all resources.

A few benefits to come out of this:

-- Avoid duplicating code
No new code for new types of resources

-- All resources are loaded through resource loader plugins
With a single resource manager, there's only 1 place to register these

-- Search paths
The resource manager takes care of managing search paths and virtual drives.
This is really part of avoiding duplicated code, but has some nice side effects:
Resources loaded recursively will now always be searched for in their "parent" search directory. For instance you'd have Textures loaded from Materials loaded From Meshes loaded from.. and so on. This way resources within resources can always specify their path relative.


How I went about this
I have a ResourceManager class, which acts as an access point for resource to the application. This is where you create, load, destroy resource, create drives and search paths, etc.
Then, the resource manager has several instances of the ResourceGroup class.
This is the class that actually holds resources, but only of a specified type (my resource types are hashed from strings, but that's beside the point). ResourceGroups are created when a ResourceLoader for loading a specific resource type is plugged into the ResourceManager.
Now, creation, loading, and destroying of resources are forwarded onto the ResourceGroup, depending on the type of resource you're creating (this is from templated methods in the ResourceManager class), while drives and search paths are kept sentral in the main manager.

That was my approach so far anyway, hope it might be of some help, or give you some ideas.

Good luck with your project!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement