How pedanticly do people manage runtime errors during games? (1) Memory management, non-allocation, etc In a game with dynamic entities, would it be best to allocate large blocks of memory using your own heap allocation scheme? In a dynamic game, a person loading multiple programs AFTER the game has started might force the dynamic allocation of memory to fail (or at least the platform might start virtual memory paging). I can think of tons of hideous memory allocation problems. Has anyone thought about memory error management designs in games out there? I''m imagining that on a large project, trying to implement a system after 50-75% development might be a hideous beast. Is there a good game memory management design (system?) ? (2) Alternative Errors . Failiure of filesystems . Failiure of input devices [#2 is quite vague] Any ideas on error management of these devices? I''m being quite broad because I can think of reasonably good solutions in large projects. #1 is what I really want answers to. Memory management & Mismanagement. Are there prefered methods of allocating dynamic memory that I dont know about? Do current game companies just MALLOC or NEW ? I hope i havnt been too vague. Any responses from experience would be appreciated. Error management is not so important in small projects. In something larger, more commercial, it becomes important to at least ensure that it''s easy to implement. Thanks -Tim

ttt

to #1 Memory allocation problem;

It would be best to create a wrapper around any allocation

Weapon *pWeapon = AddWeapon(nWeaponType, pPtrList);

AddWeapon(int nWeaponType, Weapon *pListWhereMasterWeaponIsStored)
{
Weapon* pTemp = new Weapon(nWeaponType)
if (pTemp == NULL) // an location error has occurred
{
// decide here what you''re going to do
if (FreeStuff() == NULL) // can''t free enough memory
{
DumpErrorMessageToFile("Not Enough Memory for Weapon")
TerminateGame();
}
else return pTemp;
}

This is a brute force method of error-checking

A better method would be to have a base class for all your objects and include in that base an Error Message field and an Error-Handling member function.

derive other classes from it and ?possibly? virtualize the Error-Handling member function. And in the constructor, include the error message.


ZoomBoy
Developing a 2D RPG with skills, weapons, and adventure.
See my character editor, Tile editor, diary, 3D Art resources at
Check out my web-site
Also new links to combat flight sims

Weapon* pTemp = new Weapon(nWeaponType)
if (pTemp == NULL) // an location error has occurred
-------------------------------

This won''t actually work under C++. If new cannot allocate memory it should throw std::bad_alloc . so you''d need a:

try {
Weapon *pTemp = new Weapon(nWeaponType);
} catch (std::bad_alloc) {
if (NULL == FreeStuff()) {
throw "Weapon could not be allocated";
}
}

--------

(Yeah, my coding style is somewhat annoying...

Most comercial game companies spend a lot of time working on a memory subsystem. Here are the examples I know:

In Chris Hargrove''s Code on the Cob series he made a memory allocation sub-system (his articles are available in GameDev''s programming articles).

Quake 1 had a memory subsystem (look at it''s source).

The Darkside Engine (HG2 and some others), has everything derrived from a clean memory class. (ie the class tracks memory so that it doesn''t leak and is well organized) I read this in an article, at least.


Also, optimization-wise, you want to prevent memory allocation and destruction during your inner-loops. Or at least I read that somewhere.

I''m currently trying to work on a subsystem in my engine to allocate all memory at the beginning, then deallocate it all at the end, but it is very complicated. In fact, if I were to start over, I''d just worry about memory towards the end. The reason is that for complete control of memory I''d just have to write my own operator new, and use it.


re: #2

Currently I''m throwing exceptions all over the place. Later I''ll try to add recovery, but a lot of errors (like when a resource file is missing), I don''t find recoverable.


Dark Lord Pi

Thanks for your ideas.

I''ll look at the qsource to see how they''re doing it and learn some ideas from that.

I do know with memory allocation, finding the largest block of memory available is more timeconsuming than ideally liked during a loop.


I was also thinking about pre-reserving a block of some dynamic memory "reserve" memory.

Overide the new operator and all memory allocation schemes.

If memory is low, or not allocated (within the new operator''s algorithm, or your allocation scheme), deallocate the reserved memory, set

In memory allocator:
If memory is low or memory not allocated
deallocate the reserved memory
set an EXIT GAME NOW flag with "ERROR: OUT OF MEMORY"
continue with allocation or fail.

The alternative method is to preallocate _EVERYTHING_... but I think this''d be quite hard.

the deallocation of the reserved memory should be enough to get you through unwanted memory allocations to ensure that the error is cleanly handled without killing allocations for handling errormessages.

This might also be usefull when doing extensive debugging. Running out of memory while trying to dump a game log or something (i''m thinking of an arbitary case).

Any other ideas for memory management & error handling ?

-Tim

ignore the writing error in:
deallocate the reserved memory, set

Thats an interesting idea for reserving mem for error-handling stuff.. I had never thought of that.

This is something that''s keeping me back from progressing on my latest project. I''ve experimented with a mem management class that marked its memory so everything is safe, etc. I don''t like the way this worked. It was confusing and it probably fragmented the crap out of the OS heap. Next I tried a system where I managed my own heap, ensuring that all of the heap was in physical mem. This worked well because memory leaks are non-fatal -- at the end you just de-allocate your heap and everything''s fine. On the downside this allows you to code sloppily.

I''m setting out now to create something more sophisticated so that there''s intelligent handling of errors and memory allocation is consistent throughout. I want to do it right. So far, Quake''s system is looking very much like what I want (the Quake source is an amazing tool, so many neat tricks and examples, you must d/l and browse it).

It basically allows you to allocate ''hunks'' of memory each hunk has a name. This way you can partition your memory and guarantee that all texture data falls in a certain memory range, or make a small hunk that is used for temp storage (eg. strings, tmp arrays, etc). I haven''t looked at it in great detail, but its given me a few ideas of where to go.

You should have a look to. Let us know what you find.

I guess this is where most people put a famous quote...
"Everything is funnier with monkey''s" - Unknown

>I''m imagining that on a large project, trying to implement >a system after 50-75% development might be a hideous beast.

thats why you implement it from the beginning .

seriously though, error management is practically a must in a midsize to large project..

-goltrpoat




--
Float like a butterfly, bite like a crocodile.