In Venture the Void, and in basically every other game I've made, there comes a point towards the end where you start to notice memory getting eaten up. This is I think natural enough in the development cycle, to have a memory leak. Fortunately, if you have an object-oriented development model, it's not too hard to find a memory leak: since it probably can be traced back to objects not getting properly destroyed, all you have to do is count your objects.For Venture the Void, it turned out that the planet data was referenced in a circular loop and so as you flew from place to place the planets wouldn't unload completely. Fix the circular reference, and the memory leak disappeared.What I used was a little thing, called TRACER. This is just a little macro-gremlin that you put at the top of each class, i.e.,struct mystruct { TRACER(mystruct); ... rest of it ...};And what it lets you do is count how many instances of mystruct there are at any given time. For Venture the Void, it was useful to actually create a status bar that would show this, so as I flew from place to place I could see for instance how many cities, enemies, planets, etc. were loaded. If I noticed that every time I flew into a planet, and then flew out, the total object count went up by 5, I knew there were somehow 5 objects that weren't getting freed. Then I might notice that there were 5 satellites, and make a reasonable guess that it was something to do with that.Anyhow that's where I'm at with Texas right now, tracking down this ugly memory bugaboo! If you think a module like the one I created to keep track of object allocation would be helpful to you, you can get it here:CPP Tracer on Kittylambda.com
2008-12-30