Resource Management Suggestions?
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.
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:
That makes it easier to extend your system to new types of resource.
The basic idea you have sounds fine to me though.
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.
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.
Type safety is your friend.
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.
The ResManager class had methods like "Request()" and "Add()" and such. It was very simple.
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.
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...
I'm not sure I understand this?
WeakReferences/boost?
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?
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.
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.
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.
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!
What is the solution of this problem in C++?? I'm very confused!...
Tnx!
Zuck: you know what type of thing you're loading, so just cast it:
Mesh m = (Mesh)ResourceLoader.Load("mesh", "MyMesh");
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...
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement