Jump to content
  • Advertisement
Sign in to follow this  
ProgrammerZ

how to implement a resource system

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

Hey guys, I'm programming a simple game engine and I was wondering how to implement a resource system (resources meaning graphics, sounds, meshes, textures, etc). I was thinking of having a resource class and then deriving the sound, mesh, etc. resource classes from it. All resources would be managed by a resource manager class. Also, if the program wanted to use a resource, it would call a resource manager member function to load the resource. The resource manager would check to see if that resource was loaded. If it was, it would return the resource and increment that resource's reference count. Else, it would load the resource and return it. When the program is done with the resource, it calls a resource manager function to release the resource. If the resource reference count is one, the resource is released/deleted. Else, its reference count is decremented by one.
[source lang="cpp]
class Resource
{
private:

    // ctor and dtor
    std::string m_sFilename;

    unsigned m_iRefCount; // how many references this resource has

public:

    void AddRef() {++m_RefCount;}
    void RemoveRef() {m_RefCount = ((m_RefCount == 0) ? 0 : (m_RefCount - 1));}

};

class ResourceManager
{
private:
    // clipped

    std::list<*Resource> m_Resources;
    
public:

    // clipped

    enum {texture, mesh, sound, sprite, etc.};

    Resource* GetResource(std::string filename, int type)
    void DoneWithResource(Resource* resource);

};

Any suggestions? --ProgrammerZ

Share this post


Link to post
Share on other sites
Advertisement
Your resource class is no more than a reference counted pointer. For that it would be much preferable to use shared_ptr

Also since you're using C++ there is no need for a "Manager" class. What exactly do you need to manage? If a client needs a resource it should just instantiate one.

Share this post


Link to post
Share on other sites
Quote:
Original post by fpsgamer
Also since you're using C++ there is no need for a "Manager" class. What exactly do you need to manage? If a client needs a resource it should just instantiate one.


It's not an unreasonable idea. You may want to cache resources (so you don't get to reload the sound file for a shot from disk ten thousand times). When a client needs a resource, it can ask the manager, which will instantiate one for him if an instance doesn't exist, or give a [shared] pointer to an existing one if it's still there. It can keep track of aggregate memory consumption to decide when to destroy some old resource.

Share this post


Link to post
Share on other sites
Few changes coming to mind:

-Change the list in your manager to a map, that way you can use the filename to quickly check if the resource is already loaded (or maybe a trie, if you expect a whole lot of resources, especially with common prefixes)

-Ask yourself, if you _really_ need reference counting or if you don't need your resources in memory all the time anyway. Do you REALLY want to load it again and again, because the only part of the code using the texture is dropping it's reference after using it each frame?

-Unless there is a really good reason, store the resource itself in the map, not a pointer. That way you won't forget to delete them.

-Random thought: don't hand out plain pointers to the resources. Wrap them into transparent constructs with something like an observer pattern. Probably too wasteful, but the easiest way to invalidate all references when unloading a resource... or maybe a second layer of indirection, where you hand out (transparently) pointers to a table containing pointers to the actual resources. These pointers can be adjusted if needed. But both (well, all) ways of validating pointers before use will result in an "if" and I don't like these instruction cache destroying little buggers (not in critical parts of the code at least).

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!