Resource Cache Theory/Impl Question

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

    • Resource Cache Theory/Impl Question

      Ok, this post is my understanding of the Resource cache with questions mixed in.

      The resource cache is a mechanism for keeping track of which resources are currently loaded, which resources need to be loaded, and which can be unloaded. Loaded and unloaded referring to the game/graphics engine, DX or middleware.

      1) The res. cache is merely an external (to the rendering pipeline way to keep track of the resource and still needs to be loaded into the graphics engine?

      2) Thus at one time, if a resource is in use a copy of the resource exists in file format, in memory in the res. cache, and in DX or the engine also?

      The loading of the resource into DX, OGL, or the proprietery engine still needs to be accomplished by some API call even if the resource is loaded into the cahce.

      3) This could be done inside of the ResCache::Load(..) function at/near the bottom of that function? (The books example was: DX3DCreateTextureFromFileInMemory(...) )

      Thanks,
      Alien

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

    • RE: Resource Cache Theory/Impl Question

      Another good question.

      The goal of the resource cache is to keep as many things in memory that will be used over the course of the game level (for shooters), or game area (for big world streaming games).

      The idea is to limit access to the disk (HD or DVD), optimize the use of memory space as much as possible, and if you DO have to hit the disk make as best use of the time as possible.

      So...many of the answers to the questions you ask are very dependant on what kind of game you have, how you store your resources on disk, and in what form they take after they are laoded.

      Take the texture as an example - the best thing would be to load the texture in memory once, get it into the right format if necessary, and stick it VRAM and leave it there for all eternity.

      But, not all games can afford to do that. Frequently, some textures will eventually fall out of use and others will be needed. If that happens, the next best option is to hold the unconverted texture in memory (this assumes a PC game too - XBOX has unified memory, and PS2 is quite another beast altogether) so when it needs to be stuffed back into VRAM you can do so without hitting the disk drive.

      The last option, of course is to nuke the unused texture from all memory and bring in the new one.

      Not only is platform a concern with your resource cache, but the type of resource is also important. Some resources should always be in memory, no matter what, because they are in constant use. Others are used so rarely that the moment they are not referenced they can be thrown out. And, there are those resources that fall somewhere in between.

      The best course of action is to plan your memory and resource useage to the finest detail - and any caching that happens is all part of a finely tuned architecture. The CPU needs extra cycles to hit the disk, decompress resources, and copy all the results around, so you have to do that in a part of the level that isn't crowded with AI, physics, and a million polygon environment.

      Remember that the book's resource cache gives you a place to start, but it isn't a good solution for a real game. There's a lot of optimization that should be done first (I mention that at the end of the chapter, and list a few ideas). One thing would be really important - store the resources on disk as close to the format they'll take in memory as possible. If you minimize copying/reformatting, you'll be better off. Compression is OK, as long as you can turn that on/off per resource.

      Does that help?
      Mr.Mike
      Author, Programmer, Brewer, Patriot

    • RE: Resource Cache Theory/Impl Question

      Yup, that did it! On a final note, once the resource cache is done with the resource and the resource handle is "destroyed", the task of removing the actual resource from DX or the game engine is still at hand correct?

      I'm guessing that at the same time the resource handle is destroyed (or maybe even as part of the resource handle class destructor or something) the resource would need to be removed via a DX API call.... DX3DRemoveTexture(...) or what ever it is?

      Thanks,
      Alien