Well if you've been hanging around the DirectX newsgroup for any amount of time, you'll notice and/or probably discover that one of the most discussed topics (besides OpenGL vs. DX) is concerning questions about using classes and/or interfaces with DLL files.
Currently, Gamedev.net has one article dealing with using DLL files with classes, written by Gaz Iqbal. It's an excellent starting point, and I urge the reader to peruse that document first. This is an attempt to build on that document, while at the same time demonstrating the power at our fingertips.
Why use a separate Renderer DLL?
Some may be asking that question to themselves right at the moment. Although everyone has their own reasons, I'll attempt to answer a few of the ones that strike me as being the largest:
Why not use COM?
A few others might be asking this question as well. My first response to that question, would be that COM is a pretty advanced topic of discussion. Most "newbies" are still getting used to some of the most basic concepts of Object Oriented design philosophies, without having to worry about picking up COM. Provided your product is targeted solely for the Win32 environment, COM could be the ideal solution. The targeted audience for this paper, however, are the programmers who are on the road to understanding COM, yet not quite there yet. Another response to this question, is that COM is Win32 dependent. If you are a Linux developer, then you are outta luck with COM.
I am one of "those" types of people that need to see a clear example along with the explanation. Because of this, I've attempted to provide as much clarity for this article as I can. The goal of this paper is to create an example DLL file which we can use in a, or indeed any, game.
In order for the DLL to function properly, it is paramount that we isolate ANY graphics code from our main library. That way, should anything change in our DLL, then (most of the time) NO modifications will need to be made to the library, and vice versa.
What we're going to do is first create a static library holding our engine/framework structure. Within this project, we are then going to create a DLL project, in order to implement the rendererInterface object interface.
Now for the most part, most of you will have all of this already, right? Right. If you're using Borland, then I'm 80-90% sure that this "method" of DLL implementation will work as well. (I'm endeavouring to keep it non-compiler specific as much as possible).
For those unfamiliar with the concept of Design Patterns, they are a useful tool in the world of Software Development. They are an approach to solving specific object oriented problems.
The goal of our class framework is to create an object that we can use independantly of the actual API. So in other words, we want to be able to use an object which will give us the ability to freely call its methods, without having to worry about "proper" Direct3D or OpenGL calls. This kind of abstraction is, and can be, a great benefit to our game engine design.
The more astute of you will immidiately realize that we will need to create a base class which will contain the relevant methods for our rendererInterface object. In OO terms, this "base" class can also be called an Interface.
I'm not sure if this is the "OO correct" approach, but my common method to designing an interface class, is to first jot down a few things that we NEED it to do. For our example, we'll keep things nice and simple. It needs to:
See?? Nothing tio complicated...hehe
The design pattern which seems to best fit our needs is called the Abstract Factory design pattern. According to Gamma , the official definition of this pattern is to:
Provide an interface for creating families of related or dependent objects without specifying their concrete classes
Which is our intent.