Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
84 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:


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.


  1. Visual Studio 6.0 (can function on Visual Studio .NET as well)
  2. The DirectX SDK (if you want to implement the renderer in Direct3D8)
  3. The OpenGL headers and libraries (if you want to implement the renderer in OpenGL)
  4. 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:

  1. create and initialize the graphics hardware
  2. clear the screen
  3. start sending primitives to the hardware
  4. finish sending primitives to the hardware
  5. change the screen clearing color
  6. 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

  Static .lib and the DLL

  Source code
  Printable version
  Discuss this article

The Series
  Part I
  Part II
  Part III
  Part IV