It has been 14 years since Allegro 5 was first announced and nearly 5 years and 2 months since version 5.0 was released. After many years of development in the unstable branch, I am excited to announce that a new stable version of Allegro is ready for release!

Allegro 5.2 brings forth many features from the 5.1 branch and exposes them with a stable interface with guaranteed source and binary compatibility. This includes things like shader support, limited support for 3D game development, video playback, Android and (functioning) iOS support. Some features, however, are not quite ready for prime time and therefore remain unstable. To avoid the codebase divergence that prevented 5.0 from receiving many bugfixes from the 5.1 branch, these unstable features coexist in the same branch, but must be opted into before being used.

This release would not have been possible without the help of the many people who have contributed to Allegro over the years. In addition to the 'core' developers that have been around since time immemorial, many of the most exciting features of Allegro have been contributed by people who started using Allegro relatively recently. Even without making code contributions, simple users of Allegro who made suggestions, bug reports and simply used the code have also been invaluable to making Allegro as high quality as it is today.

In many ways, the game development community have abandoned native libraries like Allegro. Despite this downturn, many still create great games with Allegro as foundation, and I think Allegro still has a niche to fill. Allegro 5.2 is an important milestone, but it is not the end of the road. There are still many bugs to fix, features to add and games to write.

Check out the source archives here.

MSYS2 binaries are available here with the dependency packages available here.

You can grab the MSVC Nuget package here.

Ubuntu and homebrew will be updated in the coming days.

On a technical note, Allegro 5.2 is source but not binary compatible with Allegro 5.0. Additionally, the semantics of some functions have changed, but hopefully not in a way that affects most programs.

Changes from 5.1.13.1 to 5.2.0 (April 2016)

The main developers this time were: SiegeLord, Polybios, Mark Oates, Elias Pschernig and Jonathan Seeley.

Core

• Add al_is_event_source_registered (koro).

  
  

• Make destructors log messages more meaningful.

  
  

• Mouse emulation API for touch devices is now unstable.

  
  

• Rename al_convert_bitmaps to al_convert_memory_bitmaps.

Input

• Haptic API is now unstable.

Android port

• Fixed bogus display destruction on Android which previously caused zombie states.

OSX port

• Fix OSX mouse state position scaling.

  
  

• Fix other various scaling issues.

  
  

• Make toggling ALLEGRO_FRAMELESS work.

  
  

• Fix an issue where fullscreen windows would occasionally leave empty space for the titlebar.

  
  

• Fix incorrect debug assert in the audio addon.

Windows port

• Make Allegro apps DPI-aware by default, which means that they won't be scaled by the OS.

  
  

• Fix compilation for the CPU detection code on some compilers.

  
  

• Don't sync the D3D bitmap when locking with WRITE_ONLY.

  
  

• Remove dsound.dll runtime loading.

  
  

• Don't link xinput and d3dx9 libraries (they are still required at runtime though if you're using the relevant features).

  
  

• Fix a bug where al_wait_for_event_timed can block despite 0 timeout (Aldo Nunez).

Build system

• Install PDB files when building with MSVC.

Documentation

• Fix source links for API entries with multi-line prototypes.

  
  

• Make the readme look prettier on GitHub.

  
  

• Tons of assorted documentation improvements, especially for the audio addon.

Other

• Add a stability system where some unstable APIs need to be opted into by defining ALLEGRO_UNSTABLE before including Allegro headers.

Audio addon

• Fix sporadic deadlocks

  
  

• Recorder API is now unstable.

Native dialog addon

• `al_toggle_menu_item_flags` is now unstable.

TTF addon

• Add an option to pre-cache the glyphs, useful for platforms where the current algorithm is buggy (typically some Android devices).

Video addon

• Temporarily remove FFmpeg backend, as it was too buggy, didn't build and was too hard to fix.

Examples

• Make ex_vsync less likely cause a seizure.

  
  

• Make ex_draw_bitmap and ex_touch_input switch in/out on Android.

  
  

• Add documentation to ex_bitmap (Daniel Johnson).

  
  

• Improve ex_logo text entry experience.

SHA256SUMS

dd47d4a72e8a81e947c303d6cebf5056bba1e56f77339ce5481e5d33bf0841ce  Allegro.5.2.0.0.nupkg
fc8ef6597461f11adaf43b95329ea4a825cd387659643f4046f0b2f07fcd7c53  allegro-5.2.0.7z
af5a69cd423d05189e92952633f9c0dd0ff3a061d91fbce62fb32c4bd87f9fd7  allegro-5.2.0.tar.gz
7890acb70eb05edf4ec99e9b63b60c22af7bf387e34f023207ad1c4fa56484b8  allegro-5.2.0.zip
c1e272f2e2f6be80cb567829ebaa10efec854e44a8da7d0d8b02a9143b5d2dbb  allegro-mingw-gcc5.3.0-x64-5.2.0.zip
aee66be54bec6dca60ae6f6f892a447aae2d17e29b29d110bb29fee73947830c  allegro-mingw-gcc5.3.0-x86-5.2.0.zip

