🔒 Locked

Memory Management Paradigms

Started by shiftLynx Dec 30, 2004 at 11:42 AM 0 replies 300+ views

Original Post

Dec 30, 2004 at 11:42 AM

I'm currently writing a small game engine, based on ideas in the "Enginuity" series (http://www.gamedev.net/reference/articles/article1947.asp, http://www.gamedev.net/reference/articles/article1954.asp, http://www.gamedev.net/reference/articles/article1959.asp, http://www.gamedev.net/reference/articles/article1973.asp and http://www.gamedev.net/reference/articles/article2011.asp). I was attracted by the modularity and good structure of the ideas Richard Fine has collected together. However, I've run into a problem as far as smart pointers and reference counting/garbage collection are concerned. I believe that the system of memory management used in the Enginuity series is based on this article: http://www.gamedev.net/reference/articles/article1060.asp -- objects which are to be automatically collected are derived by some class, then smart pointers increase/decrease references as necessary. At some point in the game loop, all objects with zero references are deleted... which is where the problem arises: objects allocated on the stack cannot be deleted. After much tweaking trying to get the system working nicely, I've decided to give up and try looking for other methods. This is really what I'm trying to achieve: a memory management system which can return unused memory to the heap at any time in the game. For example, all of the textures used in some map may become redundant once the map is complete; all "texture" objects would be deleted. It's trivial to implement a system in the map loader to release all of the textures when a new map is being loaded, but I'm fishing for a better method. One thought that I have had is creating a template called "DisposableResource" - this would determine whether an object can be deleted or not. Example: DisposableResource< CSomeClass > disposableObject; Smart pointers could then decide whether or not the object needs to be deleted or not (possibly because of a member flag set by the DisposableResource template to indicate that it is disposable). I'm sure that if I gave this method enough thought, I could come up with something... and I shall give it much more thought. In the mean time, could anybody suggest different memory management techniques? Another characteristic of garbage collection that I really like is automatic detection of memory leaks. What other memory management paradigms are used in commercial games? What would other people suggest? Thanks for any feedback. - Chris

Kitt3n

Dec 30, 2004 at 1:00 PM

Maybe sth like the following is suitable for your needs:

If a particular object (eg particle system) needs a resource (eg a texture)
it will "create" it in the textureManager...

The textureManager looks if this texture was already created.
1. it was => increment ref-count and return existing resourceID
2. it's not => create and set ref-count to 1.

As soon es the object is destroyed, tell the manager you don't need the
resource anymore (ie decrease the refcount).

Now make a resource-budget (max mem to use) and if the resource
count goes down to 0, let the resource continue to exist (don't just
throw it away yet, we are still withing our budget!)..

As soon as you allocate a new texture (create), check the budget if no
space, swap out the resources with refCount 0 (if none, remove the
oldest texture).

Hmm... hope you can make some sense of this :)
Anyway it works pretty well for me.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.