Hey, When doing memory management for games, it a common solution to allocate a big chunk and afterwards to your own management within it. How big a chunk do you allocate?? Do you make your memory manager extendable, letting it allocate more memory when needed, or do you just keep a fixed-size chunk? And when programmers specifie the memory required for their game to run, how do they determine that? What affects that amount of memory required? And last, how do they determine the recommended amount of memory?? I'm sorry that the questions might seem stupid, but I would really like to know.. :)

Writing a custom memory manager is definately something that games have used but whether they still do, and how common this is, I couldn't say.
However I wouldn't recommend it as a particularly useful thing to do at the start of a hobby project unless it interests you particularly. If you think you'll use it later, to minimise future code changes you could write a 'dummy' manager class which just passes all calls through to new/malloc/whatever. This wouldn't be a bad thing since it can very easily tell you useful information like how much memory you are using and if memory is not being deallocated. Then if you decide you need a real memory manager just slot that in instead; if not you still have the added functinality for debugging.

Hope this helps you?

Of course it helped, but I would like to get some answers to my other questions too.

But I see your point. The memory part in a game might not be so important anymore, but I think that it could help alot if a solid manager is written.

Actually memory managmenet is very important not just to conserve memory but to prevent memory fragmentation killing the performance of your app.

I think a suitable quote would be:

Quote:
"Premature optimization is the root of all evils", Knuth said, but on the other hand, "belated pessimization is the leaf of no good", according to Len Lattanzi

i would tend to agree, your going to have alot of small objects de/allocated on the heap at random/arbitarty periods of time its most likely gonna kill your performance by fragmenting the heap.

for instance imagine having some STL container of pointers/smart pointers, every time you add element not only you going allocate that new element on the heap the address of the instance is going to be copied & allocated on the heap aswell.

You probably wont a mixture of memory stragties for small & large objects, for STL containers of pointers/smart pointers i use a pool allocator (boost::pool_allocator) instead of the default allocator type.

EDIT: That quote is gonna be my new sig

Yes,

But what about the other part of my question? Will a fixed-sized pool / heap be able to do the trick? Or is a extenable heap necessary?

And what about my question about, how to determine required amount of memory and the recommended amount???

Useful resource: Memory Management

Quote:Original post by OleKaiwalker
And what about my question about, how to determine required amount of memory and the recommended amount???

pretty much you determine this based on the min-spec machine for which you are targeting your machine. i.e. if you are targeting a 512MB machine a good size for your chunk might be somewhere between 256MB and 350MB. so basically you say: "this game must run on this machine" then you make the game fit in that much memory.

and the answer to your next question: "how do i know what's a good min spec machine"... the answer is experience. develop a few games. get a sense for how different levels of quality perform on different platforms. decide if you are shooting for a AAA product or just a hobby quality game. typically at the beginning of a product for a AAA game you'll decide that the min spec machine is whatever machine was a top performer either at the beginning of your product or a few months before. by the time you release your game 1-2 years later, the machine that was at the top of the pack when you started, will be a decent entry-level machine.

worrying about how much memory to allocate if this is your first game is probably a waste of time. odds are you'll never come close to maxing out even a 2 year old computer and memory fragmentation will likely be the least of your worries. it's certainly a good idea to play around with memory managers, but don't worry too much about the details now.

-me

You could check here in gamedev the Code on the Cob series, it have some chapters about memory manager and how to use to handle game resources, cache it, and every other good tricks you could need. By the way it contains full source code!

http://www.gamedev.net/reference/list.asp?categoryid=45#115

Regards,
Oscar

Hey, thx... :D

I'm sure it'll be a good help.