Monthly Archives: January 2007



Spent many hours coding today. I began by creating what amounts to a basic Windowing API. This in it’s self had a LOT to it.

But when it came time to implement it for the renderer my Scene Graph showed it’s flaws.

After many hours it is clear what I have to do.

There are going to be 2 separate entities:
1) 3D Scene Graph
2) 2D Display Graph

Both with their own completely separate base classes for the nodes. This change is an important idealogical change though which will have far reaching ramifications in the rest of the framework. Right now the Resource base classes assumes the resource is a 3D concerned entity.

This will be changed. Now resource will be a more general base class, and 2 classes will derive from it, a Resource2D class and a Resource3D class. Then any entity that wants to be added to one of the graphs must derive from one of these two base classes. This will , after quite a few hours of work, simplify a lot of what is going on in the ResourceManagerService.

Lastly, A new system for cameras is going to be implemented which will resolve an long standing organization issue as well as provide for a flexible camera system.

Sigh… Wish the semester wasn’t starting tomorrow. This is a very needed revamp to the Resource / Scene Graph system, but I had wanted to get something released before I got loaded down with work.

On a better note though, the WindowManagerService came out awesome! If I do say so my self, and I do 🙂 It combines several layers of complexity into simple high level functions. To create a window, all that is required is two function calls:
createWindow( window customization arguments );
displayWindow( windowId, true );

And thats it! I still have to build on top of this and add in buttons and such… But it’s a great start.

So it looks like it’s going to be a while till the next release, what with the semester starting and all… Oh well…

– Adam


Real quick one today, I finished the 2D base classes and got the Black Engine tag image displaying on the HUD again, with alpha blending.

Those base classes and the 2D Text base classes I did a long time ago are all that is required for my basic GUI. So now I am going to start work on the GUI service which I’m planning to have work quite a bit like a simple windowing API.

Meaning, you tell it the dimensions, location, and title of the window. Then using member functions of that base window class, you can add things to it like buttons. Really looking forward to this actually, should be fun 🙂 The other thing that will have to be accomplished along with this is having the Modes in the mode service take over control of setting the scene graph and such. This means, when you switch to the 2D GUI mode, that mode switch will automatically remove the 3D scene components from rendering, and when you push on a 3D mode it will push it’s components into the scene graph. Much more dynamic way of handling things. Any way hopefully I can hammer most of this out to night and tomorrow!

– Adam


So the logging system has been completely over hauled finally. There is now a separate logging thread so that write operations will not block inside the rendering loop. Formal logging messages are now implemented with logging levels so for public releases the logging level can be lowered from debug so there is less spam in the log file. Also as far as writing debug info goes, there is a much longer list of overloads for the write() function so any data type can be parsed out to text easily.

Also been working on the new 2D components to create a truly flexible base which a GUI Service will build on top of to provide a robust interface. Once this GUI service is complete it will be what the user sees instead of just loading straight into a BSP file. Then from there the user will be able to select the BSP file to load or exit the engine.

That along with 2 bugs that need squashing is all that is left on the release list!

So hopefully I can get those done soon and get a release out.

– Adam


I’m knocking down items on my release list fast and furious.

I finished implementing my new ConfigurationService which loads in *nix-ish config files in the form of:

# Commend line
Key1 value1
Key2 value2

So they can be accessed like:
getValue( “NameSpace”, “Key1” );

I hooked this up to the renderer already so the resolution and if it is full screen or not can FINALLY be set in a config file! This is something I have wanted to do since the engine started 2 years ago but always got put off!

The hooks for collision detection are finally in as well. Lets see what else…

I’ve been going through and slowly adding Doxygen comments to old code, as well as to all new code. I doubt the next release will be fully documented, but the one after that will be.

I also completely over hauled the boot strapping process of the framework which will crash more gracefully now if something fails as well as produce more informative log messages.

Also wrote the new unified TextureManagerService to replace the functions in the BSPManagerService. So now everything in the framework loads and manages textures in the same way. This is a big step because it allows for the 2D classes finally!

I’m debating what to do next now. There are 3 things left before I’d be comfortable doing another public release.

  1. 2D Interface classes
  2. BSPManager clean up code
  3. Asynchronous logger

While the 2D interface would be more rewarding, the number of logger calls is increasing a lot, and the longer I wait the more function calls will have to be replaced. So that will probably be next.

Theres still quite a bit of work left to do for a release, but getting close. Baring any unforeseen events, I should have v.6 out by the end of the week since I have nothing else to do!

– Adam


