Hi!

I have tried to complile latest version of allegro. And I had realised that it is not easy as any other libraries like SDL or SFML.

Maybe some articles already exists, but my search was fail

I think that is not a real problem to describe us how to comple this library (with detail step by step). It will be not shor/not big article, but it will get new users for this lib. Becouse, a lot of users go away due to hard to comppile lib from first or second trying.

Can anybody post some article, how to comple allegro from scratch. For example for vs2013. How to obtain files that equals to published at http://cdn.allegro.cc/file/library/allegro/5.0.10/allegro-5.0.10-msvc-11.0.zip

Sorry for my english

It's relatively straightforward to compile Allegro with MinGW or MinGW-w64/MSYS2. MSVC isn't as nice, so generally you have to rely on pre-built libraries.

You need cmake installed and then you can build like this :

cd allegro
mkdir build
cd build
cmake -G "Visual Studio 12" -DCMAKE_BUILD_TYPE=Release -DSHARED=On -DWANT_MONOLITH=On ..

Then open the solution it creates and build it with MSVC.

That's the basics of it. Where it gets hard is compiling the rest of the dependency libraries with MSVC. Build support is spotty. Some of the dependencies can be built with cmake as well, like zlib, libpng, physfs, and freetype. Others need to be built with configure, which is only available through Cygwin, MSYS, or Unix, but luckily these all support msvc projects in a win32 folder (though the version may be out of date, so get latest sources) like ogg, vorbis, and theora.

See README_msvc.txt in the source distribution for additional build notes.

Yeah... I just tried going through the process and everything is super easy for the CMake-enabled libraries, but getting libogg/libvorbis compiled is proving to be basically impossible. I wish they'd get a CMakeLists.txt in their libraries .

I think I had problems with libogg last time I tried building Allegro as well. It wanted a header file that wasn't included with MinGW.

Can't you load the out-dated versions of the solution files and have msvc update them to the current version by re-saving them? Isn't there any kind of backwards compatibility here?

That wasn't the issue (indeed, it managed to open and convert the project/solution files). It took a bit of time to get libvorbisfile to find libvorbis though... I ended up just creating directories where the stupid project was trying to find the lib files. I did discover that I broke A5 building without the D3D SDK .

That's why I like building with MinGW - it has dx9mgw.zip and that's all you need. You don't need the full SDK, which is nice.

Newer Mingws or MSYSs may not even need dx9mgw.zip at all

Mingw-w64 doesn't, since it provides up-to-date directx headers from winelib.

MSVC doesn't need the DXSDK itself since it ALSO provides all the needed headers (but not ABSOLUTELY ALL of them IIRC, anyway not anything Allegro needs).

SO far, I couldn't find ANY reason not to switch to Mingw-w64 over the old Mingw (which is stale).

Mingw-w64 IS available also for 32-bit systems, and provides a TON of toolchain and libraries through the MSYS2 project.

EDIT: by the way, I did build Allegro the very first time with MSVC, and all of the dependencies myself or got the binary for windows when available...O honesly don't remeber being THIS big hassle.

I'll fire up again MSVC and try to build allegro from git in the next days to see what changed in the ecosystem.

Now that I'm back home, I'll attempt to get the build shit working that I promised. I have a busy schedule though, so I can't give a date as to when it'll get done. But I am hoping ^[1] to have automatic Mingw64/MSYS2, debian, and MSVC binaries for both stable, wip, and git.

Isnt' there a way to produce MSVC "compatible" C DLLs cross compiling with mingw?

I know a couple FOSS projects out there proved something like that

EDIT: nevermind, you indeed CAN produce a suitable import file with which MSVC can correctly link a C DLL with MinGW but this precludes the possiblity to statically link.

It doesn't provide D3DX9 headers, which Allegro uses for some advanced features.

Well, it did only take a few hours... it's not a show stopper, but mildly annoying . The worst part for me, was finding a computer with enough free space on the C drive to install MSVC, as it refuses to be installed on a different drive in a meaningful way.

Right, now I remember...I should have mentioned that I was focused in using Opengl also on Windows so I just let things be in cmake (alas WANT_D3D9EX off as default IIRC).

Let's not get into Visual Studio wonkyness, that is a separate problem, don't you think?

Kidding aside, I'll have to try again MSVC just to taste the problem.

D3D9EX is different from D3DX9. The former is some weird Vista extension, while the latter is what makes shaders work.

>>Right, now I remember...I should have mentioned that I was focused in using Opengl also on Windows so I just let things be in cmake (alas WANT_D3D9EX off as default IIRC).

I think directx in allegro is a neccesary future! Becouse some users, that download shareware games have old computers where DirectX is working perfectrly, but not opengl.

I have choosed Allegro instead of (cocos2d-x, SDL and many other) due to DirectX support.

Curious, I'm fairly sure I haven't had the need to install the DX SDK when at first using MSVC. But I might be wrong of course.

Might be as you say, but Allegro Directx support its already quite advanced.

The directx those old games use, is really DirectDraw, not Direct3d. Allegro 5 only uses Direct3d, but it does use a sufficiently "compatible" (read: old) subset of the api for most of what it needs.

I mean that directx is more simplest software to install than drivers for video cards. And users can install it. Driver for Video Card (for normal support OpenGL) it is usualy problematic software even for pro-users.

So my opinion that games, that use DirectX are more easy to install.