More Resource Cache Questions

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

    • More Resource Cache Questions

      So, I have been thinking a little more about the resource cache. It seems like it is more of a disk cache, ie to keep the files in memory so the disk is accessed less. This is fine, but isn't there another side to resource management?

      What about if you have loaded a texture and created a texture object and then that texture is used again by another model. Your solution means that the texture would not need to be read from disk again which is great, but don't you need some way of sharing the actual texture object that was created too. Otherwise you will have two seperate texture objects when only one could be shared by both models.

      Does this mean you need a resource cache, and also some kind of texture manager (or mesh manager too), to be able to re-use and not duplicate already created objects and associated buffers?

      Couldn't you take this resource cache further and make the resource cache the actual created objects rather than just the file itself? Is there a pitfall to this scheme?

      Thanks again for any insight.

      The post was edited 2 times, last by Raeldor ().

    • RE: More Resource Cache Questions

      There are as many ways to manage resources in a gae as there are games. A resource manager is like a memory manager: there is no such thing as the perfect one. There is only what's right for the specific game you're working on. Every game I've worked on used something different.

      In general, you'll want to share the texture data between objects. This goes for pretty much all resources, including sound, animations, etc.

      In Rat Race, there is a huge ClumpHolder class that manages anything and everything regarding the visual component of a complex object. This class holds a pointer to a CResource object, which is managed elseware in the system. Basically, no one outside the resource manager should care at all about where the resource truly lives. One possibility would be to use resource ID's so when someone needs to actually access the data bits, they get a valid pointer from the resource manager, which may or may not have to load it from the hard drive. Just like the manager in Mike's book, you basically lock it, use it, then unlock it. Multiple objects (like the ClumpHolder objects in Rat race) can point to the exact same resources by using the same ID.

      Hope that helps.

      -Rez

    • RE: More Resource Cache Questions

      Thanks for the reply.

      I think my basic question is, in the book the resource cache loads the resource as a binary block, but doesn't create a C++ object class for it. So, then you have to create the class (say a Texture class) which has a pointer to say a DirectX texture object that it creates and populates with the data. Now you have duplication... the resource cache still has the binary block but the texture object also contains the same data.

      Why not just have the resource cache create the objects (eg Texture object) rather than just having a binary block?

    • RE: More Resource Cache Questions

      That takes processor time. The point of a resource cache is to get in grab as big of a chunk of data as possible and get out (maybe decompress it). You can move and pointer the data around all you want once it's in memory and when you have alittle bit extra processor time.

      I suposs If you wanted to make a builder class and put it into your resource cache system you could request a chunk of data and just have the system send it to you in the structure you want it in but your still not doing that hwne you get the data you're doing it after the fact.
      .Code
      push you ; haha!

    • So, can you confirm that the data is duplicated? Once in the resource cache, and once in the object it belongs to?

      Or does the resource cache load directly into an object belonging to the renderer (ie, load directly into and create a directx texture object).

      The post was edited 2 times, last by Raeldor ().

    • In the best case, the data should NEVER be duplicated, ever.
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • Originally posted by mrmike
      In the best case, the data should NEVER be duplicated, ever.


      Yet in the book you suggest using the DirectX FromFileInMemory function, which seems to suggest that you would have the DirectX texture object, plus the file in memory that was loaded by the resource manager.

      I think this is where I am getting confused. Can you confirm this is correct?

      The post was edited 1 time, last by Raeldor ().

    • Hitting the hard disk takes forever. The #1 goal of the resource manager is to make sure everything is already in memory when its actually needed.

      Is the resource manager the one that manages whch textures end up in the video memory?
      -Larrik Jaerico

      www.LarrikJ.com