This ( Black Engine) has been, like I’ve said all along, a HUGE learning experience for me. I have tried to plan as much of it as possible by talking to people and doing copious amounts of research, but at the same time I didn’t want to just copy other engines. I wanted to know I could come up with these ideas on my own.

As I’ve been working with my Engine and reading and talking to people I have come with with a short list of things that must change. A sea change in fundamental design philosophies that should be used when making any component of the Engine. Now this will not effect many parts of the engine. In fact a lot of the engine really came out quite perfect IMHO. But the areas that need to change are as follows:

  1. Strict initialization phase required for ALL elements
  2. Stronger encapsulation for all classes resulting in more task oriented publicly exposed functions
  3. Re-implementing of scene graph to be less convoluted and more of a traditional Scene Graph implementation

Let me elaborate on each of these:
1. Strict initialization phase required for ALL elements: I had thought of this before any code was even laid down for the rewrite but wasn’t sure if it was necessary. The idea was that there would be two phases to starting up the framework.
1. Instantiation
2. Initialization
Instantiation, all elements that are to be started with the framework would be instantiated but the constructors would do nothing else. Then after everything was done, everything would then enter the 2nd phase which is where all the things traditionally in the constructor would execute, assigning default values and such. The idea being if one element required a pointer to another this method ensures the other element exists already so the order of instantiation does not matter.

2. Stronger encapsulation for all classes resulting in more task oriented publicly exposed functions: This is really a sea change for me in OO design. My instinct has been to, while protecting the private date, still only providing basic access functions to it letting the other classes combine them into the more complex actions they needed thus being totally flexible. But what this is saying is to have much more simplified functions that describe a task rather then a data operation. So instead of having setVelocity(), setPosition(), there would just be a moveTo() function. A shift to this kind of thinking has already been implemented in the User class’s control scheme.

3. Re-implementing of scene graph to be less convoluted and more of a traditional Scene Graph implementation: This has been a nagging aspect of the engine I have known from the beginning needed attention. Though it seems the longer I wait the better an idea in my head I get of what I want it to turn into. But now I think I have a very good idea of how to implement it which will result in a much cleaner design that is more logical.

That all being said, while a LOT of time has gone into theorizing about Black Engine very little work has been accomplished in the last ten days. I’m getting back to coding now. I have spend a LOT of time reading and talking to people about Collision Detection, and it is sure to be the hardest topic of the Engine, period. Looking at the time required to implement a proper algorithm, I am implementing a hold over so that I can get to the remaining topics left for the v.6 release. Those are:

  • Rudimentary Collision Detection
  • 2D classes
  • Unified texture manager
  • Configure file Service
  • Asynchronous logger

None of these are real time killers so I’m really hoping to bang these out in a couple days…

We’ll see.

– Adam


So we are well into the New Year now and progress is moving along on with Black Engine.

When I first got back I finished getting BE to compile on both Windows and Linux seamlessly which took a minimal amount of code changes but a lot of time organizing and standardizing the build environment so everything works exactly the same on both platforms. A lot of time was spent getting all the build targets working and standardized as well.

I then got the entire project into SourceForge’s SVN which is a big sigh of relief for me since it’s not just sitting on my hdd some where now.

Lastly I created post compile scripts for every project which automated a task I had been performing by hand and which had really sucked. So now the build environment is much cleaner and extremely easy to set up and get building.

Why did I do this you ask? Because I have a new programmer helping with development now! Ju2wheels2 will be taking on some tasks as he can to help speed things along. His first task is a complete overhaul of the Logging class which will add some much needed functionality as well as improve logging performance greatly.

In other news I finished the changes to the Kinetic Element system which has resulted in an even yet cleaner and faster system for moving Elements.

With all of that done I had a choice, I could start on the 2d GUI classes which would require a Unified Texture Manger Service, or just jump right into collision detection finally and just get this nasty beast taken care of. So I started researching different approaches and algorithms and identified the one I wanted to use.

It’s an ellipsoid-plane collision detection/response algorithm that is very well explained. So after a day of reading and looking at how it would fit into the engine, I began coding it today. I’ve put down about 300 lines of code for it today and I can already say. This is one of the hardest topics I’ve tackled yet in the engine. It’s going to take some time to get this one right. But it is coming along.

Also there is some very preliminary planning taking place for a Game which will use Black Engine. Chris our lead artist has been working up some concept sketches and we’ve been talking about game ideas. I think we have some pretty cool stuff brewing.

Unfortunately I’m leaving tomorrow for several days. Going down to Mass to do some Slave labor on my dads boat 😉 But when I return I plan on banging out this damn collision detection algorithm and hopefully get a release out shortly after.

– Adam