Resource handle responsibilities

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • Resource handle responsibilities

      Should a resource handle simply be a piece of data or should it have functions to manipulate the data. If the class can manipulate its data than it is more encapsulated but it may have too many responsibilities. If the class is essentially a C struct then it is less encapsulated but has less responsibility.

      For example, should a handle to mesh have a function to render itself or should some other class do that?
    • It depends on what you mean by resource handle and how you plan on using it. I'd need to know more about your architecture.

      If I remember correctly, in Game Coding Complete, the ResHandle class from Game Coding Complete is more like a proxy for the resource. It manages the relationship between the resource and the resource cache and it's on you to grab the actual resource and manipulate it. If your system mirrors this, I wouldn't add resource-specific functions here. I would make the caller get the resource, cast it to the correct resource subclass, and then call functions specific to that resource.

      In my own engine, I have a ResourceId, which is a pooled string representing the path within the resource package. It's effectively a wrapper around a pointer to a string, so there aren't any functions involved (except Get(), which returns the dereferenced string).

      I also have a ResourceProxy class, which is closer to the ResHandle class from Game Coding Complete.

      If you want to give a more detailed description of your resource system, I can give you a better answer.

      -Rez
    • I'm honoured to be speaking with the one and only Rez!

      My resource cache is similar to the one described in the book but not quite the same.

      A Resource::ID represents a file. It holds the path and a precomputed hash of the string.

      The Resource::Cache has a get method which returns a const Resource::Handle given a Resource::ID.

      A Resource::Handle holds the size of the allocation. It doesn't matter where the memory is. The handle just stores its size. The loader for the resource is responsible for setting this size. Classes derived from Resource::Handle hold the actual resource. For example, the TextureOpenGL handle holds the ID of the texture and the TextureOpenGL loader sets the size of the handle to the size of the texture.

      A Resource::Loader has a virual load method that takes a Resource::ID and returns a const Resource::Handle. It also has a virtual canLoad method that takes a file extension and returns a bool. (I'm thinking of changing this to a method that returns a vector of file extensions and the cache performs the comparison)

      So should a MeshOpenGL have some getters for the buffer IDs and have some other class render the mesh or should it have a render function which handles the rendering?
    • Kerndog73 wrote:

      I'm honoured to be speaking with the one and only Rez!

      Thanks man! There's nothing special about me, I've just been doing this for a long time. ;)


      So should a MeshOpenGL have some getters for the buffer IDs and have some other class render the mesh or should it have a render function which handles the rendering?


      It sounds like you ResourceHandle class acts like my Resource class. It's a base class where the subclasses define the actual resources themselves. In this case, the handle's entire job is to manage the resource, so I wouldn't have it do any rendering. I would have the MeshOpenGL rendering happen in another class that takes in a const MeshOpenGL&.

      That having been said, it is a bit of a gray area. For example, in my own system, the ScriptResource DOES have a Run() function, which causes the Lua script to execute. This is an exception though and most of my resources have getters that are called by other systems to get the raw resource.

      Hope that helps!

      -Rez