RE: [boost] shared_res<>, pooling

From: Gary Powell (Gary.Powell_at_[hidden])
Date: 2000-04-10 11:39:18

> Use:

In games, lots of objects share resources, all of them may not be visible.
If system resources are tight, resources that haven't been used recently are
candidates for being paged out. Only the memory manager knows that it needs
more RAM.

Think of it this way: You have solders moving about, one part of their data
is the graphic image of them fighting. Unless the camera is on them, you
don't need to draw the image. So while the soldier still exists in the
world, and his image resources are "used", They are not currently in use.

You can either request the image every time you need it using the original
key (often a filename string). Or Build a table of resources, hand the
soldier a resource index. The request now uses the index instead of the name
(saves on the hash, and duplicate storage for the similar soldiers) and
looks in the table for the resource. If it's not there it's refreshed from
the CD/DVD. Each call at the resource updates the clock field. This scheme
requires that you register resource files with a resource manager so it will
know where things are.

It's different from a shared pointer, in that, the object is one more layer
away. You also may want a lock/unlock system on it so that subsequent calls
within a loop don't page it out and you thrash. (Although the clock markers
should keep this from happening.) The resource manager may also want to
store the size of the object as well so that when the memory manager comes
calling you can free up enough memory and possibly the a single block of the
right size memory.

This is all hideous and nasty and I hope to never have to do it again.
(Console boxes with, RAM, and a CD but no disk space have to do these
things.)

-gary-

gary.powell_at_[hidden]