Captains log - 30/08/3006
For the past 4 days now we have been stuck in deep space, unable to travel anywhere and our power supplies running low. The backups are now running low after the main engines stopped working. Our best technicians are at work trying to correct the problem - but it seems like a mistake in the main operating systems of our ships computer have caused us a problem. Due to overuse of the holodecks we have run out of memory to run vital systems - I would order a purge of the main computer to correct the problem but it seems this would shut down the ship long enough for our air supplies to run out. Damn these people who write our leisure software - they seems to cause us no end of problems with their ever expanding desire to write realistic software. Apparently we would have been fine if we'd managed to get our planned upgrade while in space dock last month though ... but for how long?
One part of my job is to ensure that a game runs on a given platform within the constraints set by the console or our memory specifications. Consoles are easy since you have a limited amount of memory to play with anyway, so you know how much overhead you have to play with. PC's are a little more flexible due to various reasons - but its still nice not to push peoples machines too much - for various performance reasons, but mostly for not having to force people to upgrade their machines just to play a game.
Fighting to ensure that the game data, textures and model data all fit into a limited space is a very delicate job ... but then you have another thing to think about - fragmentation. All together its actually an amasing thing that games can be fit into the memory on some consoles and still have such a high visual quality.
From the start of a project you need to ensure that you have clearly laid out limits for all your data - and stick to it. Memory profiles of layouts and strict checking of exported data is needed - especially when your artists are prone to author textures in massive sizes and then scale them down at export - hopefully, I have seen exported data creep into the game where textures are still at their 2048x2048 original resolution.
Over time we have developed quite an extensive set of memory libraries and tracking tools - both in debug builds and PC side tools that help us to track all manner of allocations, deallocations and fragmentation holes. But it is still alot of work to keep a check on games and ensure they are running smoothly in all areas. Being able to track where and when an item was allocated - or even what deallocated it - is a major asset to identifying and correcting problems.
Its not that much of a problem with homebrew applications/demos, but its still good practice to watch out for the pitfalls and try to code yourselves a good set of libraries and tools to just see what its like to deal with these sorts of problems. Understanding these problems, their causes and solutions makes you much better programmer!
Another thing is that there are libraries/programs out there that can help you to profile your application to see wether you have memory leaks. Direct3D's debugging levels are also useful in that they will report if you have any objects still referenced/allocated when your application is shutdown. Make use of them :)