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 »