First release of the Allegro in the new year! Hopefully not too many more of these before the next stable release.

Get the source packages here.

Get the MinGW binaries here.

Get the corresponding dependency MinGW binaries here.

Get the MSVC binaries from NuGet (now with MSVC 2013 support!).

Ubuntu and homebrew binaries will be done in the coming days!

EDIT: Ubuntu packages are now done.

Changes from 5.1.12 to 5.1.13 (January 2016)

The main developers this time were: Julian Smythe, Elias Pschernig and Peter Hull.

Graphics

• Add al_get_opengl_program_object (SiegeLord).

Input

• Fix spurious triggering of the mouse grab key when it wasn't otherwise set (SiegeLord).

Android port

• Avoid multiple HALT/RESUME events on Android (Max Savenkov).

  
  

• Implement al_get_monitor_info for Android (Reuben Bell).

  
  

• Fix Android crash on file access.

  
  

• Implement ALLEGRO_FULLSCREEN_WINDOW on Android.

  
  

• Fix crash if display is destroyed while the app is switched out.

  
  

• Add support for x86_64 Android.

  
  

• Add al_android_set_apk_fs_interface.

Linux port

• Allow using OpenGL ES in X11.

  
  

• Fix the initial display size not being correct sometimes (SiegeLord).

  
  

• Fix a race condition in the XInput joystick driver (Trent Gamblin).

OSX port

• Fix various memory leaks.

  
  

• Fix al_set_window_title.

  
  

• Fix a lot of decrepit and deprecated code.

  
  

• Fix single buffer flip display (SiegeLord).

Windows port

• Fix Windows UNC path handling.

  
  

• Fix clipboard nul-termination issues (Trent Gamblin).

  
  

• Set the window title immediately upon window creation (SiegeLord).

Build system

• Define CMAKE_FIND_ROOT_PATH for i686-w64-mingw32 cross compiler (Martijn van Iersel).

  
  

• Allow building with older CMakes again (SiegeLord).

  
  

• Do not cache compile tests' failure (Bruce Pascoe).

  
  

• Add a way to statically link the runtime with MinGW (SiegeLord).

  
  

• Don't link the MSVC C runtime at all when requesting a static runtime and building a static library (SiegeLord).

Documentation

• Add links to the source code of the definitions of the most API entries.

  
  

• Fix sidebar generation with modern Pandoc (Boris Carvajal).

Python

• Fix ordering issue for HAPTIC* structs.

  
  

• Fix missing ALLEGRO_PRIM_ATTR_NUM.

Other

• Add a 'none' debug level to turn off logging entirely in debug builds (SiegeLord).

  
  

• Reconfigure logging after the configuration files are loaded (SiegeLord).

  
  

• Fix al_set_new_window_title() off-by-1 (Bruce Pascoe).

  
  

• Don't call al_get_time() before system is installed (SiegeLord).

Audio addon

• Add al_get_default_voice and al_set_default_voice.

  
  

• Flush the pulse audio stream rather than draining it, fixing some audio breaks (SiegeLord).

  
  

• Fill audio stream fragments with silence in the audio addon rather than in the acodec addon, fixing some garbage output (SiegeLord).

  
  

• Fix possible deadlock when destroying audio streams (SiegeLord).

Acodec addon

• Don't read past the audio chunk's end when streaming wav files (SiegeLord).

  
  

• Turn off allegro_acodec dynamic loading by default, fixing a common footgun (Bruce Pascoe).

Image addon

• An enormous amount of work supporting reading of esoteric (and not) BMP format variants (palletted, GIMP-style, etc). New tests were added using the manual bmp suites.

Native dialog addon

• Update code to work with modern OSX versions.

  
  

• Clean up menu handling on OSX.

SHA256SUMS

7505f68ef26388a28b85e6e03f2193ebe33fbe0d8bed118e7a8f3e10ad95966f  allegro-5.1.13.7z
f3c5be792bc0fc6e657de473112196823598120cfa2e6e19d6f87543f2a273fd  allegro-5.1.13.tar.gz
453cfa50a12050ce71b54db8dac9ba4390918ea9bbd343515e0c08dd2ea8e297  allegro-5.1.13.zip
a6f1b2624769698f8e4676b9266bb941939ab557df67d924b5b14eaaf6f807f9  allegro-mingw-gcc5.3.0-x64-5.1.13.zip
5e99632eb7109758e008ea31cb9b2e2c8326e6f26eae9ccb6c7e10ca1953ef7a  allegro-mingw-gcc5.3.0-x86-5.1.13.zip
cf3cc436960c75b27759c8611611f9cf357717d99ccec2d5a0c3d5844ccc697a  allegro_deps-mingw-gcc5.3.0-x64-1.4.0.zip
bddccb95d4df8f2209ad222a32a2450172dfb848ef73f472a1744b2de4bd1c44  allegro_deps-mingw-gcc5.3.0-x86-1.4.0.zip

