Back to General and Gameplay Programming

Designing a Resource Manager Framework

nicba · 2003-02-11T13:50:14

Last night I just lost my whole library of loader classes by accident, texture loaders, material loaders, mesh loaders ect. Instead of just sitting down and coding them all up again as they were, I thought I would make things a bit interesting by designing myself a proper resource management framework (not that I actually need such a monster for the small games I write, but it''ll be more fun than just re-doing my ball of mud!). Here''s some of the things I have thought of until now: 1) A couple of different ResourceManagers, which can be assembled into a composite structure (the pattern). So I have a global ResourceManager to retrieve my resources from in-game, but also access to different sub-managers for configuring specific things about certain kind of resources. For example a TextureManager that lets me set the filtering method (mipmapped ect.) on the textures to be loaded. 2) This setup would even allow me to attach different strategies to the different managers for implementing various memory-management/disk swapping algorithms for each kind of resource (by use of the strategy pattern). I would like to separate the management of the resources from the actual loading of them. Also, I would like the framework to be extensible enough to load resources from .res files included in the .exe (screensavers), plain from the file system and from archive files (ex.: .zip). I like my resource loading code to receive just a stream (any kind of stream) and parse that into the requested resource type "transparently." My question is how to accomplish this best. I''m not sure how I ought to divide the responsibility among my classes. In my first solution I have two kinds of classes: ResourceManagers and Resources. The resource managers derive from AbstractResourceManager and the resources derive from AbstractResource. The inheritance hierachy for resources is three levels deep. For example I could have a concrete TGATexture, which derives from an abstract Texture type, which in turn derives from the AbstractResource class. My resource managers should be flexible with regards to supported file formats, so instead of hardcoding them to operate with the concrete resource classes, they only know about the abstract types at compile time. At run-time one should be able to register support for different file formats by passing references to the concrete classes to the managers. Ex: ATextureManger = new(TextureManager); ATextureManager.registerFileType(TGATexture); ATextureManager.registerFileType(BMPTexture); .... When the game requests a resource from a resource manager, it should attempt to load it by querying all its registered file types classes for one capable of handling it, in a Chian-of-Responsibility like fashion. A TGATexture class would thus know how to handle a ''.tga'' file type and respond to this. By consequence, each concrete resource type should therefore know how to load/unload the resource from memory, using their choosen file format. A TGATexture might therefore have an interface like the following: class TGATexture : Texture { load(stream); // Load a ''.tga'' file into a Texture structure unload(); // Unload the texture (temporarily) from mem. } Where the stream is opened by a resource manager to that managers respective repository (a file in a specific directory, in a .zip file ect.). There is, however, at least one problem with this approach to resource loading. Tying the the loading of resources directly to subclasses of the abstract resource types, such as with the TGATexture subclass, creates a one-to-one mapping between resource types and files (that is, there is an abstract resource type Texture and one or more concrete implementations that fills Texture with data). The problem arrives with "library" files, as the .mtl files used to store materials for a wavefront .obj model. A .mtl file does not correspond directly to a material, so we can''t have a Material type with a MTLMaterial subclass loading from a .mtl file. The .ntl files contains a collection of materials. Therefore, in order to support these files it would be necessary to define a new resource type, a MaterialLibrary resource. This resource, I feel, would be kind of articficial. The rest of the game/application does not care about material libraries. It cares only about a single material at a time, when its going to render it on a face. Maybe a viable alternative is to have not two but three kinds of classes: ResourceManagers, Resources and Loaders. That is, to split the loading code out in its own class hierachy. There would only be a few kinds of resources: AbstractResource, TextureResource, MaterialResource, MeshResource and AudioResource, for example. And these would all be entirely passive, only storing the data put into them. Instead of registering file types with the resource managers, one would register Loaders. For example there would be a only one TextureResource class, but more loaders: TGATextureLoader, BMPTextureLoader ect. Loaders would be a kind of factory classes, hiding the complexity of instantiating and loading a resource from a file (or a stream, rather). But they would be very thightly coupled to the resource classes storing the textures, materials or whatever. I kind of like the conceptual picture: ResourceMangers in which you registers Loaders for different file format, which in turn instantiates and loads resource for the managers. But then again its another, separate class hierachy. That model would also mean an increase in complexity. I can''t decide which approach I like best.... Any of you done anything like this before? Comments, feedback, tips and ideas are very much welcome. Regards Nicolai

General and Gameplay Programming Programming

Started by nicba February 01, 2003 11:07 AM

14 comments, last by nicba 21 years, 2 months ago

Shannon Barber

1,684

February 06, 2003 07:54 PM

It''s not at all impossible to have the same resource manager manage the audio, animation, meshes, textures, etc...

With Java you could just use multiple interfaces.

Essentially, all the resource manager does is accept a moniker and produce a concrete object that supports the IResource interface. Whatever request the resource, ought to know what type of resource it is requesting. A dynamic cast will be performed from the IResource to the ITexture, or IAnimation, etc... interface. (In C++ you could use a static cast for most scenarios.) The classic COM name for this interface is IPersistStream.

If the resource manager is responible for loading the items off disk, it makes sense to use one for all resource types. It would be the RM''s job to read the header/index of some wad files, search the index for the moniker token, then load and decompress the data. For all resources this process is the same. To even have multiple objects of the same resource class will result in a duplication of the index in memory, or at the least loading the index multiple times.

To use mutliple interfaces in Delphi, you have to make COM objects. It will perform the "dynamic cast" through the QueryInterface method for you, if you just assign a pointer of one interface to another.

- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara

Anonymous

February 08, 2003 04:00 PM

quote:I wouldn''t use inheritance like AP suggested. [...]

In fact my suggestion is a generic RSM (resource storage manager). It only handles id giving, ref counting, and access. Your loader asks the RSM to return a space, take the id and use the id to access the data from the RSM. So your RSM is sort of a global singeleton (doesn''t have to be a singleton).

For even greater reusability, you parameterise the storage type in the RSM, but all these requires C++ template.

as i said, i wanted to provide a perspective, not suggest a design. i like your RSM-concept. one question though:
when using templates to parameterise the storage did you mean using a concept like "policy classes"?

  struct ZipAccessPolicy { ... }struct DiskAccessPolicy { ... }template <class AccessPolicy = DiskAccessPolicy>class ResourceManager : private AccessPolicy{ ... };

if so, wouldn''t the only difference between using inheritance and templates be the kind of polymorphism (run-time vs. compile-time)?

Void

126

February 09, 2003 12:21 PM

No, there is no concept of DiskAccess in the RSM.

  // Resource ID manager with ref counting, blahtemplate <class Param>  class ResourceMangaer{   std::vector<Param> p_;   // a list of the resourcepublic:  typdef int ID;   // id for accessing  ID  Create();  Param& Access( ID id ) const;};class SurfaceData;class AnimatationData;class SoundData;// imagine global singletong availabletypedef ResourceManager<SurfaceData>   SurfaceRM;typedef ResourceManager<AnimationData> AnimRM;typedef ResourceManager<SoundData>     SoundRM;// Higher level loaders.void LoadBMP( ifstream &is ){   SurfaceRM::ID id = SurfaceRM_.Create();   SurfaceData &data = SurfaceRM_.Access(id);   // parse bmp}void LoadJPG( ifstream &is ){   SurfaceRM::ID id = SurfaceRM_.Create();   SurfaceData &data = SurfaceRM_.Access(id);   // parse jpg}

Anonymous

February 09, 2003 01:25 PM

ok, then i misunderstood what you meant by "storage type". i thought you were referring to the actual location.

it seems to me as if you didn''t really address the problem of
resource location but instead provided a solution to
the problem of where to store the loaded data...

how does your design handle the requested independency of
resource location (zip, hd, exe)?

if you wanted to accomplish it by using iostreams wouldn''t it be better to use istream& instead of ifstream& ?
and wouldn''t you need to use inheritance again?

(please note that english is not my first language and keep that in mind when interpreting the "tone" of my reply.)

Void

126

February 10, 2003 10:06 PM

quote:Original post by Anonymous Poster
how does your design handle the requested independency of
resource location (zip, hd, exe)?

if you wanted to accomplish it by using iostreams wouldn''t it be better to use istream& instead of ifstream& ?
and wouldn''t you need to use inheritance again?

Yes. You are rite. It should be istream. My bad.

Bascially, the code for parsing specific file format as just in a function. I have not worked with .zip files before but I assume you can get the data in a stream of bytes. In that case, you subclass istream to read a zip file in a stream format using operator >> like ifstream. Similarly for resource loading in exe.

Your zip_stream, exe_stream and file parsers can be reused in a mix and match way. Yes, there is inheritance but in this way the loading and where they are located are loosely coupled.

nicba

122

Author

February 11, 2003 01:50 PM

quote:
Bascially, the code for parsing specific file format as just in a function.

But by making the code for parsing a specific file format just a function, like in the code above, isn''t you turning the pyramid upside down?

If the loader functions is the "upper layer" that the client needs to access when loading resources, then it would require the client to duplicate code for determinding precisly what fileformat it is about to load, everywhere the application happens to load something. Everywhere the application loads a texture/image it must use an ''if...then...else...'' statement to find out wether to call LadBMP or LoadJPEG. I would rather abstract that by hiding that descision inside a single Load method of the resource manager. The resource manager may then call the appropiate Load function for the client, instead of the other way around. Also makes it easier to add/remove support for new formats, I would think.

quote:
Your zip_stream, exe_stream and file parsers can be reused in a mix and match way. Yes, there is inheritance but in this way the loading and where they are located are loosely coupled.

Yes, that was my thought also. But still, it might be a good idea to encapsulate the actual streams inside the DataAccessStrategy suggested by AP. It would make it easier to pre-configure the location of the resources once and for all. For example it would allow you to do something like the following:

  void initResourceManager() {  ZipAccessStrategy zip = new ZipAccessStrategy();  zip.addResourceLocation(./resources/tiles.zip);  zip.addResourceLocation(./resources/objecttextures.zip);  ...  resourceManager.setDataAccessStrategy(zip);  ...}void ResourceManager::Load(filename) {  // Open the file from one of the pre-configured locations...  stream = this.getDataAccessStrategy().open(filename);  if fileExtension(filename) = ''.bmp'' {    LoadBMP(stream);  }  else if...}

I think that would have been a bit harder if you restricted yourself to work only with the stream interface. A stream would typically be instantiated only right before data is to be read, and destroyed when finished. So there wouldn''t be much possibility of setting it up and configuring it.

Designing a Resource Manager Framework

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Designing a Resource Manager Framework

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines