The Open Adventure Project

Any header files shared by both the game and the editor should reside in the library only to avoid code synchronisation problems. This means that if the header is changed at all, it need only be changed once.

If anybody has a problem with the way this is structured, please ask here for clarification of why it has been structured this way and perhaps suggest an alternative. Please do not simply re-structure the files without discussing it after I have structured it a specific way.

Scons now successfully compiles Both Editor & Game with libtoap as a shared library.

I've added a "WinDebug_VLD" target in Visual Studio to support memory leak detection using Visual Leak Detector. See the Wiki Current Status page for brief instructions of how to set this up

For anyone using Linux, can use the Valgrind suite. Install it via your Distributions repository.

I'm unsure if Eclipse is set up to compile with the -g flag to include debugging information. Though scons is.

Then just run:
valgrind --leak-check=yes ./myprog

The above command will run Valgrind's MemCheck System. There are more feature available in this suite so I'd recommend checking out the Quick-Start Guide.
http://valgrind.org/docs/manual/quick-start.html#quick-start.intro

Any header files shared by both the game and the editor should reside in the library only to avoid code synchronisation problems. This means that if the header is changed at all, it need only be changed once.

My bad, had a bit of a nasty brain fart and got all confused. My apologies.

No harm done. I know that everyone has their own idea of how things should work, and a lot of the different ideas are bound to conflict at some point. I'm glad we could resolve this without any major problems. Let me know if you think I'm doing something really stupid, I have been known to have brain farts too :)

I have to say valgrind is ruthless when it comes to memory checking.

for instance

void createkeyEntity()
{
    Entity* keyEntity = new KeyEntity() ;

    EntityList.push_back( keyEntity ) ;
}

It should be:

void createkeyEntity()
{
    Entity* keyEntity = new KeyEntity() ;

    EntityList.push_back( keyEntity ) ;

    delete keyEntity ;
}

I'm glad I decided to check my code for leaks. :)

That's a good example of the flaws in automated tools like valgrind. EntityList stores pointers, you pushed a new pointer into it and then deleted what it pointed to, thus rendering the pointer invalid. There's no memory leak sure, but if you retrieve that pointer from the EntityList and try to do anything with it then Bad Things™ will happen. So now EntityList contains pointers to garbage.

It would only have been a memory leak if the key entity was never deleted at all, not if it wasn't deleted in the same function. Right now the entities only exist within the function which creates them. If the entities are going to have the same lifetime as the EntityCreator then just iterate through the EntityList delete'ing the pointers in the EntityCreator destructor instead. If they're going to exist longer than the EntityCreator then you'll need a seperate list somewhere, have some form of auto-deletion (reference counting maybe?) or have the game code bear the burden of ensuring no memory leaks where entities are concerned.

Memory management hurts my brain sometimes.

Fixed that bug. :)
On a side note: All Specified Entities like Level & Door entities can now have their own geometry.