Archive for June, 2009


reference counter based memory management + bitching about life

June 8, 2009

The bitching about life part comes first.  I believe the DCFC song “No Sunlight” sums up my rant in that regard nicely, so I won’t waste the space here.  Okay I’m done with that.

Now, on to the not depressing stuff.  I was thinking of ways I could potentially speed up memory management with threads.  I was basically thinking along these lines:  I should queue my object deletions so that I can delete them on the side while the next iteration is in progress.  So I came up with an interesting system.  I haven’t implemented the threading yet, but I have seperated object deletion from the main loop entirely and it’s just tacked on the end for now.

Basically I implemented a reference counter object management system.  Each ManagedObject has a grab() and drop() method, used to count references.  When the number of references reaches zero, the drop() method calls the queue_deletion() method in the ObjectManager singleton.  The ObjectManager also keeps track of ManagedObject’s that are still kicking, so that they can be cleaned up at the very end if they weren’t properly dropped.  This should keep memory leaks from being as bad, though that doesn’t mean I won’t bust my ass trying to find all of them.  So the current code for updating is as follows:

void Engine::RunMainLoop(double timestep)
while (running)
if (!Update(timestep)) running = false;
if (!Render()) running = false;

The ObjectManager deletes all things queued for deletion in CleanUp(). What I could do is simply start a cleanup thread that cleans up every second or so. For the threaded version it will lock the mutex for the queue to copy it over to a private queue and clear the public one so that it can be used again while the cleanup iterator goes through and deletes everything added previously. If you want the full classes, I shall have t3h c0dez in an article on custom memory management for C++ classes shortly.

EDIT: Okay, article’s up. It’s called “C++ custom memory management primer”. Link under My Articles in the sidebar.


OGRE integration

June 6, 2009

Well, I’m beginning to integrate OGRE, and lemme tell you… it’s growing on me. I also find that it can actually be quite slim when you leave out the utility components and do most things yourself. I just want it’s fantastic material system. I’m beginning to figure out just how unbelievably moddable this can make the game as well. In addition to loading an Actor file for every ship, that actor file will reference an OGRE material and mesh file, which is also fully moddable. I’ve also mastered the material abstraction system. For example, you can create a base class material called ship_material that implements normal mapping and paralax mapping over a main texture with all textures referenced by alias, then extend it with set_texture_alias on each ship, so none of that fancy shit has to be replicated, just say which textures to use and reference the .mesh in the Actor file. bam! I love modularity.


Continuum Engine

June 3, 2009

That’s the name I have for it now.  It’s a badass name, no?

Anyway, I’ve got 3demon engine working as a rendering engine for now, but I still hate the Irrlicht style shadows it uses.  It IS a branch of Irrlicht.  They’re just so… broken.  They don’t even have a consistent appearance across subsystems.  OpenGL has a different volume method from D3D9 in it.  I want something like OGRE, but I absolutely hate the way it’s organized.

Does anyone have an idea as to what I should do?  I don’t want to use my own rendering engine because I’d like the focus of this project to be on the game itself this time, not every little technical thing to support it.  I will give OGRE a shot, and if that’s how it has to be, so be it.  But do you absolutely HAVE to use the ReferenceApp layer?  That, I put to you, is TERRIBLE API design.