Allegro 5.1.12 released!

Once again, I present to you the newest release of the WIP branch of Allegro. This time there were a lot more new features added than during the previous release, because, as everybody knows, it's much more fun to add new bugs rather than fix old ones. Just kidding, we fixed plenty of old bugs too ;). Some of the features are pretty nifty, such as the clipboard support.

We had quite a few new contributors this time around, and in fact most of the changed lines of code were not even done by the old team! That's pretty exciting.

Download the sources here.

Download the Windows dependencies here.

Download the Windows binaries here.

Once again, I changed the format of the MSVC binaries. Now all of the dependencies are statically linked, including the MSVC runtime. The only exception are the debug builds of Allegro, which link the dynamic runtime still. Hopefully this works well for everybody. The motivation for that was that people probably don't care what Allegro does under the hood, so we shouldn't burden people by making these dependencies explicit. Another new thing is that we now have MSVC 2015 binaries.

MinGW and Ubuntu binaries are not yet ready and will be made in the coming days.

EDIT: Homebrew is also now available.


Changes from 5.1.11 to 5.1.12 (September 2015)

The main developers this time were: Bruce Pascoe, Beoran, Elias Pschernig, SiegeLord, Trent Gamblin.


  • Add al_set_blend_color and al_set_blender, for additional blending modes.

  • Add ALLEGRO_MAXIMIZED display flag.

  • Add al_reparent_bitmap, al_get_bitmap_x/y. This allows changing the offset of a sub-bitmap.

  • Make ALLEGRO_PIXEL_FORMAT_ANY_NO_ALPHA actually pick a format without an alpha channel.

  • Add al_premul_rgba and al_premul_rgba_f convenience functions for dealing with pre-multiplied alpha blending mode.


  • Fix key auto-repeat on modern X11 versions.

  • Fix mis-detection of some joysticks on Android.

Android port

  • Fix a crash when minimizing the app before Allegro has been initialized.

Linux port

  • Add al_get_x_window_id (Robert MacGregor)

OSX port

  • Fix some deprecated API usage.

Windows port

  • Fix a dangling pointer issue resulting in crashes when resizing on Windows 10.

Build system

  • Build with multiple processors when using MSVC.

  • Make XInput2/touch input optional on Linux.


  • Various documentation improvements.

  • Fix some badly formatted flags (Rodolfo Lam).


  • Allow injecting Allegro events into event queses using al_emit_user_event (Ryan Roden-Corrent)

  • Add al_set_new_window_title and al_get_new_window_title.

  • Add al_get_clipboard_text, al_set_clipboard_text and al_clipboard_has_text.

  • Add al_resume_timer (Ryan Roden-Corrent).

  • Add al_get_cpu_count and al_get_ram_size.

Audio addon

Font addon

  • Add al_draw_glyph, al_get_glyph_width, al_get_glyph_dimensions and al_get_glyph_advance. These functions are useful when additional control is needed when drawing text.

  • Add al_set_fallback_font.

Image addon

  • Add al_register_bitmap_identifier, al_identify_bitmap and al_identify_bitmap_f. This allows detecting the bitmap type by looking at the initial few bytes in the file rather than relying solely on the extension.

  • Allow saving bitmaps with uppercase extensions (Daniel).

Native dialog addon

  • Fix crashes when creating menus with sub-menus (Todd Cope).

Video addon

  • Allow using both Ffmpeg and Theora backends simultaneously.

  • Reduce latency of al_get_video_frame for the Theora backend.

  • Make the Theora backend send the ALLEGRO_VIDEO_FRAME_SHOW events.

  • Rename al_get_video_width/height to al_get_video_scaled_width/height which now return the aspect corrected size of the video frame.

  • Rename al_pause_video/al_is_video_paused to al_get/set_video_playing.



  • Remove al_get_video_aspect_ratio.


  • New examples: ex_reparent, ex_inject_events, ex_clipboard, ex_cpu, ex_timer_pause.


3b66fbce9ae86f17b589eecea4406fd1d291dfa4e766a7a8cff1e0f0aba265d9  allegro-
78d1056d6cc0e4527ef35646f612a80456442a7866445ca7cf61a11bd64e79c0  allegro-5.1.12.tar.gz

Mark Oates

I'm super excited. This one has gotten a lot of action, and is the first version collaborated on github if I'm correct. :)

I've really been looking forward to this one:

SiegeLord said:

Allow injecting Allegro events into event queses using al_emit_user_event (Ryan Roden-Corrent)

Of course, these are super neat and will make it into my code:


Add al_get_clipboard_text, al_set_clipboard_text and al_clipboard_has_text.

Not something I would think I'd ever use, but I'm glad the pre-multiplied variants have made it in.

Also these will probably replace my existing equivalents:


Add al_draw_glyph, al_get_glyph_width, al_get_glyph_dimensions and al_get_glyph_advance. These functions are useful when additional control is needed when drawing text.

