If you’re anything like me, you’ve probably got used to the trusty .NET Garbage Collector always being there, and never really needing to know more.  Gone are the days of languages like Delphi (where I learned OO) where you had to explicitly clean up after any object you created.  You learned by necessity to be wary and methodical and avoid those nasty memory leaks.

Now days the Garbage Collector makes life so much easier.  With Business application development, there rarely seems to be any need to even think about all your memory usage and the Garbage Collector.

With Game Development however, it’s important be aware again.  You really want to minimise any reasons for the Garbage Collector to charge in and do it’s business.

Case in point:  My CloudManager class (essentially a Particle System, not that I knew it at the time) used to cause awful stuttering in my game 10-20 seconds after starting the game.  The problem was that the Garbage Collector was kicking in and cleaning up after all those Cloud objects that had since expired, and been culled from the list.  The solution was quite simple really.  I changed the CloudManager to behave like a Pool of clouds.  Once the pool reached its maximum size, the cloud objects would be recycled rather than culled.  Problem solved!!!

Anyway, I’m getting off the point.  The point is Shawn Hargreaves (of XNA team fame) has put up a most excellent wee post about the good ol’ garbage collector.  In particular he talks about how the much anticipated XNA Content Pipeline will deal with GC. 

Of most value, to me personally was his short and sweet explanation of the Garbage Collector from a Game Development point of view. Nice to have small an understanding of these mysterious things. 

Check out “Taking out the trash”.

This entry was posted on Thursday, September 21st, 2006 at 9:44 am and is filed under Game Development, Software Development, XNA. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.