sponsors gamedev.net search:

Introduction 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: Object Oriented Design: Handling your Renderer object in a seperate DLL environment allows for a more flexible object orientated implementation of your game/application. This layout would enable your small team of programmers to easily see the readability and reusability of seperate code modules. Shipping Updates: By structuring your rendering code this way, you are creating an easier environment in which to ship updates to your customers. Instead of having to recompile your libraries and executables, you only need to ship a newer DLL (Note: provided of course that the "external" interfaces to your DLL do NOT change; only the implementation code inside the classes contained in the DLL should be modified). Educational: Although this response is similar to the first one, basically this can be viewed as a "cool" exercise in computer programming. Not only will it wow your friends, but you will come away from it learning some new tricks that are not only applicable to your game, but also to software development in general. 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. Getting started 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. Requirements: Visual Studio 6.0 (can function on Visual Studio .NET as well) The DirectX SDK (if you want to implement the renderer in Direct3D8) The OpenGL headers and libraries (if you want to implement the renderer in OpenGL) Willingness to have fun! 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). Design Patterns 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: create and initialize the graphics hardware clear the screen start sending primitives to the hardware finish sending primitives to the hardware change the screen clearing color destroy and cleanup our graphics hardware 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 [1], 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. Static .lib and the DLL

Contents   Introduction   Static .lib and the DLL   Conclusion   Source code   Printable version   Discuss this article The Series   Part I   Part II   Part III   Part IV