Oh no! The manual is missing some of the new function signatures.


Thanks for the awesome work everyone! I'm gonna try it out soon.


Oh no! The manual is missing some of the new function signatures [].

Works now 8-)


Kudos to you all (and Kang thinks this is a pretty nice release too.) :)


On Windows, al_get_cpu_count seems to return the number of logical processors, as opposed to the number of physical cores. Is it the same on other platforms? Should this be documented?

I think it's ok for it to work this way, it's the same as Java's Runtime.availableProcessors() method.

Thomas Fjellstrom

I think it's pretty normal to just report number of logical processors. It's fairly safe to assume you can use all logical processors as if they are physical cores unless you are doing some super duper heavy calculations that HT would only make slower. Games though tend to do enough waiting that HT will only accelerate work loads.

It might make sense to add a "al_get_physical_cpu_count" or something equivalent, in case you really care.


Awesome! I'll give it a try.


Bumping the thread so I can edit it when I finally get around to making more binaries so I can edit the OP >_<.


Thread locks too soon!


Thread locks too soon!


Edgar Reynaldo

How do I get the library, the demos, and the examples all to build statically without depending on the C or C++ std libraries? I've tried several different flags, trying these first in cmake-gui :
CMAKE_EXE_LINKER_FLAGS -static-libgcc -static-libstdc++
CMAKE_MODULE_LINKER_FLAGS -static-libgcc -static-libstdc++

With these flags set, it builds the static library, and then fails to build the cosmic protector demo, which is C++. It fails because of redefinition errors in std::string and __gxx_personality_v0 due to relinking the std library somehow.

This is MinGW 4.8.1 on Vista. The CMake options are :

So what should I be using?

Thomas Fjellstrom

Libraries should not be statically linked against any other libraries that are going to be used from other code. Otherwise you get symbols being redefined in multiple object files.

A static allegro library should not link to anything. (imo)

Edgar Reynaldo

If I compile with no flags present for any of the aforementioned cmake variables then the examples all depend on lib_gcc_sw-2.dll or whatever and libstdc++-6.dll. I want them to be static linked to the CRTs as well.

Thomas Fjellstrom

You don't link the libraries against any lib at all. GCC won't do it either unless you force it. It'll leave the symbols as undefined. When you go to link your actual program, you tell it to link to everything statically.

Linley Henzell

Thanks for the work, everyone!


Well done guys !!

I'll take my testing tour soon :-D


You can use -static instead. It's usually a bad idea to use that in Linux, but I find my mingw .exes created with it work fine and don't depend on any DLLs.

Gideon Weems

The font add-on got some really nice additions this time around. Thank you to all involved! :D

Rodolfo Lam

Congratulations on the release!

Now SiegeLord, just to confirm, the change you made to the way allegro is built means that we no longer have to download the allegro-deps folder from Gna! anymore? Or I misunderstood the post?


You only need them if you do static linking. For dynamic linking, you just need Allegro's DLLs.

Rodolfo Lam

OK Great!, so that is a weight off, was writing a guide to help someone install the library here, when I though that I missed to explain the installation of the dependencies ;D


Nice. I was slightly worried some time but then I found that the git repository was moved, so I'm back on track now.

I think I really like the clipboard stuff, in fact someone has asked me about using the clipboard just this week.

During compiling with VS2013, I found a compile error in bitmap_io.c, so I'l attach a patch for this.


Thanks, applied it:

Interesting though that neither clang nor gcc even warn about the missing * - I guess it might even be optional in the standard just MSVC requires it.


I wonder how I didn't hit this when making the binaries... the 2013 archives definitely have the allegro core library in them...


Just realized, this is probably similar to how "x = &memcpy" and "x = memcpy" are identical in C++, here the & for the function pointer is optional.

Still, it's a mystery why MSVC 2013 would sometimes have a compile error and sometimes not.

Rodolfo Lam

So maybe you found a compiler bug? It's always funny to try to convince compiler devs their side is wrong and not our code...


It's not a compiler bug, it was a warning actually and I'm compiling with warnings as error whenever I can. Warnings can find pretty interesting things in your code...

Thomas Fjellstrom
tobing said:

It's not a compiler bug, it was a warning actually and I'm compiling with warnings as error whenever I can. Warnings can find pretty interesting things in your code...

But -Werror is rarely useful :P


We can't compile Allegro with -Werror because CMake's compile check tests will often fail in that situation. It'd be a lot of pain to fix all of them. Allegro's source itself should compile without warnings (and does on Linux). It'd be nice to do so on MSVC, but many of the warnings are completely terrible (especially the warning for while(1) loops), so we'd have to disable a good portion of them first.


I guess that the usefulness of warnings strongly depends on the compiler, but I'm trying to write code that is free of warnings whenever possible. Currently I'm porting one of my allegro apps to native 64 bit, and for that all the warnings about losing digits in conversion can be a nuisance - or hint to where things have to be adapted.

