Thread: Is it necessary to write a specific memory manager ?

Originally posted by Sayeh
A game should not be doing any allocation/deallocation during game play because that's cycle-consumptive.

Honnestly, for most video games, this is not realistic. That might be realistic for a game like quake3 or a fight sim, where the number of objects to handle is determined at launch-time. But, in many games, dynamic allocations at play-time are unavoidable, because the number and the type of the objects is very variable.

Honnestly, for most video games, this is not realistic.

Actually, it is realistic for virtually all commercial games. The reasons are obvious.

Virtually all games have a finite maximum number of RAM objects they will allocate at any given moment in time. Whether this is polygons, persons, projectiles, sounds, or any other RAM-utilizing object.

Therefore, it makes sense to allocate the RAM at startup because

a) you can make sure you have enough right up front,

b) it helps the memory manager because it prevents you from massively fragmenting your heap,

c) it simplifies your code because you only have to worry about allocation issues at startup and ending, and finally

d) it means game performance doesn't take a hit during gameplay because the memory manager is trying to compact a fragmented heap so it can put a block together of the requested size.

Of course, if you aren't interested in performance, maintainability, heap maintenance, and other little things like that we professionals care about, well then... 'nuff said.

Oh, and in case it wasn't obvious-- just because it's allocated, doesn't mean you have to use it right away-- it just guarantees it's available when your app does need it.

Stay tuned for more tricks from the game programming gods...