Glueing Leadwerk's TEntity and your own codebase together

[Laurens]

Hi guys,

 

I am interested in how people have glued Leadwerk's TEntity and their own codebase together. Right now I have a C++ class Entity that forms the base class for all my other objects. I had problems properly deleting the object and the actual TEntity it was wrapping. Imagine you have a Scene class that inherits from Entity. The scene class has a number of child TEntity's of which the corresponding C++ class has also been new'ed during the loading process. Now, if you delete the Scene, freeing the entity, the engine will automatically free the childs of that entity. The result is that the TEntities are properly deleted but the C++ objects remain because they never have had their destructor called. To solve this I added the free callback to my entities, calling the destructor of the TEntity's user data in the callback function. It is not hard to see this will end up in a loop and solved it like so:

 

void _stdcall FreeEntityCallback(TEntity entity) {
   Entity* e = reinterpret_cast<Entity*> (GetEntityUserData(entity));
   SetEntityUserData(entity, 0);
   delete e;
}

 

Entity::~Entity() {
   if (GetEntityUserData(_entity) != 0) {
       SetEntityCallback(_entity, 0, ENTITYCALLBACK_FREE);
       FreeEntity(_entity);
   }
}

 

I am interested to hear how other people have solved this particular problem. How have you wrapped Leadwerk's TEntity?

 

Thanks!

[Canardia]

You would need to write your own World::Free() method, which nullifies the TEntity pointer in all C++ classes. Then Scene::Load() should also populate a vector with all loaded models. This is something which could be added to LEO too, since without it, LEO kinda doesn't work how the engine is working internally. LEO should be as close as possible to the BlitzMax OOP interface.

 

But I think it's better to wait for LE3 to have a full C++ OOP interface. LEO is just a light C++ OOP interface, as it was designed as such.

[Laurens]

Well, that's essentially what I am doing now. I am relying on CountChildren and GetChild to maintain the list of children of the scene. When loading, it just new's the appropriate classes and when a list of instances is needed, it grabs the children of the TEntity and casts the user data to the appropriate class again.

 

It does feel kinda clunky though so that is why I was wondering how other people solved this particular problem.

[Canardia]

Instead of using Entity userdata, I would populate a STL map in a ProcessScene function, after the scene is loaded. Looping through the map is also much faster than using the ForEachEntityDo function.