Pseudo Random Journal Generator Predictable permutations on programming, technology, and more.

adam_01may2007.plan

It may be that I'm running on only 2 hours of sleep but debugging is especially frustrating to me today.

Any way, a few days ago I solved several more big bugs which allowed me to load, unload, and load another level several times before it crashed.

Then I ran it through valgrind again to identify more trouble spots. More spots found, and fixed today. Pretty much the last memory corruption bug now has to do with the Camera class deleting it's Scene Graph Nodes. It is a bit of a special case so it makes sense it is the one causing problems. But I have been over it and over it, fixing little logic errors associated with very obscure code paths along the way, and I can't find a single thing wrong with it now. It's very frustrating.

Once that is solved ( some day ) there is quite a bit of memory leakage happening. Mostly obvious stuff. Part of my texture memory, a temp buffer during creation, isn't being deleted. It should be pretty quick to get most of that under control.

A few steps forward. But so much has been revealed to me during this debugging that is necessary to make the code base clean. I'm going to be spending a lot of time cleaning and refactoring...

- Adam

adam_28apr2007.plan

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

adam_11apr2007.plan

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

adam_08apr2007.plan

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

adam_03apr2007.plan

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

adam_31mar2007.plan

Haha well, another blown dead line. I did code for a few hours today, got a lot of polishing done. But then I went over a friends house and started grilling and drinking, so I didn't get to finish everything.

Any way out of a list of 10 things I checked off 6. One of the things left to be checked off would be better implemented if I just sucked it up and went ahead and finished something I was going to hold off on till after the release. I don't think it will take too long to implement any way so might as well do it the right way the first time.

It's really starting to get kinda exciting watching everything finally take shape.

But I'm going home for the night tomorrow so don't expect a release till maybe Sunday.

Oh well...

- Adam

adam_29mar2007.plan

I put in QUITE a few hours today. Encountered some very frustrating problems, but long story short is the new camera system is implemented.

Going to take some tweaking and polishing, but I have the engine loading into a menu, then from the menu, then you select the map you want to load by pressing the correct button, it loads and you go from there.

I still have to work on cleaning up the memory and changing maps and just lots and lots of little polish things. Here is the list of polish left before the release:

- Finish Texture manager memory manager

- Polish memory clean up code for unloading BSP maps

- Implement new controls to go back to the menu system

- Re-implement FPS HUD 2D elements into the new camera

- Re-implement vertical movement hack

And thats it! I plan on having 2 maps in the new release which you will be able to select from the menu. And if I get enough time maybe I'll work on new menu graphics because the current ones SUCK.

I'm freaking wasted. Night.

- Adam

adam_29mar2007.plan

Well I hooked up and debugged the new camera system with the FPS camera. Then I used the windowing system to design the first version of the main menu. This required finally implementing the last part of the Mode Service which I had been planning for months. So now there are two distinct game states which are managed by the mode system.

So now you load into a menu, load a map from there, then once loaded, you can press escape to return to the menu, and from the menu you can exit the program.

I also went through and implemented (but as of yet have not tested) the more advanced memory management for the Texture Manager.

That is about half of the polish and tweaks I have slated for this release. So expect to see a release probably late tomorrow.

Also it's my birth day, so no more work will be getting done to night!

- Adam