Work++; // Again!

I’ve been slacking. No, really, mega slacking. Its been almost two months since I wrote something here. Earlier, I wrote about my latest employment opportunity at PWLabs. Well, that job ended abruptly. There was nothing wrong with that job, I enjoyed it fully, but several days after I started, I got a call from a recruiter that works for McAfee (Yes, the anti virus maker). Impeccable timing! He hooked me up with the dev team at McAfee and we had a phone interview. That, eventually, blossomed to a full 5 hour interview (you heard me correctly, 5 Hours!) where I took two tests on top of an in-person interview. Needless to say, I got the job and my brief career at PWLabs came to a close.

The stuff that they have me doing right now is guarded with an NDA, but its mostly going to be Win32 programming. My experience at BumpTop and at Strike Technologies helped me get my foot in the door. I always avoided huge Corporate jobs but this one actually made me excited.

For those that don’t know, McAfee’s engineering department is located in Waterloo, so the drive from Toronto is a bit time consuming. I ended up buying a 2008 Hyundai Accent for the trip, it’s not a bad car. Nevertheless, I will be moving down to this area eventually. Some places that I was looking at are in Cambridge, Kitchener, and Guelph. But that won’t happen for a few years anyway.

Patterns And Such.

I ended up having to refactor some of my rendering engine code this weekend. It was a tough job and it involved stripping several classes of their Singleton status. The first couple were easy because they don’t connect the any crucial system. One of them being a Logger that writes error messages to a file and console window. The last class I had to strip was my Event Manager system. Now, to put it in perspective, every hefty class that has a major role in the rendering engine (ie. Renderer, Windowing, Resource Manager, etc) needs to notify some other part(s) of the system of an event. For example, if the user resizes the window, the window class must then notify the renderer that it needs to resize its back buffers. But, the window class does not know of the renderer, so everything would be routed through the Event Manager. In order to send events through it, without coupling the Event Manager to any other classes, I used the Singleton.

It worked great! Until I tried to multi thread my renderer or place the rendering portion of my code inside a DLL. Hell broke loose and my whole architecture failed. Back to the drawing board I went. As a side note, when I started searching for a new way of dealing with this, I came upon a really cool website which proudly displayed this image:

Hilarious! I thought, Who would of thought that Patterns can be displayed in a periodic table. But that was beside the point. I eventually came to the conclusion that one must make a singleton but without a singleton. My solution was this: Create a Factory that spits out message dispatchers, but with a slight twist. Only spit out a pointer to the same dispatcher over and over, therefore creating only one instance of that dispatcher for all objects that want to use that specific Event subsystem. Why, you may ask. Because that lonely dispatcher knows how to communicate with the Event Manager. As the Dispatcher was being created by this factory, it was given a pointer to the manager. So now you have a direct link between a Dispatcher and the Manager. Lastly, all you need is an Event Listener. This listener takes in a pointer to a dispatcher and since it knows how to contact the Manager, it registers itself with it so that it may receive messages. All the programmer has to do is derive a class from this Listener class and it automatically has the capabilities to send and receive messages. To an extent its a fancy version of the observer pattern. I especially like this because I just replaced a Creational pattern with a Behavioral pattern.

This is not the only method I came up with, but its the cleanest one. Although, it sounds like there could be problems with memory management and loose pointers, but I do not believe so. I posted a question regarding this on GameDev, and there was a plethora of responses. I used that as my platform to kick off searches that were more in depth then what was talked about.

On a different note, I used a program called StarUML to model my entire engine. The results are here, but I must warn you, its big, its complex, and not quite finished. Feedback is always welcome as I am always looking for ways to improve it.

Work++;

