Proposal:Resource Memory Management

This article is currently only a proposal

The features or design guidelines described in this article are only a proposal made by one or some persons. It has not been reviewed and ratified by the core development team yet. Feel free to add your personal opinion about them or make counter proposals.

Related forum post: New Resource and Memory management

Memory Management

Specifically how to deal with pointers -> Python. boost::shared_ptr for example.

Resources

Images/Textures/Tiles, Audio, Video, Fonts... etc etc.

Engine Structures

Maps, Instances, Objects, Layers... etc etc.

Brainstorming

prock

• Whats our thoughts on FIFE::FifeClass? It adds the ability to count references of any derived object but it's not actually used. The Singleton classes are derived from FifeClass as well. Is that a requirement? TimeManager, RenderBackends and GUIManager are all singletons. My thoughts are that all game related objects (like maps, instances, layers, sound emitters, etc etc) should be derived from FifeClass so they get a unique ID.
  • What is the criteria for deriving from FifeClass? Currently FifeClass only gives a FIFE ID.. Should all FIFE objects have a FIFE ID? Should only game (or game data) related objects have a FIFE ID? Whats the standard here?

• What about FIFE::IReferenceCounted? FifeClass is derived from it and implements the reference counting mechanism. ResourcePtr wraps it and is only used in Animations.

• There are 2 types of data in the game. One is game related data like map, object, animation files. The other is raw data that is used by the engine.. like images and audio files. I think they should be treated differently. Game related data should be left up to the client to load/save (we would still provide default XML loaders/savers). The rest should be loaded by FIFE as they are now (correct loaders are detected and used). The "RAW" data should be the only data that is pooled. The pooled data should all be managed by a single ResourceManager class (a factory class). All other "game" should be managed by their respective containers. i.e. Layers are managed by Maps, Instances are managed by Layers. etc etc. Perhaps the "model" itself should act as a factory for these. model->createInstance(map,layer, object);

• The map editor itself could use a plugin system for loading maps, animations, objects, etc etc. That way you could run the editor with a command line option defining which plugin to use.

• Object owners should be well defined. Layers OWN instances. Maps OWN layers.. etc etc. I seen a bad use of this in the cell grid. There is a new (cloned) cellgrid created for every layer in the game. The Model currently owns the cellgrids but never actually removes them?? One thing that has to be looked at is the cloning process for the cell grid.

• I was browsing the Ogre3D documentation. They have a pretty nice way to manage resources. Check out their ResourceManager documentation.