I can't seem to grasp the concept for these two. Can they even be compared?

A .lib uses static linking and there is no need to include the .lib files for the end user right?

As oppose to a .dll which uses external linking and is a required file for the end-user to run your program.

Are they the same aside from these 2 differences? Both of them provide functions and resourcesfor your game. I suppose .DLL's would be useful as a resource if you were make updates to your game, instead of making the user re-download the entire updated game, you can just have them download and replace the old .dll file?

Would that work? Can you load resources into .lib or .dll fles? Resources such as Bitmaps or Midi files? I would be nice if the game was just a .exe and a .dll for all the resources.

I am developing my game, all my functions are in header files and all resources are saved externally. Would like to put some of the resources in .dll's or .lib's. I can't ignore these 2 file types forever... Gotta learn em.

Thanks in advance.

You can load resources from a DLL, but it's not exactly trivial and since you need an rc file it sort of makes it Windows Only.

You could always rename a zip file to dll and use physfs to open it :p

Using a DLL just for resources is not very common, most games use some other file format for that. Other formats tend to be easier to use, and also cross-platform.

As for .lib files, IIRC you can't put resources in them (they are just a collection of .obj files). But you can put them in the .exe, as .exe files have the same format as DLLs. The process is described here. This is most commonly done with the main application icon, so that Windows Explorer, etc. will show it as the icon for the executable.

What are .dll's used for? Storing methods for classes? Datatypes? I am getting the picture .dll's are for windows applications and is not meant for games...

.Libs are used more often. But isn't it the same thing? Just a bunch of methods, data types and classes for your game? I want to impliment one or both in my game. I am getting sick of putting all my function defintions and classes in header files.

You can store data in .dll's if you want, and they are sometimes used for games (allegro for windows creates alleg<version>.dll by default).

A static library file is used at compile time to include the function binary code that your game needs right in the .exe. DLL files also need a "lib" file to export the DLL names of the functions, but your game only has those names/identifiers rather than the code. The DLL will have the code in that case, and your game will call those functions. If you make improvements to a game engine, you only need to provide a new DLL rather than an entire new exe. OTOH, calls to DLL's are somewhat slower (not a problem if function takes significant time itself) and DLL's tend to thrash the cache due to always being loaded on a 4096 byte boundary.

IMO, DLL's were mostly useful back in the days of 4 megabyte machines, since many programs can use one dll for various functions, and the dll only takes up memory once, rather than a big block of code in each exe.

You are mixing things up. A .lib file is a file used at compile time. It can be statically linked in your program so that no DLL is needed or it can be a dynamic .lib file in which case when the program compiles it will need a corresponding .dll file to function.

Why are .dll files used? Well, for one thing, you could have a .dll that handles networking stuff. So when a bug arises in the networking code you would just have to give your users the updated .dll and they wouldn't have to download the whole game again.

Another thing is common dll files like kernel32.dll, user32.dll, etc. If it weren't for dynamic linking you would have to statically link all these DLLs in your program or ship them with your game adding unnecessary size to your game. But because these are dynamically linked at program startup and are available in every Windows installation you don't have to worry about them.

So, .lib files are used at compile time, .dll files are used at runtime. For more on .dll files, see the Wikipedia entry.

EDIT: beaten.

well if its the windows port of a game we are talking about many or most have them(dlls).
but it's not a rule.Sims 3 doesn't have any but GTA4 and Neverwinter Nights have them.

What coding does a .dll store? Function definations? Methods? Classes? External data types?

Using a search engine would be faster, easier and more convenient than asking here.

Everything you mentioned can be in a dll. Allegro 4/5 is in a dll. A virus could be in a dll. Basically, a DLL is in the same format as an PE file (.EXE) so everything that can be in an .exe file can be in a .dll file.

Again, read the Wikipedia entry.

EDIT: beaten again

lin lin, you shouldn't bother creating DLLs for your game. If there is a bug in your game code, just give your users a new .exe. And use .zip files or something for data. Or load the files directly from the original files.

Thanks for the advice guys. One last question...

I've read some documents regarding .dll's and .lib files. It's just like building an exe except the output is a .dll or a .lib instead. I've seen people have function definations, declarations and methods in these lib files.

I've been doing the same thing except I've been using header files.

