Sign in to follow this  
GhostAce

Multiple resource manager

Recommended Posts

Hi, I posted this on flipcode but nobody seems to reply. Here is goes: -------- I am writing a small game engine and have problems with multiple resources. At the beginning there were only meshes and textures in my project. Now I have materials, skins, shaders etc. For every resource I have separate singleton manager. It is getting boring to add new managers for every new resource type and I have a feeling that it is not a good practice. I think it would be better to have one resource manager for all types of resources. So my question is: what is the best method to organize resource managment - every resource type with its own manager or one multi resource manager? And if the second one - how to design the manager ... ? -------- I hope that is not considered spamming. Thx for all replies.

Share this post


Link to post
Share on other sites
I too have several resources in my engine: textures, models, patterns for displaying, etc.

I ended up having one templated manager, and I'm just instantiating it every time. I only got to write a class handling specific loading/releasing routines for each resource type.

You may have consider putting the instantiated managers in some kind of namespace, or even write a general keeper-class for your managers, with one function for releasing. But for acquiring a resource of a certain type, you'd have to write a spcific function every time, so I think it's the same amount of work no matter what, :(

So templates saved the day. Again.

Cheers.
/def

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
This pertains more to C than C++. I found myself duplicating a lot of code when creating new resource types. So I converted the major chunks to macros which take the mutable areas of the code through the parameter list. This simplified the generation of new resource types to code as simple as this:

#include "impl.h"
res_read_IMPL(mesh, res_read_mesh_3ds, res_read_mesh_ase)

Of course, this means debugging large macros, so you'd want to be sure the code is bulletproof before you macroize it.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this