My apologies in advance if this is an obvious/stupid question or if I've posted this on the wrong board. I'm an Allegro newbie, but I've done some Googling and forum-searching for a while and still can't come up with the answer so I thought I'd ask direct.

I'm currently making a game in Allegro 5 using Visual Studio 2010. I'd like to distribute an early version to a friend so he can test it, but it won't let him run the .exe file. I can run the .exe file on my own laptop as long as allegro-5.0.4-monolith-md.dll is in the same folder. On his computer it complains that it wants msvcr100.dll.

It appears to me that I'm dynamically linking to dlls and those will need to be distributed with the .exe when I distribute my game. From my research I've found that if I statically linked I could just send the .exe file with my resource folder (for images/fonts/sounds etc.) and that would work without any external dlls. Apart from not knowing whether what I've said this far is accurate or not, my problem is that I can't find anywhere that explains to me how to change from dynamic linking to static linking in Visual Studio 2010. There's lots telling me how to set up static linking on Code::Blocks, but I was originally advised to use VS2010 because I updating my game would be easier with that, but I now wonder whether static linking would remove that advantage anyway... I'm rather confused.

Put simply, my question is: what's the simplest, most professional way to distribute my game?
Should I use an installer for the finished game? (I've no idea how I'd do that)
Is there an advantage to dynamic linking that means I should stick with that, or should I switch to static linking?
If I should switch to static linking, how do I do that in Visual Studio 2010?
Once I've done that, do I just need to send the .exe & the resources folder, or will they still have to install Allegro or something else to make it work?

Sorry for the long newbie post.
Thanks to anyone who can help me out.

The simplest most professional way would be obviously a static link. distributing tons of dlls with your applications isn't professional.

That's not related with Allegro nor with Visual Studio. You should look for a free installer tool.

If you were creating your application and your application includes some libraries made by yourself, I would say that a dynamic link would be good since you can send just that dll in case there is a bug. Now, that's only required in very big applications/games. But a dynamically linking Allegro or another library that you program uses as a core part of your game doesn't make sense.

Put the case that the developers find a bug in Allegro: A memory leak when destroying .wav audio samples. Since you're using .vorbis files, are you going to send the new library to all your users? no, because isn't affecting you, otherwise you would have realized that there was a bug when testing your application isn't?.

Or put the case that Allegro release a new version with a new feature that your game could use, like Allegro 5.1 with the Shaders addon which isn't available in Allegro 5.0.4. You can't just send the addon you would need to send the .exe with the corresponding modifications too.

So I recommend you to always use static link to the core libraries that your program uses, since are less likely to fail.

For more info:
Static_and_Dynamic_Link

I have no idea... I use C::B.

There's nothing to install after a well done static link.

The most professional way to distribute your program would be to provide an installer.

The 2nd most professional way would be to have a downloadable zip file. Inside would be a readme.html file, a launcher exe with an embedded icon, and a folder containing all your game files, dlls if you have them, and the actual game exe.

3rd (which is what most of us have done) is to put everything in a zip, and not worry about creating a separate launcher exe or anything like that. Just let the gamer double-click program.

qft

Exactly. Having an installer for an Allegro game is like putting on a tie and bringing a suitcase to an interview. There's really no point.

Haha, and in most cases the interviewee is slobbering all over himself.

You always so educated... What I said is my opinion and nothing more, and as I have said plenty on times in here, you're not going to change my mind and I'm not going to change yours. If you like to distribute your applications with tons of libraries do it, at the end it's not me or you who is going to decide which is better.

Again, if that's your truth that's fine, go ahead and spread the word!.

Don't call it "most professional" then. Real professionals who make thousands of dollars on their games distribute tons of dlls with their games. How much money do you make of your games to qualify your approach an example of what professionals do?

I always forget that I'm talking with programmers here... I forgot to add IMH, so the SiegeLord compiler gave me an error of type;

error: /../../thread: line32: you forgot to say that it's your opinion. Alternatives are (IMH and then the text)

Given that the Allegro 5 binaries are all prebuilt with static versions, there's no hassle to you. The only thing you have to do is add #define ALLEGRO_STATICLINK to your project's build option.

Note that the -mt flag static links the C runtime. This is independent of whether or not you use the static Allegro libraries.

-mt removes the need to distribute the MSVC DLL
static removes the need to distribute Allegro DLLs.

And there's no reason that the average Allegro game sucks other than the average Allegro programmer lacks the skills, desire, or resources to create a professional looking game.

C/C++ / Preprocessor / Preprocessor Definitions.

Just add ALLEGRO_STATICLINK to the semicolon delimited list. (No need for #define when you put it in your compiler options.)

You need to link against the static version of that library.

When you static link you also need to add each Windows library that it complains about. There's probably a list around here somewhere, otherwise you can just search Google on the function name, click through to the MSDN documentation, and see what .lib file is needed.

Thanks for the list. I added it to Linker->Input->Additional Dependencies, but it can't seem to find any of the .lib files. Does that mean I need to add another directory to Linker->General->Additional Library Directories?

I got this list:

agl.lib
agld.lib
agld_s.lib
agl_s.lib
agl_s_crt.lib
alld.lib
alld_s.lib
alleg.lib
alleg_s.lib
alleg_s_crt.lib
allp.lib
allp_s.lib
comsupp.lib
comsuppd.lib
comsuppw.lib
comsuppwd.lib
delayimp.lib
libcmt.lib
libcmtd.lib
libcpmt.lib
libcpmt1.lib
libcpmtd.lib
libcpmtd0.lib
libcpmtd1.lib
msvcmrt.lib
msvcmrtd.lib
msvcprt.lib
msvcprtd.lib
msvcrt.lib
msvcrtd.lib
msvcurt.lib
msvcurtd.lib
oldnames.lib
ptrustm.lib
ptrustmd.lib
ptrustu.lib
ptrustud.lib
RunTmChk.lib

I'm not really sure if it helped yet. The compiler once again threw LNK2001 errors for every allegro command, which I can only assume is because allegro-5.0.4-monolith-static-mt.dll isn't the correct file to link against (it was changing that from the non-static version that caused those errors).

I also got a new error relating to one of the .lib files I added, which I can't make much sense of. It's printed below.

1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in libcmt.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in libcmt.lib(typinfo.obj)