Thread: Resource manager tree

The concept seems sound, but you are re-implementing a lot of tree and list functionality that you don't need to re-implement.

How so? I'm not doing anything with the STL map except generating unique IDs. The linked list portion amounts to a couple of pointer swaps. I don't see how this is reinventing the wheel. The STL did not provide the data structure I needed and so I merged two and created my own.

I re-coded the system to use DWORD IDs. I just simply reset the ID to the new ID if the resource must be re-created.

I do appreciate the work you put into the explanation and code though. Resource management is fairly complex but I feel my solution has some usefulness. Either way I think either of our solutions will work far better than trying to cram everything into memory at load time.

Ok but gimme some credit here for evaluating the issue and designing my own.

I really suck at asking questions in english =P

I try again...

What is the return valu of sizeof(DWORD) and sizeof(CResource *) on your plattform? It can't be any space saving to chose one or the other...

It seems like you are wasting a lot of time searching for unique identifiers when you already have one at hand, i.e. the CResource pointer, which is an unique identifier...therefore you should't really need any random-code to make an unique identifier (observe that even if you use a perfect random number generator you don't get uniqness, only randomness, think of a 6 sided dice for example).

Instead, do some bit-swizzling to remove apperent ordering of the index, that is cheap and should work ok.

The suggested boost implementation looked nice too, but that adds external dependencies instead of course.

And I hope you post the finished code.

/f

The CResource pointer is not a unique indentifier.

Even if it currently isn't in your implementation, it definitely could be. Allocate a thin proxy object and the pointer to the object is unique.

But my main point was the random generator stuff, you don't need it. You just need an increasing index (or the above pointer) that you move around the bits of to get performance out of your tree, that way you have all the uniqueness you need for your index, guaranteed no duplicates, without all that code that still don't get you unique identifiers.

I'm obviously not able to get my attempt of subtle hinting of no difference of memory usage regarding DWORD and CResource* across so I'll just drop it, it's not like it's important anyway nowdays. I'm still used to thinking about saving a byte here and there in structs... =)

Did you have performance problems with your resources or did you add the resource manager just in case? On modern computers I have always let the driver take care of texture loading myself, it's usually no problems at all.
As I understand it you don't do any pre-use loading to avoid stuttering when it's needed in the scene, only chosing which texture is LRU, something that to my knowledge the graphics drivers already takes care of (OpenGL on linux at least).

Keep coding, it's always fun to see what you're up to with your game, not so many here do as much progress as you =)

/f

How would I go about implementing this data structure using both a std::map and a std::list?

I would need pointers into the list correct?

Code:

struct STLListNode
{
  CResource *pResource;
  
  //For the linked list
  STLListNode *pNext;
  STLListNode *pPrev;
};

std::map<DWORD, STLListNode *> Resources;