Headers:
#include "Function prototypes.h"
#include "Function definations.h"

Is it almost the same thing? Should I bother using .libs instead? Both .lib and .h are static linked. So I don't think there's any advantages as far as space is concerned.

Tell me if this may be a good idea:
I can use .dll for levels and items. When the time comes I can release a "demo" which has level.dll... As the demos expand I can add more .dll or keep updating the old one without having users re-download and re-install. My issue is does this have to be a .dll? I can design my own file type .lin and have the game look for this file the same way it'd look for using the previous method. .dll can be shared by all programs, but my program is the only one that'll be accessing it. So I imagine I can just create my own file type and do the "updates" for each demo instead of venturing into unknown grounds...

I do want to learn more about them though, I just can't think of a good use for them in game development. Allegro uses .dll's but allegro isn't a game is it?

Sorta. Only putting a lot of code in headers is bad.

Header files are to define things. No executable code or instances of data should be in those. That's what the 'c' or 'cpp' extension is supposedly for.

DLL's allow you to break your exe up into separate files, not just one big chunk. One single DLL can be used by more than one exe. If you compile all the Allegro examples statically, each file will be several times the size of the ones that link to the DLL, since most examples only have a small amount of code compared to the size of the Allegro library.

Very interesting, up till now I've been using header files and 1 .cpp file. I keep the function definations in one .h file and prototypes for them in another. My .cpp only has the main loop for the game with all the function calls directed towards header files.

It's been working fine so far I don't experience slow downs or breaks.

I had a feeling having all these headers was a bad idea...

You can give them the txt extension if you want, but common practice is to not put code and actual instances of data into header files.

Headers are fine, but putting code in headers is generally considered a bad idea^[1].

I see. Thanks for the help. I am looking up some tutorials on making simple .dll's for console first.

I am programming an FF Tactics clone. However, I don't want to release demos, instead it's better to release it in modules. For example, the first release will have world 1, second release some time later will add world 2.. etc.. etc.

.Dll's would be a good idea in this situation since I don't want users to keep re-installing every update. I'd just have them download and replace the old .dll's. I can't do this with .libs.

Just in my mind I don't see how a .dll is any different compared to me just making my own file type (.lin) and have the .exe look for this file instead. Sure it can't be shared like a .dll, but my program is the only thing that would be calling it anyway. Maybe your right... .dll's have outlived their usefulness years ago...

If levels need special code, releasing them in a dll would work. But I imagine that you won't need a bunch of special new code per level (maybe some levels..), so you can just release data files for the game to load.

Can you give me your opinion on what kind of files you guys prefer?

Do you make your own file types? Use .dlls? .libs? And what do you use them for?

I make new data formats all the time, but I only use the object files produced by compilers and assemblers for code. I don't even bother stuffing them into a library.

I use physfs, which supports zip, directory, pak, etc. I don't yet know what I'm going to go with for my final release... I haven't decided yet if compressed or uncompressed will be better. On the one hand compressed files are smaller, but then the files load slower. It depends on whether or not our slowest target device can keep up while loading from a compressed archive or not.

I'd vote for uncompressed (at least for PC) because disk space is so ginormous these days. Zipping up the whole thing for installation takes care of the bandwidth problem when downloading the files.

Yeah, I'd think if loading was an issue, you could support both compressed and uncompressed, and on the slow devices, have it uncompress the data on install.

Those are some options, but I'm still not decided and won't be until I do some testing further along. I already think we may have to drop what was our lowest target device, since loading the amount of graphics we load per level from flash on that device is terribly slow. So it might be 3rd gen iGadgets and above, as far as those devices go. No clue about android, and the others, it doesn't really matter because they're plenty fast either way.

So .dll should optional, but .lib should be highly recommend right?

Since putting all those functions in a header file is considered a bad idea. Every game should be static linked with .lib files. While .dll should be optional...

I just don't want people going in messing with my code. If I have a .dll file with all the character stats on there, they can go in and motify it. My own format would help to prevent this.

If it's a network game, keep the stats on a server where they can't mess with them. If it's not a network game (single player) what's the problem with them messing with them? They're only cheating themselves at worst, modifying the game to make it more fun for themselves at best.

Hey off topic question.... Anyone know a good place you can find sprite artist? Are they a rarity? Can't seem to find any that are that good..

