Monthly Archives: April 2007


Well. what follows is the meanderings of thoughts I have had during the past 2 weeks.

If ur not terribly interested in Black Engine / Software Engineering you’ll probably want to pass this one by. But I think for those of us that are new to trying to learn as we create, this should be of some interest.

So I began by tracking down a very intricate heap corruption bug involving a string of virtual destructors which after learning many many new techniques for debugging memory corruption I tracked it down to several places in my more basic code. Code that I had tested to my satisfaction. This was a big slap in the face. Some of the mistakes were minor and forgivable in my mind because of the huge time crunch it was all developed under. But some were more integral.

I found several rather severe faults. Some where in design, some were in general ideology.

Let me go into them.

The first, the Element class in my mind should handle and subsequently hide all of the interactions with the Element Manager Service. Essentially wrap all the functionality and provide higher level, task oriented access to the Service’s functionality. This all seemed logical to me. So in the constructor (all constructors are virtual) the Element class handles registration with the EMS. Now, if the EMS rejects the registration, which can happen if the Element Id is not unique for example, the instance of that element is not valid and should be deleted. Well, this constructor is being called from a much higher level virtual constructor. So neither the EMS register() function now the Element constructor it’s self can handle deleting the memory b/c at that point during the construction it only knows that it is an Element, there for the Element memory would be deleted, nothing else, and the rest of the constructors would proceed as normal. Even if you don’t delete it right then, you then have the issue of communicating back to the calling code the fact that it failed. Also the calling code must then have to take care of cleaning it up conditionally which I didn’t like.

Now I thought up several solutions but when pitching them to other programmers got the sense they were very uneasy about the whole thing as was I. It just indicated there was a deeper design flaw. Their general response was, it should be a 2 stage initialization. Construction, then initialization. This is probably something close to what I will be going with.

Another thing. I didn’t use exception any where in the design. I have used exception and understand them just fine. But I had never used them in C++, with the time constraints I had at the time and the amount of things I had to learn any way I decided to not tack on another unknown. That was a mistake. Exceptions would provide a very clean solution to the previous issue as well as many others. So some point soon I plan on developing the exception scheme and implementing it.

The last big thing is. I tracked the majority of my memory corruption bugs back to my hash table. Which. Christ. I should be able to code a freaking hash table. That was the big slap in the face. For many reasons though besides just the memory bugs, I decided to switch to STL::map which is a simple unique hash map. While doing so I learned a lot about 2 things which I had known existed but hadn’t spent time to get to know well. Iterator and References. The sad fact is, I was taught C and C++ together so until recently had a confused idea of what belonged to which language. If you don’t know already, while they can be used together, they shouldn’t be, and there is a clear separation between the two.

In C++, looping through arrays should when EVER possible be done with Iterators. And heap allocated objects should almost ALWAYS be passed by reference (which does NOT mean passing a pointer!), for speed, safety, everything. Use References!

So I plan at some point removing as many as possible (the VAST majority) of raw pointers and replacing them with references.

That being said, this is the view of my code through the most critical spot light possible. My own. I believe that when these things mentioned are refactored, the code base will be rock solid and modern well coded C++.

So takes a breath…
Any way, I started writing the 2nd tutorial which goes in depth about the Extension project which is the actually game and graphics engine portion of the whole framework. I’ll probably finish that tomorrow as well as hammer away at some more of the bugs and maybe a few of these refactoring tasks.

Well, if your still reading then you’re a freaking trooper lol.

That’s it for me.

– Adam


So, I’ve spent almost a week on this memory corruption bug. Talked to a lot of people and read a lot of things and finally come up with a plan to crush it after it evaded all my previous methods.

I downloaded valgrind which is “the” memory manager / tracker for Linux. This thing has been used by NASA for the Mars rover and EA for games like Battle Field, I mean this thing is the heavy weight champ of it’s class of programs.

So I booted into Linux, wrestled with my video drivers a bit more and updated everything since I haven’t booted up into Linux in a few months. Then I got valgrind running straight from the Ubunutu repository.

And let me tell you. This program is a dream. I will have this memory corruption bug plus many other potential bugs killed in short time.

I’m leaving for the weekend to get my bike ready for the season and bring it up to school, but you can bet there will be a flurry of activity next week, killing this bug plus starting work on collision detection!

Stay tuned!

– Adam


So lots of news with Black Engine. Some good some bad.

The good is, I’ve brought on one new developer Naxos, who is going to be helping code, and working on brining on at least one more, Crazedbrit.

The release of v.6 went over really well in my opinion. It got a ton more attention then any other release so far. 76 downloads in the first 4 days. Not bad for an engine in such early stages as Black Engine.

Now the bad. The BSP unloading bug I’ve been hunting is proving to be an exceedingly elusive memory corruption issue I believe. I’ve eliminated a few very stupid stupid bugs already ( deleting stack allocated memory, derived classes not having virtual destructors ) and caught quite a few potential memory leaks. I even get a level to unload and reload now and then, but it’s just luck, there is still severe memory corruption some where so after loading the new level it dies quickly.

Also, in the process of hunting this bug I have found a rather… large. design flaw having to do with an Element failing to register with the Element Manager Service and thus having to delete it’s self but being unable to do so. I’ve been discussing a few solutions on the gamedev boards but none of them are very elegant. So we’ll see where that goes.

All in all progress is being made though. And hopefully I’ll be able to crush this memory corruption bug soon.

– Adam


Well v.6 is FINALLY released.

I cut out a few things I had wanted to get done so I could finally just push it out the door.

I will post a more complete summary of the Road Map ahead as well as update screen shots where they exist tomorrow.

Also I’m looking at bringing on another developer during the development of v.7 which will be awesome if it works out.

v.7 is going to be a lot of improvements in many many areas as well as adding in the last features required to make a game with the engine.

Any way I’ll spend more time tomorrow on this.

– Adam