|
General:
Making DLL Components
By: Jack Hoxley
Written: May 2000
Download:
Gm_dll.zip
(39kb)
DLL stands for Dynamic Link Library,
and it is also the 3 letter extension used for the file type. Basically it is
a collection of procedures and functions that can be used often and by any language
(to a certain extent). The entire windows API is made up of DLL's, look through
your system folder and you'll find upwards of 600 different DLL files. Most
of the directX files are DLL's.
Windows comes with lots of DLL's,
almost all of them are the API, the rest that you'll find are probably for other
applications. They are used to extend the programs that they are associated
with, by offering new functions and optimized code. One common use for DLL's
is to simplify the original program;
Say you had a memory access program,
that used lots of extremely complex maths formulas. If you needed to use it
often you would make a procedure to handle it - but it would still be in the
original EXE program. If it were in a DLL it would work the same, but it would
be independent from the original EXE; this would allow you to update it without
having to recompile the exe (more on this later). The main advantage is that,
in vb, you would only have to declare the DLL in the declarations section and
you could call the procedure from anywhere in the program, and not worry about
it cluttering up your project.
The second advantage is that
you can rewrite it. This effectively allows it to be patched or upgraded in
the future - something every PC-games player will be familiar with. You could
write a game, distribute it, then find an error in the code - maybe something
that only affects certain computers. You would then have to rewrite parts of
the core-code (the original program), re-compile it and then redistribute it;
possibly quite awkward. If however you'd designed it to be modular you could
just rewrite the graphics DLL (assuming it was graphics that was to be changed),
then redistribute that file. Doing this could also mean that you can customize
the game for everyones individual needs. For example, person X has a super-computer
that can do perfect 3D rendering, but has a poor soundcard - and cant use DirectSound
or Music. You could write every DLL in the form of DirectX 5,6 and 7, or using
the API (which almost every computer will support). With this structure you
could then allow your person to pick-and-choose which engine they use (engine
= component, ie. API or DirectX).
The other part of this is that
you can advance your game after release. If you worked out that there was an
amazing optimization that would speed up gameplay - rewrite the DLL and send
it off to the people. This can also link in with new features; such as mods
and upgrades (common in Quake/Half-life/Unreal Tournament). Also, if you shared
the structure of your DLL with others, they would be able to rewrite parts of
it - without stealing to many ideas, or destroying your game.
The third advantage is that the
DLL can be written in a different language. This is a little bit more complicated
to implement, but can have amazing advantages. If the whole game is written
in visual basic, you are limited with it's short-comings and any disadvantages
inherant with the language. In particular memory access in vb, which I find
can be very slow - but on the other hand, C/C++ memory access is blisteringly
fast (in comparison), and again, Assembler can do some incredibly fast maths
routines. This ability can allow you to pick-and-choose the best parts of each
language. I find that VB is much easier (and more fun) to program than C++,
but I like the memory access and inherant speed advantages of C/C++; because
of this I would write some parts of a game in VB (the core structure) and the
low-level maths and other complicated things in C/C++
Now onto the code. The attached
Zip file is much easier to understand, and it would be confusing to look at
the code in anything but VB itself. You can download the file from the top of
the page, or from the Downloads page.
The DLLs that we will be using
aren't actually proper DLLs - their activeX DLLs. Hopefully Microsoft will implement
proper DLL writing in a future release of visual basic. The ActiveX DLL is basically
a remote class. You write it the same as you would if it were a normal class
module in visual basic. You can then access the functions and procedures in
the Class module (now a DLL) in your main application.
To allow you to update it without
confusing vb (it expects a certain version of the DLL - which changes each time
it's compiled), you need to set an option for the DLL so that it is Binary Compatable.
You can find it under the component tab in the project properties
window. But before you do that, compile the DLL without this option - you
dont need any code in it yet. You now have a useless DLL (wow!) - then go back
into the properties and set it to be binary compatable, and in the little text-box
point it to the precompiled DLL. You can now add as much code as you like and
VB will never no the difference.
One warning though - you must
keep the functions/procedures the same; or at least, never delete any. If you
use the DLL in VB and you call the procedure "INIT", but it isn't
there, VB will kick up a stink and probably stop your program from working.
You can add procedures, as VB wont ever want to call them, but you must keep
the original procedures the same - including any parameters to be passed to
them. If you think that you'll want to add more parameters in the future put
dummy paramters in the original -
sub INIT(Screenwidth as integer,ScreenHeight as integer,Depth as integer,
Reserved as string,Reserved1 as string)
In this line you'll notice the Reserved and reserved1 parameters,
this means that in the future you'll be able to make use of these parameters
- assuming you can pass them as a string.
Go look at the projects in the
Zip file - they are well commented and will help you understand this tutorial.
|