Nice to hear 5.2 isn't too far off. I'll upgrade right away, 5.1.12 has a couple bugs with string handling (the clipboard one, as well as al_set_new_window_title) so it'll be nice to get rid of the workarounds for them. Plus the WAV stream corruption is gone, yay!

Will Ubuntu packages be uploaded soon? (I know it's a pain, no rush)

Also, no MSVC binaries? (edit: Nevermind, forgot these are provided through NuGet now )

For the MinGW binaries and deps it says Forbidden access.

Thanks Bruce for fixing that al_set_window_title bug. And thanks Siegelord for the new release! Already downloaded! I will make some Mingw 4.5.0 binaries here in a day or two when my internet is back up and running. (Posted from my phone )

No problem. As I use Allegro for a general-purpose game engine, I noticed it right away that every single game had the last character of its title chopped off. If I were just making a single game I probably wouldn't have paid it any mind.

edit: Are the NuGet packages bugged? Just installed the 5.1.13 package to my project, and I'm getting link errors:

1>LINK : fatal error LNK1181: cannot open input file 'allegro51.lib'

edit 2: Ignore me, it was caused by leftover linker settings from when I had the Allegro libs in my own repo. The packages work great!

Yeah, just not today. My goal is by the end of the week, but I'll try doing it tomorrow.

Yeah, I figured it was the most convenient method and hosting the .zip files seemed redundant (you can actually open the packages and extract the libs/dlls yourself).

That's... very strange. I wonder what I did wrong. I'll try fixing it in a bit.

4.5.0?

Yeah, the other folders work fine, they were the only ones that gave a problem. The files show as there, just can't download them. Permissions on them or something? (not sure how that works there)

Yeah, that's what it was. Should be good now.

Yup, works okay now. Thanks.

Great work as always!

I'm making the move. Byebye A4, all my code will belong to A5 during this week.
It's going to be a pain.
Allegro5, I'm coming !!

I must say NuGet is nice - and with the static option, no more needing to build Allegro myself, yay!

I didn't realize nuget could add options to the project settings. That's pretty nifty.

Woah no way. I had no idea you were still using A4.

I can say I do miss the old days of key[] and polling everything. Times were simpler, then.

*nostalgic music*

I like NuGet package. it's easy to install from Windows 10's PowerShell

PS C:\Users\FooBar> Find-Package Allegro | Install-Package -Destination C:\Users\FooBar\Documents\A5

Thank you for the Allegro Dev Team!

I misspoke again. I'm running MinGW 4.8.1. That's what the binaries I provide will be for.

Ubuntu packages have been uploaded (hopefully they work ).

I just re-ran my last Travis build of minisphere, and the build succeeded using the 5.1.13 packages. No idea what happens at runtime until I boot into Ubuntu myself, but there are no compile/link errors at least.

Mark:

You don't know the real value of something until you loose it.

Haaa, good old if( keypressed() ) ;-)

Edit: I'm on ubuntu 16.04 and I confirm that they work.

@SiegeLord By the way it still might be worth providing standalone MSVC binaries for allegro_deps, since those are needed to build Allegro using CMake and are a pain to build them all manually. For now I can lift them from the NuGet packages, of course.

I created a function for that under Allegro 5.

bool key_pressed(int key)
{
   ALLEGRO_KEYBOARD_STATE s;
   al_get_keyboard_state(&s);
   return al_key_down(&s, key);
}

Thanks, I look forward to it.

Cheers. Here ya go. If you have any problems with it let me know and I'll fix 'em lickety split.

http://sourceforge.net/projects/unofficialallegro5distribution/files/A5113distroMinGW481-4.7z/download

Allegro 5.1.13 for MinGW 4.8.1 build 2
(got rid of dependency on OpenAL32.dll and made static libs link statically to the MinGW CRT)

Allegro 5.1.X
https://sourceforge.net/projects/unofficialallegro5distribution/files/latest/download?source=files

MinGW 4.8.1
http://sourceforge.net/projects/unofficialmingw/files/mingw_4_8_1-4.tar.7z/download