Awesome, Allegro 5.2.0 is finally gold, it's been a long time coming. Now let's see if Debian can get their act together and upgrade their Allegro packages. I'm still running against 5.0.10 for my Ubuntu releases.

As always well done everyone, and many thanks.

Well done !

Regarding the audio addon:

Fix sporadic deadlocks => was this the cause of lags when recording ? Nothing was loss thanks to the queue but I had some lags with 5.1 when reading packets from the record buffer. It was like frozen for seconds, after what it continues to work but is there is huge lag between record input and given record samples.

Recorder API is now unstable => which mean it's still under active development ?

Excellent!

Cool! But I have two questions:

What does "is now unstable" means?

Is it still working on WinXP? I've proposed myself to release a new version of Allegro.pas before TINS 2016 and unfortunately the only computer available is a WinXP one.

"Unstable API" means: It's there, but still under development, i.e. the API is not guaranteed to be around in the next version. It could change or be removed completely.

As to the 5.2 release, it means that developers didn't think those parts were "mature" enough to be introduced as something the next releases would have to be compatible to. So they were marked as "unstable". This is what "is now unstable" means.

There are short notes in the docs why the specific API is considered unstable, too. For example, about audio recording :

About haptics:

Instead of marking the whole 5.1 branch as "unstable", there is now only one branch with parts of it marked as unstable. Note it's about API.

Thanks for the explanation, Polybios.

I've just download it and installed at the office (fortunately, my job is in a game development studio now ) and I've found a problem in my Xubuntu 14.04.4. May be I should send a bug report.

Thing is that some examples and the Skate demonstration game raise a segment violation if no sound support is available. Initially, I compiled it without OpenAL. Some examples as ex_haiku and the demonstration games except Skate just show a message that there are an error initialising audio, but the other just raised the segment violation. Once OpenAL were installed (I don't know why it wasn't) everything work.

Also I'm really glad that you rescued the 3D Allegro stuff. It makes me chuckle.

I'll test on WinXP later.

[edit]
I've just realised that today is April 1st...

Well, knowing Allegro 5's history, it's a good release date.