Some of you may know already that I have received an employment opportunity from a company called Parallel Worlds Labs (PWLabs). I took the job without hesitation for several reasons. Firstly, my yearly salary was increased substantially. To some, this might have been enough to switch companies, but for me, it was not the main reason. Secondly, PWLabs makes 3D, interactive games and displays for museums and other such institutions. I saw this as my chance to pursue a career in Game/Graphics programming. Lastly, its mostly a work form home job, so my commute time is cut down from 40mins to about 10 seconds (The time it takes me to walk into my living room). So, as you can see, I am thrilled to start my new job.

Unfortunately, this will mean that I will be leaving my ever-vigilant post at BumpTop. The last year flew by quickly and from my perspective as a code monkey, it was not a bad job. Code was my passion and focus. I literally re-wrote the vast majority of BumpTop, made it stable and robust, and its something I would definitely put on my portfolio.

SIMD And Randomness

Alright, I ended my zealous trek through the inner workings of SIMD just because I wasn’t using it enough in my project. Don’t get me wrong, its a really nice piece of technology to dabble in, especially when doing math on a large scale (say, Matrices). But for the day-to-day programmer in me, I really don’t get to use it as much as you might think.

But, I’ve done some detective work and most compilers nowadays optimize the code in such a way that SIMD gets incorporated automatically. Therefore, learning SIMD should be put in the same category as learning Assembly. Its nice to have but in reality it will be rarely used, if ever. I have a feeling that I’ll run into a situation where SIMD is required and its the only thing that can save the world from total destruction. Well, until then, I’ll just shelve it.

On the bright side, I finally gave my game/rendering engine a real name: ‘Radiant.’ I don’t know why I named it that, and for some reason, I never second guessed it. It was one of those spur of the moments that I hit F2 and started typing. Don’t ask me what or why, I’m still in the wilderness on that one. Anyway, progress on the engine is a bit slow just because the only time I get to work on is during bus trips to and from Hamilton, or other places. If there were more hours in the day, I could actually get something done.

I should also say that I’ve re-worked the way the engine is laid out because all my singletons were not working well with DLLs (I think I wrote about that, somewhere). This quickly because a mess. SVN likes things to be done in order and in small chunks, else it starts bugging you about cleaning up the repository. I like to do things in big chunks, literally taking a +1 Battle Axe to the tree and then rebuilding it from scratch. Bad tactic, I know. Lets just say, SVN was in pain. Poor thing.

As a side note, I found out something interesting today about the MSVC build system; It supports multi-core compilation! Its like your own distributed build but on your own machine, Hooray. More on this later.

Coder Burn-Out

Its been a while since I wrote something here, and with good reason. I have gotten to the point where I do not want to look at code when I come home. I am on the edge of burning out. Thankfully, my vacation starts in a few days. But this blog post is not about my fun-in-the-sun vacation, rather its about the politics of being a programmer.

A few days ago I had a conversation with a friend about coder burn-out. Most specifically, should a manager push the programmer to the brink of burning-out in order to move the project along? I say, yes. To a point. Pushing a programmer to work that extra bit is natural, and happens quite frequently in the industry. It gives that extra boost when the projects needs it. But, it is similar to adding nitrous oxide to an engine to get extra horsepower. If you don’t give the engine a break, it will break down. Pistons will seize, gears will grind, and the engine will come to a screeching halt. Much like an engine, all this can happen to a programmer (just it wouldn’t be as violent, at least, I hope not). From personal experience, when a burn-out happens, I cannot look at code. It literally makes me unproductive, sluggish, and resistant to coding. Moreover, I start to neglect personal projects and duties (such as this blog) that once made me happy.

Fortunately, I am nowhere near the point where I hate programming, but my pet projects have not seen progression in weeks. My vacation is coming up and it will be a breath of fresh air into a stuffy room. What I am wondering is, how do other people deal with coder burn-out? What are your strategies or things that you do to relax and get your bearings back?

Some GameDev Math Resources.

I’ve been scouring the internet for some decent resources on math, collision detection, and physics, so here are some:

More to come, later.

Real-Time Collision Detection

