Game Development Community

Memory Management.......

by George Ison · in Torque Game Builder · 12/17/2011 (11:09 am) · 12 replies

Hey folks,

We have a question about the memory management in T2D. Our latest production is a match based/platformer set to release in January. However, it seems to really be hogging the memory so to speak and for what reason we cannot seem to tell. What memory management methods are hidden around in T2D that we can use possibly during scene swaps, level loads and things like that to free up memory? When using t2dsceneWindow.endLevel are there other things we should be aware of that are not being taken care of in this method? Should we be deleting more manually through t2dsceneObject::onLevelEnded or something of the like??

What other methods based on T2D do you suggest that will help us create lighter footprints with this product?

Any help you can provide would be greatly appreciated and we thank you in advance.

About the author

Love to engineer and develop just about anything. Our primary focus though is that of computer games and software tools.


#1
12/20/2011 (8:49 am)
Hi George, you can manually cleanUp the scene after the level is completed using a function like this:

function levelCleanup(%scenegraph)
{
	echo ("Starting level cleanup : " @ %scenegraph);
	if(isObject(%scenegraph))
	{	 
		echo("******* Cleanup Level *******");  
		%sceneObjectList = %scenegraph.getSceneObjectList();
		for (%i = 0; %i < getWordCount(%sceneObjectList); %i++)
		{
			%sceneObject = getWord(%sceneObjectList, %i);
			if(isObject(%sceneObject))
			{
				echo("["@%i@"] object deleting: "@%sceneObject.getClassName());
			   	%sceneObject.delete();			 
			}   
		 }
	  	echo("******* Cleanup Level ended *******");
	}
	else
	{
		echo (%scenegraph @ " is not an object");
	}
   
}

Besides that make sure your sprites are POW (Power of Two, eg.. 512x512.. 1024 x 1024) this reduces the amount of memory used by the graphics card, because if your images are not in POW OpenGL will convert it automatically to the next POW.

Another tip will be to disable the preLoad of images on your datablocks like this:

new t2dImageMapDatablock( SomeImage )
{
    imageName = "~/data/images/SomeImage";
    imageMode = "CELL";
    frameCount = "-1";
    filterMode = "SMOOTH";
    filterPad = "1";
    preferPerf = "1";
    cellRowOrder = "1";
    cellOffsetX = "0";
    cellOffsetY = "0";
    cellStrideX = "0";
    cellStrideY = "0";
    cellCountX = "-1";
    cellCountY = "-1";
    cellWidth = "170";
    cellHeight = "128";
    preload = "0";
    allowUnload = "0";
};

Note that the preload property is equal to "0" which means that the engine will load it on memory only when is going to be used by an specific scene.

Hope it helps.

Hugo.
#2
12/20/2011 (9:04 am)
Hugo,

You just helped us out tremendously friend. Thank you very much. We actually found that the pre-loading of sound caused our memory issues to be outrageously high, by stopping this we were able to reduce memory consumption by a whopping 40%!.

I had actually just learned that OpenGL was actually updating to the next POW, so we haven't even looked at that yet but what I did not know was that images were being pre-loaded as well. We are looking at this now as well.

Again thank you very much!

#3
12/20/2011 (9:07 am)
Hugo,

Question about the code you posted, does t2dsceneWindow.endlevel not do the same thing?

Just curious....
#4
12/20/2011 (11:47 am)
This helped my memory-hogging problems as well! I figured I might as well make it as efficient as possible before I'm even CLOSE to a public Beta. Thanks!
#5
12/20/2011 (12:23 pm)
@ George, endLevel function just deletes the tile maps if any and clears the sceneGraph, but I suspect that all the imageMaps are kept in video memory. If somebody knows this better than me, please leave us a comment.

#6
12/20/2011 (12:35 pm)
@Hugo,

I definitely see your point here, I just didn't want to create even more code if we were essentially already doing that with endlevel which we thought we were, especially with clear scene being in the endlevel code.

I will do some testing and see if i can physically see a difference in memory.

By chance does anyone understand what the variable field "allowUnload" does and why it's an option? Is this used in some kind of auto memory management algorithm?
#7
12/20/2011 (1:19 pm)
allowUnload flag is used by the engine when it tries to remove the image from memory, the engine removes the images automatically when there is no valid references (smart Pointers) associated to it.

The following paragraph was taken from the official documentation:

"allowunload"


This field is closely linked with "preload". As mentioned above, when not preloading textures, textures will be activated when a texture-frame is referenced by a TGB object. What was not discussed was that when the TGB object no longer references the texture-frame, the texture is deactivated meaning it disappears from memory. Don't get this confused with the image-map being destroyed, this isn't the case, simply the texture-data is removed from memory and the image-map is still around. This means that when you don't preload textures, they get automatically activated/deactivated as sprites reference them. You can use "allowUnload" to control whether textures are deactivated when an object no longer references it.


You can use "$prefs::T2D::imageMapAllowUnloadDefault" to control the default value for the "allowunload" field.


Hugo.
#8
12/21/2011 (2:19 pm)
Hugo,

Thanks a million man your help has been greatly appreciated on these issues. We have reduced out memory foot print dramatically!
#9
12/22/2011 (7:43 am)
No problem, I'm more than happy to help. If you still have memory problems I could show you some engine level changes (C++) to reduce it even more, but I think you are OK by now.

Happy coding, and merry Christmas bro.

#10
12/22/2011 (8:14 am)
Thanks friend and Merry Christmas to you and yours as well! I might take you up on that memory offer soon, might even be nice to work on a project or two with you! Shoot me an email sometime!
#11
12/22/2011 (1:15 pm)
Sure, when the right project comes into the table, will be nice to work together.

#12
01/14/2012 (10:01 am)
This little exchange helps me tremendously as well I seen other places where optimization issues are discussed. Hugo if you could make a resource of your knowledge I'm sure it would help the community greatly. It would also give users a place to post their own optimizations to build upon your insight.