Where's my mind control interface?
Congratulations guys! I may be a kind of old ghost, but I really appreciate this community (The most civil I've ever seen) and the continued efforts in actually implementing alternative propositions.

I feel like the best solution would be to step up and send them a patch. The fact that you're on 5.0.10 and not 5.0.11 means they're not quite up to date even for 5.0... Once I make the Ubuntu 5.2 packages, perhaps I could send them as is to Debian (since that's where they came from originally anyway).

We just need a hard look at it and see what's up with it. It might be fine as is. Did you have any issues with it (aside from that sample length issue; did you resolve it?)?

Whoops... that's bad.

Awesome!

I thought you were playing games with my heart, when I looked at the date. Awesome!

When will it hit the Ubuntu depot ? There are no 5.2 yet ...*

Edit: all I can see is 5.0.11.2 !

That would be AMAZING to get an up-to-date Allegro stable release through package managers.

Yeah, I would love it too.

Tested on WinXP. Even my old notebook is able to run it nicely.

I don't know what was done in the past but the first step would probably be to contact the Debian Package Maintainers and the Fedora maintainers. Not sure about Arch, Gentoo or any other distros, I've never used them.

I found some odd keyboard behavior in Allegro 5.1.13 on Windows 10. If someone with 5.2.0 installed could test some code for me I would appreciate it. The thread with the code is here :
https://www.allegro.cc/forums/thread/616179

Quick question, why has the nuget package become so much bigger? (47mb vs 73kb)
{"name":"610269","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/c\/0c7a1a526715cd30aca30c36cf58034c.jpg","w":630,"h":450,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/c\/0c7a1a526715cd30aca30c36cf58034c"}

Because of the new mind control ability of 5.2

EDIT: building it on my Win7x64 installation. I'll report the state of audio recorder fragments and may test for Edgar's problem.

PDB files, although I've no idea where the 73kb number comes from (maybe some sort of incremental download?). 5.1.13.0 package, for example, is 27.9 MB on my system (and 5.2.0 is indeed 47MB).

Google has done some amazing work. They actually send differential updates that are tiny compared to the full thing. Like hundreds of kbytes and sometimes less. They actually have it aware of code building process and the resulting binary code sections and compress them separately. I don't recall the specifics but it was something crazy.

Why are they not using that for Android Studio updates?

I missed a word in that last post. It's for Google Chrome:

https://www.chromium.org/developers/design-documents/software-updates-courgette

Check out article. They do all kinds of crazy pre-linking hinting tricks.

Looks like it could be applied to anything else though!

Incidentally, there are tons of wiki articles that still refer to Allegro 5.0 and 5.1... it'd be convenient if somebody spent a minute of their time updating an article... just search for 5.0 and 5.1!

When will 5.2 be available for Ubuntu? I don't expect official packages anytime soon, but the PPA hasn't been updated either.

Sometime this weekend most likely.

EDIT: I hit a snag in that I am not allowed to create new PPAs for the Allegro organization on launchpad (I need a 5.2 PPA). I've contacted the owner, so it might take a little bit longer still.

EDIT2: Now it's updated.

Building latest master branch for 5.2 fails on the example ex_d3d.exe. It's not linking with libd3dx9.a :

This is on MinGW 4.8.1 on Win10.

C:/mingw/LIBS/A5GIT/allegro5/examples/ex_d3d.cpp:59: undefined reference to `D3DXMatrixPerspectiveFovLH@20'
C:/mingw/LIBS/A5GIT/allegro5/examples/ex_d3d.cpp:95: undefined reference to `D3DXMatrixTranslation@16'
C:/mingw/LIBS/A5GIT/allegro5/examples/ex_d3d.cpp:98: undefined reference to `D3DXMatrixRotationY@8'
collect2.exe: error: ld returned 1 exit status
examples\CMakeFiles\ex_d3d.dir\build.make:117: recipe for target 'examples/ex_d3d.exe' failed

I believe the problem is in allegro5/examples/Helper.cmake with the 'example' function's parsing of the input arguments.

Here is Helper.cmake - see the highlighted line

I believe that line replaces all instances of any character other than 'x' with null (but I'm probably totally wrong as I know very little about regular expressions). I think what it means is match any word beginning with an 'x' and replace that word with an empty string. So I don't actually know why it's not working.

In allegro5/examples/CMakeLists.txt there are the following lines to create the ex_d3d example :

if(WANT_D3D AND D3DX9_FOUND)
    example(ex_d3d ex_d3d.cpp ${D3DX9_LIBRARY})
endif(WANT_D3D AND D3DX9_FOUND)

${D3DX9_LIBRARY}) is libd3dx9.a

I don't think it is parsing it properly, and so libd3dx9.a is not getting linked, causing the undefined references.

What do you think?

Try running make ex_d3d VERBOSE=1 and see what link command it outputs. The only thing that changed recently is that the core no longer links D3DX9. For me it gives:

/F/msys64/mingw64/bin/g++.exe   -W -Wall -Wpointer-arith -g -DDEBUGMODE=1 -DD3D_DEBUG_INFO  -mwindows -Wl,--whole-archive CMakeFiles/ex_d3d.dir/objects.a -Wl,--no-whole-archive  -o ex_d3d.exe
-Wl,--major-image-version,0,--minor-image-version,0  ../lib/liballegro_main-debug.dll.a /F/msys64/mingw64/x86_64-w64-mingw32/Lib/libd3dx9.a ../lib/liballegro_dialog-debug.dll.a ../lib/liballegro-debug.dll.a
-lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -lwinmm -lpsapi -lshlwapi /F/msys64/mingw64/x86_64-w64-mingw32/Lib/libdinput8.a -lglu32 -lopengl32 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

mingw32-make ex_d3d VERBOSE=1

c:\mingw\bin\g++.exe   -W -Wall -Wpointer-arith -g -DDEBUGMODE=1 -DD3D_DEBUG_INFO  -mwindows -Wl,--whole-archive CMakeFiles\ex_d3d.dir/objects.a -Wl,--no-whole-archive  -o ex_d3d.exe -Wl,--out-implib,libex_d3d.
dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\ex_d3d.dir\linklibs.rsp

Well for me it's not linking libd3dx9.a .

Why is it making an import library? "-Wl,--out-implib,libex_d3d.dll.a"?

Edit
@SiegeLord - Are you using the MSYS Makefile generator or the MinGW Makefile generator? I don't know if that makes a difference though.

I'm not sure what that last parameter is but I think it's inlining the contents of that file ( @CMakeFiles\ex_d3d.dir\linklibs.rsp ).

Here's what that file contains :

 ../lib/liballegro_monolith-debug.dll.a -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -lwinmm -lpsapi -lshlwapi -Wl,-Bstatic -ldinput8 -Wl,-Bdynamic -lglu32 -lopengl32 -Wl,-Bstatic -lgdiplus -Wl,-Bdynamic -luuid -Wl,-Bstatic -ldsound -Wl,-Bdynamic -lOpenAL32 -Wl,-Bstatic -lFLAC -Wl,-Bdynamic -logg -lwsock32 -Wl,-Bstatic -ldumb -Wl,-Bdynamic -lvorbisfile -lvorbis -Wl,-Bstatic -lfreetype -Wl,-Bdynamic -lzlib -lphysfs -ltheoradec -logg -lwsock32 -Wl,-Bstatic -ldumb -Wl,-Bdynamic -lvorbisfile -lvorbis -Wl,-Bstatic -lfreetype -Wl,-Bdynamic -lzlib -lphysfs -ltheoradec -lpng16.dll -lzlib.dll -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

-ld3dx9 is not there.

Yeah, I am using MSYS makefiles... odd.

Could you try compiling 5.1.13 and seeing if this command is different?

I deleted ex_d3d.exe from my 5.1.13 build and reran "mingw32-make ex_d3d VERBOSE=1" and here's what it said when linking the file.

c:\mingw\bin\g++.exe   -W -Wall -Wpointer-arith -g -DDEBUGMODE=1 -DD3D_DEBUG_INFO  -mwindows -Wl,--whole-archive CMakeFiles\ex_d3d.dir/objects.a -Wl,--no-whole-archive  -o ex_d3d.exe -Wl,--out-implib,libex_d3d.
dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\ex_d3d.dir\linklibs.rsp

And here's what build\examples\CMakeFiles\ex_d3d.dir\linklibs.rsp contains : (note it has -ld3dx9 in it).

 ../lib/liballegro_monolith-debug.dll.a -lkernel32 -luser32 -lgdi32 -lcomdlg32 -lole32 -lwinmm -lpsapi -lshlwapi -Wl,-Bstatic -ldinput8 -Wl,-Bdynamic -lglu32 -lopengl32 -Wl,-Bstatic -ld3dx9 -lgdiplus -Wl,-Bdynamic -luuid -Wl,-Bstatic -ldsound -lFLAC -Wl,-Bdynamic -logg -lwsock32 -Wl,-Bstatic -ldumb -Wl,-Bdynamic -lvorbisfile -lvorbis -Wl,-Bstatic -lfreetype -Wl,-Bdynamic C:/mingw/lib/libzlib.dll.a -Wl,-Bstatic -lphysfs -Wl,-Bdynamic -ltheoradec -logg -lwsock32 -Wl,-Bstatic -ldumb -Wl,-Bdynamic -lvorbisfile -lvorbis -Wl,-Bstatic -lfreetype -Wl,-Bdynamic C:/mingw/lib/libzlib.dll.a -Wl,-Bstatic -lphysfs -Wl,-Bdynamic -ltheoradec -static -lpng16 -lzlibstatic -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32

I should note I am using CMake 3.3.2.

Edit
Bump to give time for reply.

Also, I will have some binaries ready today or tomorrow for MinGW 4.8.1. I may also put together a newer package of MinGW and binaries for it too, but that may take a little while.

That would be awesome.

Which version of Visual Studio, or does it not matter? I have always used MinGW with Allegro but decided to give VS2015 Community Edition a try today. I did the following with no real luck,

1. created a console application
2. installed the nuget package
3. copied ex_keyboard_events.c into the project folder and included in the solution
4. copied common.c into the project folder and included in the solution
5. turned off pre-compiled headers

The above ends with "exit identifier not found". I don't think that's the issue rather I'm missing some fundamental understanding of how to configure.

---

I take it the nuget package installer configures Allegro 5 for that project. Is the recommended approach to re-install the libraries for each project?

Not sure what causes this issue for you, but you could just try adding #include <stdlib.h> on top of your ex_mouse_events.c file.

FYI, the Fedora package maintainer has already updated the packages so I think 5.2.0 should be available in Fedora already (and if not then soon).

Good to know, let's hope the Debian maintainer does the same soon so it can make it into Ubuntu without the need to add the PPA.

Bump so I can get some binaries made. I'll do that here in a bit.

Edit - here ya go. Built with MinGW 4.8.1. Dependencies included, examples and demos too.

https://sourceforge.net/projects/unofficialallegro5distribution/files/A52GITdistro.tar.7z/download

Woohoo, as always, your efforts are much appreciated Edgar! Thanks.

Edit: When I compiled my game in static debug mode, it compiled fine, but I notice in my console that it is reporting this as Allegro v5.1.13? I done a totally clean build using your download. But I got no errors when I compiled it and it obviously ran, but that version is off.

Secondly, when I done a clean, static release compile, I got the following errors...

||=== Clean: Release32 in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
||=== Build: Release32 in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
C:\MinGW\lib\liballegro_monolith-static.a(dsound.cpp.obj):dsound.cpp|| undefined reference to `DirectSoundCreate8@12'|
C:\MinGW\lib\liballegro_monolith-static.a(dsound.cpp.obj):dsound.cpp|| undefined reference to `DirectSoundCaptureCreate8@12'|
||=== Build failed: 2 error(s), 0 warning(s) (0 minute(s), 7 second(s)) ===|

All compiled using your MinGW5.8.1 distro you provided and the latest Allegro you posted about just now.

It depends on DirectSound for some reason. -ldsound will fix that error.

Not sure why it reports itself as being 5.1.13. I built it from GIT. Perhaps that is why. But it is 5.2 or later.

I tried that with the static release build and it compiles, but when I run the game, it gives a seg fault and doesn't run at all. Debug works fine still.

If debug works and release doesn't you might have an uninitialized variable somewhere. Try using printf statements to see where it is crashing. I don't know how else to debug release build crashes. I'm not sure why it is crashing. I am currently using static release builds in my TINS entry and it is not crashing.

V_V I have struggling so hard for the last 5 years to get any version of Allegro going and still can't get it to build nor find existing binaries/up to date tutorials.

This is my most recent attempt(lossy, lossless is attached to this post)
http://imgur.com/zP9YP7d

Please help V_V I really want to read my Game Programming All in One 2nd edition without having to translate everything to Java or SDL or GDI.

Much sadness.

Upgrade to MSVC 2013 or 2015 and use NuGet!

I need to upgrade to 2015 at some point myself.

I can't upgrade beyond 2012 unless I reinstall windows to get the service pack.

I need it to work on MinGW or VS2012.

You should probably upgrade your system for security purposes. I recommend switching to a free GNU/Linux distro if money (and morality) are an issue (and even if they aren't). Ubuntu is made to be very friendly and a Windows user won't have any problem accepting proprietary license agreements. Software development also tends to be much easier in Linux for various reasons.

Alternatively, you could reinstall Windows onto a 50% partition and then install a Linux distro side-by-side... Then you still have Windows for everyday use, but can dual-boot into Linux for Allegro development...

Alternatively, there are people here with the skills and experience to create a build for you... I'm not one of them. Gathering and sorting out the dependencies in Windows is simply too much trouble. But if it's important enough for you there may be people willing to create the binaries for you for payment.

5 years is a ridiculous amount of time to wait anyway. Don't wait any longer. Either solve your Allegro woes or move on. There are many other game development platforms and several other books...

What server pack requires you to reinstall?

A very valid question... And also what OS version/SP are you running now?

@bamccaig

The whole reason I'm interested in Allegro is because of its' portability. I am certain there is a way to get it to work on this system, but it is not as streamlined as SDL or even SFML(which I struggled with quite a bit) is, which is one of the biggest issues limiting Allegro's growth.

I have both Debian and Windows 10 on VirtualBox that run well enough to code on, but I am not going to be ready to transition from this system for a bit(I have plans to move to Debian in some future and use Windows 10 in VirtualBox but I'm not quite sure if I can move a Virtual machine from Windows to Linux).

Besides, my system is not relevant here. Isn't Allegro suppose to be able to build with MinGW and Visual Studio 2012? I am fine with using MinGW for it, but I am facing similar issues where it goes through the build process, complains that it can't find many libc features, says it's complete, and there are no output libs.

PS: I am running Windows 7 without any service packs at the moment.

Allegro is compatible with MinGW and Visual Studio 2012. The only hard part about building is satisfying the dependencies. If no existing binaries exist for your toolchain then you have to rebuild them all.

That means every library that Allegro depends on to give you graphics file loading, audio file loading, etc., needs to be built for your toolchain first (unless you can find binaries for that). And recursively you need to satisfy their dependencies first. For example, if Allegro needs libabc then you need to build that first, but if libabc requires libmln and libxyz then you have to first build libmln and libxyz, then libabc, and then finally Allegro! But that's a simplified model. There are probably close to 10 dependencies for Allegro, and I have no idea how deep the recursive dependency graph goes...

Only once you've recursively built (or sourced) binaries for all dependencies for Allegro can you actually build Allegro and then start making your games... If binaries exist for your toolchain then it Just Works(tm) and you can get started. That's the ideal case. But we don't have the resources to provide binaries for all possible configurations... And I'm not sure if all of the ones we do have are organized anywhere.

If it isn't the case that binaries exist then it's a chore to get Allegro building that only the most motivated users or developers undertake. In Linux most of this trouble is eliminated because the distribution package repositories already have compatible binaries for the dependencies, and several of the most popular distros also have packages for Allegro itself...

CMake itself, the build system being used for Allegro, will do its best to configure itself to build even if you are lacking dependencies... But if dependencies are missing then it will disable features of the library to the point of building a useless library that can't do what you need it to. You basically need all of the dependencies satisfied or you'll be annoyed later when your game won't run because Allegro doesn't support loading PNG files or something.

That sounds reasonable other than having to be done via CMake. I have no idea what toolchain means nor how to use all the CMake features, so it's a lot more steep of learning curve than a simpler build structure.

It's not as straightforward as photoshop signature tutorials (which also skip steps occasionally)

Try using msys2. You can install most of the dependencies via pacman. There are also official packages for it. Once you have it set up, it's as trivial as on Linux.

CMake it essentially used to generate your own toolchain's build scripts. This includes generating Visual Studio project (/solution?) files. I agree, it's a frustrating learning curve to have to learn, but on the other hand without it there might not be Visual Studio support at all so it might be a saving grace for you...

The good news is that there isn't much that you need to do with CMake. Install it, fire it up, and tell it to build. There is also a GUI variant called ccmake which I imagine will be added to your Start Menu by the installer... However, the real hurdle is satisfying the dependencies which CMake does not help with (if anything, it makes matters worse by implicitly letting the build succeed without them).

A "toolchain" just refers to the set of programs that you use in software development to produce a build. In general, this means your compiler, linker, etc., but could also mean other tools needed to complete the pipeline. Binaries are sometimes only compatible with the toolchain, the compiler/linker versions, that built them, as is the case in Windows. An IDE muddies the waters for what constitutes a toolchain, which is probably why you haven't encountered the terminology before, but nevertheless one might consider your toolchain to be "Visual Studio n" (meaning all of the underlying infrastructure hidden under the surface that that implies).

If binaries exist for your version of Visual Studio and desired version of Allegro then you just need to install those and you'll be fine. If not then you will need to go through the pain to build Allegro described above...

I'll try again later. My issue is it's hard to read feedback from CMake to see where is goes wrong since it continues past many warnings and many are supposedly not indicative of anything being wrong.

The overall experience so far reminds me of trying to build Minix... took a while.

Is there a way to get the source and the dependancies to build for visual studio using the cmake? I like the new version of Nuget but My school prefers the old way. Using cmake and building the binaries for Visual Studio.

Dependencies are a crapshoot with building with CMake. Not all of them even support CMake. Hell, I'm amazed that people can build them with the newest MSVC due to how they're unix first (to the point that it should be unix only)

For the official windows binaries I created CMake-based build systems for all of Allegro dependencies. I highly recommend using them and the associated scripts to build Allegro if you need to do it yourself. It might be easy enough to adapt to an older MSVC version too:

https://github.com/liballeg/allegro_winpkg
https://github.com/liballeg/allegro_winpkg/blob/master/universal/README_msvc.txt

Thank you SiegeLord. Using that link I was able to compile it for MSVC 2013 and 2015

Nice work!

Whilst OpenApocalypse moved to SDL2 (I'm not as involved these days), I still prefer Allegro for all my dev needs.

In case anyone was using the binaries I provided (NeilRoy) I repackaged it due to the possibility of older versions having snuck into the distro. Redownload from the link provided.

https://sourceforge.net/projects/unofficialallegro5distribution/files/A52GITdistro2.tar.7z/download

Yours are not for MSVC correct?

Right, they are for MinGW 4.8.1
Which I also provide a binary for here :
https://sourceforge.net/projects/unofficialmingw/files/mingw_4_8_1-4.tar.7z/download

Very nice!
I'll take a deeper look at it when I have the time.
Keep up the good work.

@ Edgar Reynaldo.. thanks.. exactly what I'll need in the future.

It WORKS!!

Publishing a binary of my TINS entry soon.

I compiled a debug version, and it worked fine for my game, but my level editor crashed, which is really strange, and I'll explain why...

First off, the point where it crashed...

#0 0041DF5E	al_install_keyboard() (C:\LIBS\A5GIT\allegro5\src\keybdnu.c:133)
#1 00405388	main(argc=1, argv=0xb518a8) (C:\Develop\Projects\Deluxe_Pacman_2\p2_main.c:99)

Line 99 in my level editor is this...

if(!al_install_keyboard()) {

I don't know what the line is in the allegro source, I don't have that. But as you can see, it shouldn't be crashing here for me. It never returns from the install function, but crashes with a seg fault inside of it.

The strange thing is, I also compiled my game (which is a separate compile) and it ran fine in debug mode, yet it initializes the keyboard as well. Both compiles on my level editor and my game were clean compiles by the way.

I haven't tested the release version yet, I'm about to and will post below...

Okay, I just tried to compile my main game in release mode and still getting a segmentation fault when I try to run it. Doesn't even open up a window. Yet it compiled and ran fine in debug mode. Same as last time, very strange. I wonder if is related to the level editor failing in the keyboard init function?

Note, nothing is changed in my game, it compiles and runs flawlessly with previous versions you released of Allegro 5. This is the only one it fails with. And I made certain to add in dsound to the libraries linked (still needed that).

Edit: Okay, I changed release mode so it compiles with a console, then added some printf()s and sure enough, it is crashing inside the keyboard init, as I suspected. But it only crashes there in release mode, not in debug mode for my game. My level editor seems to crash there in debug and release.

Segmentationfaults can be caused by anything in the code before. Doublecheck your code. Use valgrind, it will probably generate a lot of (false ?) errors within Allegro.And it doesn't like switching ownership of objects eigther. But when you skip those, what remains should be the problem.
I had such a problem some weeks ago with my startrek game. I was reading beyond some array when I refactored from #defines to enums. I forgot to remove a number of loaded sounds and use an enum sentinel instead.
Resulting in an segmentation fault in my communication module. But only in the release version. In the debug version some ships where cloaking the wrong way, without any error !

Neil Roy, double check that you've re-copied the appropriate dlls into your game folder. Sometimes that causes segmentation faults in allegro startup functions. I will look at line 133. It would only crash if the system driver had not been init'ed. So check al_init. It's probably a version mismatch error that is preventing allegro from being inited properly.

The lines of code cited are from the compiler's point of view, not yours. So they point to the source I compiled the library from.

I would agree if I had been working on my game at all since I installed the new version of Allegro, but I have not. At all. I only load it and recompile for new versions or bugs, otherwise I haven't done much with it lately. The game compiles and runs fine, to see it, just click the link at the bottom of this message, download and install "Deluxe Pacman 2", the version available now is from 5.1.13. Just before this. I compiled that exact same code, no changes what so ever and it has a fault, one that does not exist in the previous Allegro code. So something in 5.20 has changed.

It's statically linked. There are no DLLs needed. I did note that the version is still reported as 5.1.13 instead of 5.20. Otherwise, if it was in my code, it would not work at all for any version. But the last version, 5.1.13 works fine.

If it is a version mismatch, than it is with the newer version as it reports 5.1.13 still.

In any event, I'll switch back to 5.1.13 which works.

Edit: Here's the code my game runs before it crashes. Not much, it starts in main, a couple variables are declared (nothing fantastic, ints, floats the usual)...

dp2_main.c

...it then immediately jumps to an initialize function which does the following...

initialize() function;

That's it! You see ALL the code my game runs up until the crash, this is all of it. It is compiled with a C compiler, with MinGW (the version Edgar provides as a download) as a staticly linked compile, no DLLs. As you can see, not much going on in my game up until this point, and all of this runs fine with 5.1.13.

Edit2: I just noticed something when testing this again... the release version which crashes reports Allegro version: 5.2.1 where as the debug version which does not crash reports Allegro version: 5.1.13! Now I done a clean compile for both, I even manually deleted ALL the old Allegro 5.1 files as well as manually deleted all the object files, just to be certain before compiling... so...

You're not checking return values. al_init could fail, and that could be the reason al_install_keyboard is failing. Are you sure you're linking ONLY to the new libs?

I will try your code here in a bit and see if it crashes for me.

EDIT
Neil, you in the code you posted you never call al_init(). It crashes for me too. :/

If al_install_keyboard crashes and there is no serious memory corruption going on then it's probably because al_init fails too. Make sure you check your return values (could more easily catch problems like this without resorting to a debugger)! This is beginner stuff!

Why is initialize static?

[edit] Also, since this version mismatch issue seems to be a FAQ.

1 - I really think we need a FAQ wikipage. Is this the proper wiki?

https://wiki.allegro.cc/

2 - Is there a change we can make to force Allegro 5's headers to check whether the library is the right version on start-up? I've run into this issue a few times (debug vs release versions being different is a PITA!), including when I was trying to get DAlleg up and running.

Neil, did you get your problem resolved?

Sorry, I haven't been working on it. My game runs just fine with older versions of the lib. Just not this one.

I'll try again with error checking code in there. I don't know why I don't have it honestly, I normally have it for all init functions. <shrug>

Okay, you're right, al_init() failed, and I think I understand why now.

al_init() basically calls: bool al_install_system(int version, int (*atexit_ptr)(void (*)(void)))

Well, look at what it calls! It passes in the VERSION... and as I have already pointed out, there is a version mismatch. It reports v5.1.13 for the debug version, and v5.2 for the release version, so my guess is that it passes in v5.2 in release which is cauing a problem somewhere. It would explain why 5.1.13 works fine for me, and the debug version of 5.2 works fine (it reports 5.1.13) but the release does not (it reports 5.2). In any event, the problem is not in my code (aside from not reporting the error). Actually, had I reported the error, I probably would have never found this problem as it would have ended before the version was reported, or whatever... <shrug>

Sorry I didn't reply sooner, but... just not working on this as much now. I would like to update it if possible but... 5.1.13 works, no problems, this does not.

Neil, did you remember to update your headers? Were you pointing to the right include directory? Because the headers were updated along with the library. That might explain why it is reporting as 5.1.13. In my headers for the distro it reports 5.2.1 as ALLEGRO_VERSION_INT in include\allegro5\base.h on lines 56-58.

If your debug version reports the wrong version, you may be using older headers somehow, perhaps by not updating your include path for the debug version.

My best guess.

Edgar.

Edit
Is there a detailed guide somewhere to setting up Allegro with MSVC 2015? I got as far as creating a solution, installing the allegro nuget package, and then trying to set relative include directories but I don't know what the base search directory is or whether you can even use relative include paths with MSVC. I want to make a portable solution to build my ManyMouse project with. Don't even get me started on how many warnings MSVC is throwing out at me. It's gonna take me days just to get them all sorted. Does the nuget package use .lib files for allegro? Or something else?

You install the nuget package, then just use the include files as needed in your source. The nuget package will add a property screen where you select what features you want, how you want it built, and it will handle the lib stuff for you.

It's like that pkg-configure (I think that's the command) on Linux.

Sorry, I don't know what you're talking about. What nuget properties page? I access the project properties by right clicking on the project and setting the include directories there. It's not detecting the allegro headers. "Cannot open include file 'allegro5/allegro.h' no such file or directory".

Edit
I figured out I need to use $(SolutionDir) as a root directory for it to work with relative paths.

Now I have to get it to link with allegro.

I'm confused which libraries to link to. Are the dynamic release libs not included in the package? If I want release do I have to link statically? Why is there no dynamic debug monolith? Or dynamic release monolith? The only monolith provided is allegro_monolith-static.lib.

Edit
I set the link directory and added allegro.lib to the additional libraries, and it says it still can't find it. :/

{"name":"610435","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/8\/084e43eb6c2f2ef0adfa6bfe1d7eb420.png","w":1307,"h":297,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/8\/084e43eb6c2f2ef0adfa6bfe1d7eb420"}

2015 might have change things a tad, but this is what I was talking about with the property page.

Also, my include is define like this: $(ProjectDir)\include;$(IncludePath)

Then I just use #include <allegro5/allegro.h> (Note, $(ProjectDir)\include is a by product of using the SpeedHack makefile and allowing that to work with my code)

I'm still pretty new at using MSVS. I have some more questions.

1. How do I specify I want to build a dll? I can't seem to find the application type anywhere in any properties or settings page. Do I have to re-create the project all over again?

2. How do I get one project to build at a time? I told it to build only my DLL project, but it insists on linking the second project's object files which results in unresolved externals. It seems to think that the two projects are really one. I told it that the second project depends on the first one in Project Dependencies so I don't know what's up with it. It keeps insisting on linking object files that are only used in the second project.

3. Where do I look for the resulting *.lib and *.dll files once I get it to build my dll properly? So I can link my second project to the dll project.

Edit
4. So I recreated the project using Win32 Console application and DLL and now it says "LNK2019 unresolved external symbol _main referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ). I followed the advice from StackOverflow and set the linker subsystem type to Windows (it already was) and it still persists. It says it whether it's set to console or to windows.

I'm getting kind of tired of MSVS.

This looks like a great update. Thanks to everybody involved for their hard work.

Are binaries (not a Nuget package) available for MSVC2015? I prefer managing libraries the "traditional" way, but if not the package is usable.

My game is made with Allegro (http://store.steampowered.com/app/363220/), perhaps it will benefit from a new build with the update library (I think it runs on 5.0.9 still).

The allegro.cc files page should probably be updated, too.

I think the unresolved external reference to _main error is coming from the CRT. It says it's in the file MSVCRTD.lib, which corresponds to the Multi Threaded Debug DLL runtime. What were the allegro libs compiled with? I am using the dynamic debug allegro library from nuget with MSVS 2015.

I may try one last time. I tried an install where I removed ALL files pertaining to Allegro 5. I'll try re-installing MinGW from scratch along with Allegro from scratch and see how that goes but I have my doubts. My paths are all fine, I done clean installs, clean builds.

If that works, I'll let you know, if not... I just won't bother. I don't work with this enough anymore.

Well, it would help me out. I need to know whether or not there is something wrong with my build so my users aren't downloading something that doesn't work.

Sorry, it was MY fault. I checked my paths and sure enough, there is another path it checks that had an older Allegro in it. Works fine now, thanks for all your work and help. I didn't mean to be a pain, I just don't work on this as much as I used to, so I am a little rusty at times. I'll recompile the game and put up a new version of it using your latest build.

It correctly reported 5.2.1 etc... on both versions as well. I guess I need to put a note somewhere reminding me where all my folders are to avoid future headaches (and unnecessary reports here).

Thanks again "Edgar"

Edit: My game, now compiled with this version, can be downloaded here (game play video on the page too): http://home.cogeco.ca/~nroy15/games_index.html

Allegro 5.2!!! WTF!! I didn't know! Man it's incredible. Has passed 6 years since I first joined this forums... Just like a fine wine.

@AMCerasoli: You should visit us more often.

Don't be a stranger! How's the music coming along?

Okay, I solved all of my earlier problems.

I have some concerns with debugging my program with MSVS and Allegro with the Nuget package though.

1. Sources aren't included so I can't see what code is causing an exception. For instance, right now it's crashing in al_mutex_lock inside al_register_destructor inside al_create_timer. It looks like al_install_system succeeded though, so I don't know what would make it crash in al_create_timer, and I can't look at the sources because they don't come with the Nuget package.

2. allegro_debug.pdb wasn't copied over into the Debug folder when I installed the Allegro Nuget package, so I had to do it manually to get the symbols for allegro to show up in the debugger.

Yes it's true... I'm not into the game programming world right now. I use to visit the forums from time to time, but don't make any comments.

HEY YO! WHAT'S UP! It's fine, it's a hobby though. Right now I'm working on other projects. Conquer the world and that stuff, you know, like everyone.

Here's a screenie of what I mean. You can see the local variable window is empty, so I can't view the value of any of the local variables, like the mutex and it's critical section member. So I can't tell why it's crashing, and I'm stuck. Every time I try to switch to the frame where it is crashing, it says I have to have the source file to view it. Ideas?

{"name":"610451","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/a\/fa7eb5321ebe756665d19c4baf57c93b.png","w":1919,"h":847,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/f\/a\/fa7eb5321ebe756665d19c4baf57c93b"}

You should be able to specify the sources used for debug files: https://msdn.microsoft.com/en-us/library/ms241613.aspx#Anchor_1