With MSVC 2013 I'm using /W3 /WX which does not make ALL warnings to errors, but all of level 3 and below. Plus I have disabled warning 4996 (about using deprecated stuff) and 4267 (conversion from size_t loses digits) for the 64 bit version. With that, all of allegro compiles and works just fine...

Edgar Reynaldo

Hey guys, just wondered if there is a way to configure cmake to detect the static versions of libraries like ogg, vorbis, and theora instead of the dlls when I select SHARED=off for the build type. I know I can set the libraries to link manually, but this just bit me while I was trying to build fully static example programs. They linked to the dll.a files by default.

I should have some MinGW 4.8.1 binaries for 5.1.12 here in the next few days or so.


What I do is "rm lib/*.dll.a" and then cmake magically picks up the static libraries. Then whenever there's a mingw update I forget about it and am mystified for an hour why my static .exe doesn't work any longer :P

If there is a way to do it in cmake that would be nice, but I kinda doubt it, having worked with cmake a lot.


You'd need to fiddle with all the Find* functions (something like that is done by the audio addon). It's possible, but I'd just do what Elias said.

Edgar Reynaldo

Okay, I've been struggling with this for a few days now. I keep getting undefined references to libpng functions when trying to compile allegro 5.1.12.

1[ 55%] Linking CXX executable ex_color.exe 2 3c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x4f0c): undefined reference to `png_get_error_ptr' 4c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x4f2a): undefined reference to `png_set_longjmp_fn' 5c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x740e): undefined reference to `png_create_read_struct' 6c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7424): undefined reference to `png_create_info_struct' 7c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x744a): undefined reference to `png_set_longjmp_fn' 8c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7477): undefined reference to `png_destroy_read_struct' 9c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x74ba): undefined reference to `png_set_read_fn' 10c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x74cc): undefined reference to `png_read_info' 11c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7511): undefined reference to `png_get_IHDR' 12c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x759f): undefined reference to `png_destroy_read_struct' 13c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x75dd): undefined reference to `png_set_palette_to_rgb' 14c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7602): undefined reference to `png_get_valid' 15c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7652): undefined reference to `png_set_filler' 16c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7664): undefined reference to `png_read_update_i[ 55%] nfoLinking CXX executable ex_config.exe' 17 18c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x76a9): undefined reference to `png_get_IHDR' 19c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x76e0): undefined reference to `png_set_read_user_transform_fn' 20c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7761): undefined reference to `png_read_image' 21c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7782): undefined reference to `png_read_end' 22c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7792): undefined reference to `png_set_interlace_handling' 23c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x77a2): undefined reference to `png_set_gray_to_rgb' 24c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x77b2): undefined reference to `png_set_packing' 25c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x77c2): undefined reference to `png_set_tRNS_to_alpha' 26c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x77d2): undefined reference to `png_set_expand_gray_1_2_4_to_8' 27c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x77e2): undefined reference to `png_set_strip_16' 28c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x782b): undefined reference to `png_set_read_user_transform_fn' 29c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x78f7): undefined reference to `png_get_io_ptr' 30c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x7934): undefined reference to `png_get_error_ptr' 31c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../..\libfreetype.a(sfnt.c.obj):sfnt.c:(.text+0x794a): undefined reference to `png_error'

I've completely deleted freetype and libpng from my mingw installation and rebuilt them from scratch as well as deleting the allegro build directory and rebuilding allegro. I can't get rid of these errors.

It must mean I'm linking to the wrong version of libpng somehow, right?


For reference I'm using freetype 2.6.1 and libpng 1.6.18 in my build of allegro.


It might be a new thing for Freetype to require png support (did you compile it yourself?), as Allegro build system doesn't link libpng when linking in freetype.

Edgar Reynaldo

Yes, I built freetype and libpng myself with cmake.

That was it too. The new version of Freetype requires png to be linked in. I just added png and zlib to the CXX and C LINKER FLAGS fields and then everything built okay.

Edit - Update

I have the binaries for A5.1.12 and MinGW 4.8.1 ready. You can get them here :

And you can always get the latest version here :

If you have any problems with them, report them here on the forums and I will work on a fix for you. I think everything should work out of the box this time.

Dependencies are included, such as FLAC, freetype2, libpng16, ogg, theora, vorbis, dumb, and openAL. Enjoy!

Peter Hull

Possibly it's an optional dependency (I am looking at the CMakeLists.txt)

Edgar Reynaldo

You mean openAL? Yeah, it's optional. I forgot to turn it off though, so it's still there. :/

Oh sorry I didn't look at your link. You mean libpng is an optional dependency for freetype? I don't think it will hurt anything in this case, as libpng is provided with it in my binaries.

Bump. Don't want the thread to close yet. :/


Respect 8-)

Thread #615781. Printed from