Allegro 5.2.1 released!

Woo-hoo, another release of Allegro! This release brings lots of fixes for annoying bugs and a few new features. Enjoy!

In terms of packaging, I've once again changed what the msys2 binaries contain. They now contain dlls with dynamically linked runtime. Statically linked runtime proved to be too hard to use. I've also fixed the Nuget package a bit.

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.

Changes from 5.2.0 to 5.2.1 (July 2016)

The main developers this time were: Elias Pschernig, Trent Gamblin, SiegeLord, Ryan Roden-Corrent, Boris Carvajal and Peter Hull.


  • Optimize bitmap holding a bit (Bruce Pascoe).

  • Add al_get/set_depth/samples (OpenGL only for now).

  • Optimize destruction performance when you have thousands of objects (e.g. sub-bitmaps).

  • Use low floating point precision for the OpenGL fragment shaders, which helps performance a lot on mobile platforms.

  • Don't stop and join the timer thread when stopping the last timer (prevents unnecessary delay in this situation on some platforms).

  • Add al_backup_dirty_bitmap and al_backup_dirty_bitmaps to more finely control when bitmap context backup is performed.

Android port

  • Fix Android app issues when woken up during sleep.

  • Specify the Android toolchain file on the command line now. ANDROID_NDK_TOOLCHAIN_ROOT now has to be specified in an environment variable.

OSX port

  • Improve joystick enumeration (Todd Cope).

  • Make al_set_new_window_title work correctly.

  • Don't send duplicate mouse move events.

  • Fix mouse warping behavior.

  • Exit fullscreen mode if ALLEGRO_FULLSCREEN_WINDOW is set when destroying a display (otherwise if you destroy and recreate display without terminating the program, a white window kicks around).

iOS port

  • Make it compile again.

  • Don't backup textures as it is unnecessary.

  • Update minimum iOS to version to 6.1.

  • Disable the native png loader in favor of libpng, as it is broken on Apple's end.

  • Create library when creating the archive.

Windows port

  • Fix the D3D target bitmap bug.

  • Clear display to black right away to avoid an ugly white flash.

Raspberry Pi port

  • Fix system cursor support.

Linux port

  • Make al_set_new_window_title work correctly.

Build system

  • Use PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR instead of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. This lets you use Allegro as a sub-project in your CMake project.

  • Fix GDIPlus finding in cmake-gui (Bruce Pascoe).

  • Add .gitignore and ignore build/ dir (Mark Oates).

  • Fix building examples with non-Allegro dependencies with the monolith build.


  • Various documentation updates (Daniel Johnson and others).


  • Add more #include statements in Allegro headers, so it's easier to use them in isolation (Jordan Woehr).

  • Allow marking tests as being hardware only.

  • Prefix some private Allegro macros and types to not pollute the namespace.

  • Make set_shader_uniform api const-correct (Bruce Pascoe).

Audio addon

Acodec addon

  • Allow file-backed audio streams to be restarted after they finish.

  • Add Opus codec support.

Image addon

  • Fail gracefully if not built with PNG/JPG loaders.

Font addon

  • Make al_get_text_dimensions and al_get_glyph_dimensions return exact bounding boxes (koro).

  • Add ALLEGRO_GLYPH structure and al_get_glyph, allowing for some additional optimization when drawing fonts.


  • Add more controls to ex_audio_props.

  • Add an example of using Enet with Allegro.


34acb0346780b9d262c7e459701646a6046bec88db6056e17244c558fa1adfcc  Allegro.
d229402acca828882baa48e77a5ae3405d2d53565db4b2c834b3a7db1da66323  allegro-
9e88cda6bbe2b56fb47fe253f9b22868c821e78a19004b5742a90f66ac4fe927  allegro-5.2.1.tar.gz


Thank you developers, for all your hard work on this great library!


Hou pinaise je vais tester cette apr├Ęs midi pour le bug D3D !!!

Cool, I think the fix might help some of my progs which were acting strange (i.e only OGL working in windows)

Edgar Reynaldo

Awesome. Great work guys.

Will be working on putting together a binary distribution of MinGW and Allegro 5.2.1 and all the dependencies here in the next few days.


I tried updating the pre-built Allegro monolith included in jalleg from the zip I downloaded at, but it does not work. It looks like it might depend on some (new?) libraries, when I try to load it, I get the error "Can't find dependent libraries".

Looking at the output from Dependency Walker, I see two new DLL dependencies on 5.2.1 that were not on 5.2.0: LIBGCC_S_SEH-1.DLL and LIBSTDC++-6.DLL. It looks like Allegro was compiled in C++ mode, or at least with structured exceptions handling turned on?


That's this change:

SiegeLord said:

In terms of packaging, I've once again changed what the msys2 binaries contain. They now contain dlls with dynamically linked runtime. Statically linked runtime proved to be too hard to use.

Is it difficult for your use case to bundle those two extra binaries? I rarely get feedback for these msys binaries (the only one I got was that the statically linked versions were too hard to use).


Good job. :) I'll test it right now.

Anyway, did you read this? I'll really appreciate a comment from the development team. Pretty pleeeeeease? ;D


The library loader I use can't automatically load dependent libraries. There might be a workaround I can try to see if the dynamic linker can resolve symbols from the current process first, then I can load libraries manually in order.

But I don't understand it, because 5.2.0 binaries worked perfectly, and I don't understand why I need to include the entire C++ runtime and structured exceptions support library for a pure C library (it looks like Allegro doesn't even call any public members of the C++ runtime). I would also need to be able to find the exact versions of those DLLs needed, as they aren't in the ZIP. It's been quite a few years since I've used gcc, but I thought with a certain flag you can turn off C++ support?


C++ under windows is non-optional due to how much DirectX we use. The issue for bundling the runtime into the dll is that when linking the library manually in a native language (C/C++ etc), you'll need to be very careful with flags... which is a royal pain. For runtime loading, it of course doesn't matter.

Anyway, the issue was mostly a naming issue, as always. It's trivial for me to make both kinds of dlls, I just need to come up with a way to either include them in the same archive, or come up with the names of two archives.


OK, I didn't know about that requirement. I assume it wasn't needed because I saw hardly no symbols from libstdc++ in use. Ultimately, all I need is a DLL that can be loaded without dependencies on Windows 64 bit, however that is compiled. If that is something the Allegro team can provide it would be greatly appreciated. I re-package allegro-monolith into a JAR form and publish to a standard repository for any jalleg or Java user using JNA. If you prefer to keep only the dynamic link version published, that's doesn't matter, if I can get a copy of the static build for my package.

Thanks for the great work on Allegro and all the support!


Thank you so much. Especially SiegeLord for those NuGet packages. Never used NuGet before and now it is soooo easy to add Allegro to a project.


Awesome work! I just got back to some C++ and Allegro after dabbling with Unity.


Alright, I added the statically linked runtime versions of Allegro. They should be named in a self-explanatory fashion.


God Job!!!!;D


Great! I downloaded the static library, and it worked. Then I released an updated jalleg-rt package for 5.2.1.

SiegeLord said:

Optimize destruction performance when you have thousands of objects (e.g. sub-bitmaps).


Mark Oates

ALLEGRO_UNSTABLE is still required for al_set_new_bitmap_samples and al_set_new_bitmap_depth?


Yep, we still haven't gotten around to implementing it for Direct3D. The way you'll be able to tell when it won't be necessary is that it won't have the 'unstable API' in the docs, and it'll be in the changelog (if I remember it :D).

Mark Oates

Awesome 8-)

Thread #616406. Printed from