With all the craziness that last weekend brought, one of which was a book I ordered from Amazon. Just like the title says its a book about collision detection within 2D and 3D environments. It’s a bit on the expensive side, about $50, but its worth every penny. I had a chance to read the first 5 chapters on Sunday. It started off with a quick math primer and then dove head first into how collision detection works. It has a few chapters on bounding volumes and space partitioning; the two topics I have been obsessing over for the last few weeks.

Possibly the best thing about this book when compared to my other math books is that it explains the concepts with code, more then with math. For most programmers, this is a godsend. Reading a few lines of code is much easier (at least, for myself) then trying to comprehend or remember mathematical symbols.

Regardless, If you’re building an engine of some sort (Graphical, Physics, etc), this book is definitely an asset. Collision detection is not only used in physics engines, it is the core functionality of Octrees and Scene Management. Ergo, it is an integral part of an engine. Although, I don’t recommend this book to novices, or people that do not have any 3D engine building knowledge under their belt. It is Math and Algorithm heavy and requires substantial engine design theory.

EDIT: Looking through some of the supplementary books from the Morgan Kaufmann series, they all seem very interesting. If those books are of the same quality as the Real-Time Collision Detection book, then this entires series of books will end up on my bookshelf very soon. It’s something to be desired.

To OSG, or not to OSG.

I have been working on my game engine (Which still does not have a name; Suggestions are appreciated) for a while now. It has seen its share of refactors ever since I started on it back in 2006. But recently, I have come to a fork in the road. I am overwhelmed with the amount of things that I need to keep track of which makes me second guess some of my design decisions that I have made. One of which, is weather or not to write my own scenegraph or to use a stock one, say, OpenSceneGraph.

From experience, I can tell you that the amount of time that it would require to learn, implement, and test OSG’s implementation would be comparable to the amount of time it would take me to write one from scratch. I have been plagued with these sorts of decisions ever since I started the rewrite of my code. The benefits of using a library over writing your own can only be determined by the ease of use of the library. For example, if its easy to build, incorporate and debug then it probably is better to choose it then to write one from scratch. In the case of OSG, the library is big. No, its Massive!

I am still not convinced that OSG would be worth using over my own implementation, simply because of the learning curve and the work required to properly incorporate it into my engine. I would literally have to wrap my engine around OSG, rather then have it work symbiotically. That just does not sit well with me. Regardless, I will still poke around inside OSG and learn how their scenegraph implementation works.

Where is my trusty Bearded Axe, its time for some hacking!

The Moz Cause

Being an avid slashdot reader, I read a lot of stories that are mostly based off fact. Then again, some are based off of total trash. I have witnessed the lack of informational prowess by story writers, but in this latest case, I don’t know where I should stand. The article in question is about the Acid3 test that browsers are benchmarked on. According to this story, Safari scores 90% and my favorite browser of all (Firefox) scores a mediocre 69%. This tells me one of two things, either the story is a complete joke or it’s a bold statement about Firefox’s web compliance. I have use Safari and I am not very impressed. It has many flaws that hamper my browsing experience (such as tables not being aligned correctly, flash issues, colors, etc). But those are all small things and if this Acid3 test is the industry “standard”, then I say its not much of one. I believe it might be favoring the Safari side or that it was built off standards that Safari developers pushed forth. In essence, a standard is a standard is a standard and should be taken with a grain of salt when trusting it’s verdict.

Et Tu Singletone.

Seems that my favorite pattern is also the bane of my current Game Engine development. Turns out that a singleton pattern doesn’t like to play nice with Dynamically Linked Libraries. The whole notion of being dynamic is counter productive to static members inside functions or classes. Looks like the only way to actually fix this is to wrap it all up in a big handler of some sort and have the calling code manage it. Either that or create a section of shared memory in the DLL and allow it to manage the singletons. Seems like a bit of a pain in the butt just to avoid a global variable. Hmm, unless I can wrap it in another creational pattern, possibly Builder or Abstract Factory…

More research is required. And research requires Tea. Therefore more Tea is required.