• Advertisement
Sign in to follow this  

Resource Management Suggestions?

This topic is 4171 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

So I'm planning on writing a resource manager for a new project (biggest one I've done yet so I'm trying to make it good from the start). Basically as it stands I plan to have a resource management class that'll store all the mesh data and collision data (mesh data will be in VBO's for openGL, but it'll store the offsets and such). From there I'll have 2 types of objects. AABB and Octree objects. Octree will only be for the terrain stuff, AABB will be for the players and other objects on the map. Past that I'll have a scene manager which will have lists of moving objects (which will all be references to the AABB objects), static objects (also AABB) in order to seperate them for collision purposes and then a list of any terrain objects (incase I seperate them for some reason). The non tree objects will also be stored in a different octree just to keep track of objects on the map. (Not a mesh octree but a object octree). Basically I'm just looking for input whether people think this is a good system or not and if not I'm very open to suggestions on how to change or redo this. Any suggestions are appreciated.

Share this post


Link to post
Share on other sites
Advertisement
My suggestion would be for the resource manager to be completely agnostic of what the resources are – it just stores a collection of loaded resources (std::map<std::string, object> or similar). Actually loading the resources is delegated to 'plugin' classes:
interface ResourceLoader{
object LoadResource(string ResourceName);
}

class ResourceManager {
Hashtable<string, ResourceLoader> loaders;
Hashtable<string, object> resources;
...
void RegisterLoader(string type, ResourceLoader loader){
loaders[type] = loader;
}

object GetResource(string type, string name){
object r = resources[name];
if(r == null) {
r = loaders[type].LoadResource(name);
resources[name] = r;
}
return r;
}
}

class MeshLoader : ResourceLoader {
object LoadResource(string name){
// ... load a mesh
}
}

class Mesh {
// might not be the best place to put this
static MeshLoader loader;
static {
engine.ResourceManager.RegisterLoader(loader = new MeshLoader());
}
}


That makes it easier to extend your system to new types of resource.

The basic idea you have sounds fine to me though.

Share this post


Link to post
Share on other sites
I do a similar plugin style manager, but template/generic the base ResourceManager based on (abstract) return type. [edit: And use WeakReferences/boost::weak_ptrs for the Manager store so that the programmer doesn't need to explicitly deal with the manager to free the resource]

Type safety is your friend.

Share this post


Link to post
Share on other sites
They way I did it was to have a nested map like this:

map <string < map < string, shared_ptr<Resource> > > resMap;

Resources are added by type, which is determined by using the Type function implemented from the Resource interface.


class Graphic : public Resource
{
public:
virtual string Type() { return "Graphic"; }
};


The ResManager class had methods like "Request()" and "Add()" and such. It was very simple.

Share this post


Link to post
Share on other sites
I am using templates for the resource manager but I didn't think it was really necessary to list that.

But Bob, I like the idea of using the hash tables... I was going with straight linked lists at first. Been a while since I've coded, that'll be useful.

But...
Quote:
Original post by Telastyn
[edit: And use WeakReferences/boost::weak_ptrs for the Manager store so that the programmer doesn't need to explicitly deal with the manager to free the resource]

I'm not sure I understand this?
WeakReferences/boost?

Share this post


Link to post
Share on other sites
boost is a set of c++ libraries, primary of which is a set of smart pointers. One of those is weak_ptr, which shares a common pointer with shared_ptr's, but bestows no ownership. Thus when the shared_ptrs are all destroyed, the resource itself is destroyed. This allows the programmer to interact less with the manager. Less interaction means less design consideration needed; less chance of mistake...

If you used a shared_ptr (like in drakkcon's example), the resources would always stay loaded, even when the manager is the only thing referring to them.

A WeakReference is the .NET equivalent.

Share this post


Link to post
Share on other sites
That's a good point about weak references. I was kind of working on a small-level model where the resource manager clears itself at the break between levels (so everything gets flushed anyway), but you're right, for any sort of continuous world a weak-reference resource manager is probably better.

Share this post


Link to post
Share on other sites
Sorry for my question but...If we have an abstract object class like "IResource" ("object" in the Bob Janova's code) and we use a pointer of this class as returned value in "getResource(...)", than advanced methods of derived classes are not accessible from the "IResource" pointer without an external cast to the right derived class!

What is the solution of this problem in C++?? I'm very confused!...

Tnx!

Share this post


Link to post
Share on other sites
Yes, i know, but i think that is a very poor method to resolve the problem so this solution, in my opinion, is not a good OOP design...

Share this post


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

  • Advertisement