There is some decent art on http://opengameart.org... but you're unlikely to find EVERYTHING you need for a complete game.

.... wait a minute..

Isn't the .dll's encrypted? You can't just open it in Visual Studio because it's a compiled, linked, binary product, just like an exe.

Machine code isn't "encrypted" except in the sense it's readable by the CPU rather than humans. If you put human-readable stuff into a DLL you could read it with any hex editor/viewer. There will probably be a few function names you can read even in a code DLL.

I can't help but thinking that lin lin doesn't yet understand how C++ programs are built from source. Does anyone have a good reference to that?

What you suggest I do? if I want to use the .dll for new levels but I don't want people opening it up and messing with it?

I could create the .dll first then have a program that encrypts it.
Ofcourse only I will do these two steps.

The end-user will receive the game. Before the game runs it'll look for the .dll decrypt it and then run normally.

I wonder.. If I am willing to go through this much trouble, might as well just make my own file type...

Go to Wikipedia and read about these topics:

• Compiler

• Linker

• DLL

• Library (then choose computer library or similar)

• Assembler

• Machine code

A lot of reading, but believe me, you need it.

First you have to understand what a DLL is. You don't put levels into a DLL.

So how does C++ building work? C and C++ files are compiled into object files, which contain relocatable machine code. Typically these files are *.obj (or *.o on linux). Next step is linking into an executable file, which means to throw all the object files together and resolve all open symbols (like function calls and global variables). Result is an executable. Collections of object files can be put into a library, typically *.lib (or *.a on linux). Such a static library is exactly that, a collection of object files to link with. Primary purpose is to keep linker statements shorter, and have libraries which are good for reuse in more than one project.

Shared libraries are working quite differently on Windows and on linux. On Windows they are DLLs, on linux *.so files. A special thing on Windows is the fact that a DLL looks very much like an executable files, but in the end, it's just a shared library, which is only loaded when the starting program (which is a *.exe) loads the DLL. This can be during startup or by dynamically loading the DLL as needed. Either way, loading the DLL involves a link step, and after that, the executable in memory is completely linked, all symbols resolved and relocated, so it can execute.

To answer your question, it's mostly a matter of taste, if you prefer static or dynamic libraries. Linking large programs can become really slow, using DLLs can help a bit here. On the other hand, the programs that you typically write, compile and link within seconds or a few minutes, so there's no problem. Using static libraries makes the executable look bigger, but it's self contained (doesn't need to resolve symbols during runtime). Using dynamic libraries means you have to distribute them, and their summed sizes are bigger than the executable alone. None of this is an issue these days.

I'm going towards static libraries for my own projects, especially when I try to go for Allegro 5, makes things a bit easier for me.

Put your game content into directories and files that you can easily read, like using load_bitmap. You will have your original data somewhere, and at least during development it will be so much easier to read those files directly, in comparison to introduce another build step that packs your original data into any sort of pack, zip or whatever file to read in in your game.

Levels in DLL? Maybe it is better to try data driven game, same code base with different data will result in different game.

I do not thing it is wort to encrypt game code unless you are planning to use some fancy DRM mechanism. (Yeah, people will not like you for that.)

Don't bother about code encryption unless you have to. People when want, they open it anyway. If you really want encryption, make a proxy interface for all I/O operations and after your game is finished encrypt data with SSH or some other method and implement different I/O proxy which allows you to read it.

Bottom line is, you code and assets will not be protected enough unless hardware guarantee that and regular PC, Mac, iDevices and other popular platforms do not have such feature. So sorry, you have to live with that.

Regarding something mentioned earlier, about only definitions/declerations being in header files:

I put all of my class definitions in header files, and all the class functions go into a .cpp file; however, sometimes if there is an extremely basic function in a class that simply returns a class member, I put that into the class definition in the header file:

class clsMyClass{
  protected:
    int mi_XPos, mi_iYPos;
    BITMAP *mbmp_Image;

  public:
    clsMyClass(int ai_XPos, int ai_YPos);
   ~clsMyClass();

    void moveLeft(int ai_Amount);  //Code for this goes into .cpp file
    BITMAP *getImage(void) const {return(mbmp_Image);} //Simple so gets put here 
};

Would this be frowned upon? Should ALL functions go into the .cpp file, regardless of complexity/number of lines?