You are currently browsing the CodeBot @ Work weblog archives for June, 2008.
- 3D Stuff (6)
- BumpTop (5)
- C/C++ (12)
- GEL (5)
- Open Source (5)
- Seneca (4)
- Stuff (8)
- Uncategorized (14)
- win32 (7)
- July 31, 2008: Work++; // Again!
- June 8, 2008: Patterns And Such.
- June 4, 2008: Work++;
- May 20, 2008: SIMD And Randomness
- April 30, 2008: Coder Burn-Out
- March 26, 2008: Some GameDev Math Resources.
- March 24, 2008: Real-Time Collision Detection
- March 17, 2008: To OSG, or not to OSG.
- March 9, 2008: The Moz Cause
- February 12, 2008: Et Tu Singletone.
Archive for June 2008
Patterns And Such.
June 8, 2008 by Mark.
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.
Posted in Uncategorized | No Comments »
Work++;
June 4, 2008 by Mark.
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.
Posted in Open Source, C/C++ | 2 Comments »