Thanks a lot, that was fast!

Anyhow, I recompiled my Deluxe Pacman 2 game using it, both debug and release versions were statically linked and worked perfectly.

I think there may be a slight increase in speed with this version I noticed, at least over what I had installed, which I think was 5.1.11 if I recall.

One problem (if it is a problem?) that I still notice is that when I run my game with DirectX mode, I get around 400fps (should be faster, but that's my fault). Anyhow, when I switch it to use OpenGL instead, it gets half that, or around 200fps, that seems like quite a difference. I was under the impression that the two should be close to the same. I am running Windows 7 - 64bit with latest drivers (nVidia GTX650). I don't suppose anyone has figured this out yet?

I noted this a few versions ago. I am happy to run with DirectX, and I can most definitely speed my game's frame rate up (I plan to do that soon) but I still wonder if I ever recompile it for Linux or some other platform with opengl, how well it would do.

I also noticed that my frame rate gradually climbs. It done that with 5.1.11, with this version it climbs a little faster. Starts out around 350, climbs to over 400. I use the same frame rate code so I doubt it is that (though I will double check it). Just seems odd, and quite a difference.

Oh, do I still need to use "libgcc_s_dw2-1.dll" and "OpenAL32.dll" with this?

It's been my experience that DirectX hits higher framerates on Windows in general compared to OpenGL, however OpenGL's framerate tends to be more stable where DX can jump all over the place depending on what kind of primitives you're drawing.

Doh! Forgot about that again. I removed the dependency on OpenAL32.dll from the dynamic builds, but they still depend on ligcc_s_dw2-1.dll and libstdc++6.dll. I figure you're building dynamically anyway, so....

I rebuilt all the libs and re-uploaded them to sourceforge.

New links :

Allegro 5.1.13 build 2

Allegro 5.1.X latest version

There are dynamically linked debug builds of all the demos and examples in there. It would be really awesome if people could run them and see if they all work as expected. You can use gdb to get a backtrace if they crash. The dlls need to be copied into the example or demo folders or else you can just add the bin/dlls folder to your %PATH%.

Thanks for reminding me Neil.

E.

Wow, that was fast, many thanks for your efforts, they are appreciated.

I tested it out again, found bugs... in my game code, not yours.

Seems to work fine. I statically compiled/linked everything, done a clean rebuid and tried my best to hide all the DLLs from my paths and it still seems to run fine even though those two dlls "libgcc_s_dw2-1.dll" and "libstdc++-6.dll" do not APPEAR to be in the path anywhere. Does it still require them when statically linked? Or perhaps do I have them in my path somewhere I do not know. I would rather not have to include the, but if I have to I will, not a big deal really. Also, just to clarify, "OpenAL.dll" is no longer needed? I statically link everything, even my debug versions. Using the compiler you zipped as well as your binaries (best idea ever by the way!).

Anyhow, so far I am pleased.

You're welcome. With my new laptop, 4 cores and a SSD, it makes it child's play to rebuild allegro now. Whereas it took hours before.

You should only need libgcc_s_dw2-1.dll and libstdc++-6.dll when you build using the dynamic libraries. I should have eliminated the CRT from the static builds. And I got rid of the dependency on OpenAL in both builds.

And as a commentary, MinGW-Get is a nightmare, doesn't provide the latest versions of gcc, and won't even minimize when it's updating your packages. Dumbest idea ever.

Awesome. So far that seems to be testing out okay.

At first I was reluctant to use the NuGet version for VS... So many years accustomed to the normal drill of setting dependencies, include and library directories, Linker input files. However, I have to admit this is just brilliant! Everything just works and the installation is super easy. This is totally the way to go for Allegro. The easy installation should increase the user base on the long term

Indeed, NuGet is very nice. I used to be the same way, managing include paths, libraries, etc. manually (and meticulously, due to... programmer OCD issues), but what finally converted me was using version control (Git). Keeping opaque third-party binaries directly in my Git repo means it increases in size every time you modify the file, so NuGet was a breath of fresh air.

One thing I don't like is that Visual Studio doesn't put NuGet in the PATH, even when you use the Developer Command Prompt, making it difficult to automate restoring dependencies for a fresh source tree.

Another great thing about the Allegro packages in particular is they add an Allegro page to your project settings, allowing you to change add-ons, static/dynamic, etc. on the fly. This is a great convenience that was very tedious to manage when Allegro only provided loose binaries.