More resource management troubles

This is a discussion on More resource management troubles within the Game Programming forums, part of the General Programming Boards category; I've refined my resource management system to use the factory pattern. In the design I opted not to use the ...

  1. #1
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586

    More resource management troubles

    I've refined my resource management system to use the factory pattern. In the design I opted not to use the templated factory pattern and instead am using the parameterized creation pattern.

    Current design:
    • CResource - base class for all resources - resource classes derive from this class to extend resource functionality
    • CResMgr - resource manager class - maintains a cache of most recently used resources
    • ResCreator - creation class for all resources - no resources that can be added to the cache can be instantiated outside of this class
    • Resources are indentified in the cache via a random ID


    There are several problems popping up and I'm not sure of an elegant way to solve them
    • If resources are identified by their ID and their ID is assigned at run-time, how do I account for objects that use the same texture? In the current system the duplicate textures would be assigned unique IDs and would occupy two locations in the cache. Since the IDs are assigned at run-time, a mesh object cannot know the ID of its associated texture and thus cannot know if its texture is already in the cache.
    • The only way to account for user created resources is to override the create function in a class derived from ResCreator.
    • The parameterized solution resolves to a switch inside of ResCreator::Create() and ResCreator::CreateFromFile().
    • Since ResCreator must be able to create all resources yet all resources must only be created from within ResCreator, ResCreator then must be friends of the CResource derived classes. I'm not a huge fan of friend classes but could not figure out another way to do this.


    The first problem could be solved using strings or multiple IDs but I would lose the efficiency of a std::map. Since resources are located by their engine-assigned ID and not by their actual resource ID, attempting to find out if a resource existed in the cache or not would be quite slow.

    Non-negotiables
    • Resources must have a centralized way of being created, destroyed, and added/removed to/from the cache.
    • The cache must maintain most recently requested resources
    • The cache must maintain the requested size, or very close to it.
    • The cache absolutely can never exceed the maximum size.
    • Identical resources should resolve to the same ID.


    To illustrate here is an in-engine example. There is a mesh A that uses texture A that needs to be rendered and/or updated. Since this mesh uses texture A both the A mesh data and the A texture will be in the cache since the mesh class will request these from the cache. If they are not in the cache they will be created and added by the creator class. If another mesh B uses texture A it should ideally use the same texture as mesh A. It will NOT use the same mesh data since this causes a multitude of other issues.

    Any suggestions?

  2. #2
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    How are resources identified in the original Create/CreateFromFile?

    Regarding problem 4, that's exactly what friends are for. I wouldn't worry about it.

    However, regarding problem 2, a creator function registration by resource type ID might be a more extensible solution. In that case, it would be the creator function that needs constructor access.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  3. #3
    Crazy Fool Perspective's Avatar
    Join Date
    Jan 2003
    Location
    Canada
    Posts
    2,640
    If resources are identified by their ID and their ID is assigned at run-time, how do I account for objects that use the same texture? In the current system the duplicate textures would be assigned unique IDs and would occupy two locations in the cache. Since the IDs are assigned at run-time, a mesh object cannot know the ID of its associated texture and thus cannot know if its texture is already in the cache.
    Generate the ID's based on the resource identifier (hash code). Then you don't have to deal with strings and you have unique integer IDs.

  4. #4
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,586
    Generate a hash from the resource identifier...

    I like it. No strings.

    Why do we all hate using strings as identifiers? I don't know why but I despise using them this way and it seems most of us here agree.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    It's slow. When you do lookup using strings, you need to do string comparison, which is O(len(s)).
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Sorting out a resource manager
    By psychopath in forum Game Programming
    Replies: 1
    Last Post: 11-10-2008, 06:12 PM
  2. CreateProcess with Resource of executable, not the Filename
    By Ktulu in forum Windows Programming
    Replies: 4
    Last Post: 11-04-2006, 12:07 AM
  3. Generic Resource_Manager WIP with lots TODO
    By Shamino in forum C++ Programming
    Replies: 19
    Last Post: 02-01-2006, 12:55 AM
  4. Mmk, I give up, lets try your way. (Resource Management)
    By Shamino in forum Game Programming
    Replies: 31
    Last Post: 01-18-2006, 08:54 AM
  5. Serial Communications in C
    By ExDigit in forum Windows Programming
    Replies: 7
    Last Post: 01-09-2002, 09:52 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21