Resource Management has come up several times in Epiar. It's something that's currently missing in Epiar (resources are loaded directly). Here, I've decided to draw up my idea on the subject, for others to review and comment on.
Requirements
Load Resources
The Resource management system should be able to load any type of resource (be it an Image, an Animation, a lua file, a sound file, anything). The system should be able to load only one instance of the resource into Memory, even when there are many instances of it used in the Game. When a Resource is not needed anymore, the Resource system should be able to automatically unload it.
Background Loading
The system should be able to optionally load resources in the background. Resources should also support unloading in the background. User code should be able to efficiently poll for the loading state of a resource.
Background loading should be independent from the rest, that means the resource system should not depend on the presence of background loading. In fact, Background Loading should be a separate task.
Group Resources
Group Resources or a similar concept should exist to allow many resources to be loaded or unloaded in one go (this is useful, for example, for loading a complete scenario).
Filesystem Independence
Resources should not depend on the OS filesystem to load. They should be able to be loaded from a variety of sources, from example from a .tgz file, or from memory.
Portability
Ideally, the system should use no OS-dependent calls or structures.
Implementation Suggestion
Load Resources
Different types of resources should derive from a common base class which implements the loading logic. The derived classes should overload the protected virtual methods LoadImpl?() and UnloadImpl?(), which actually perform the loading and unloading, respectively.
The resources should be reference counted. When there are no more resources, they can then be automagically unloaded.
Sometimes, it's useful to keep certain resources loaded even when they're not currently needed. This could be simply implemented by having Resource keep a sticky count which can be incremented, and is decremented automatically when it's referenced again. Another solution would be to have a utility class that hoards a resource (and therefore a reference to it) to prevent it from being unloaded automatically.
Background Loading
A generic background event queue should exist, for generic background worker threads. The resource system should use that generic system for loading these resources, by simply calling the synchronous loading function on these resources.
Group Resources
These could be implemented by a new Resource type, which contains a list of Resources which it loads and unloads.
Filesystem Independence
There are existing mature and stable libraries to achieve this (for example, PhysicsFS, which has been suggested before, or SDL RWops plus a "directory" layer). If I remember correctly, PhysicsFS and SDL RWops can be integrated. The system should just use PhysicsFS or something similar.
Portability
With PhysicsFS and SDL, there should be no need to write any OS-specific code.
Changes in Epiar
Images
For example, the Image class would just be an image "instance". Its Load() function(s) would load the resource it needs through the resource system, instead of loading the resource itself as it does now. Code in Epiar that uses the Image class would not require changes, only the implementation of the Image class would.
