Allegro 5.2.4 released!

Another release of Allegro!


Download source and MinGW binaries at at downloads page. Ubuntu and Nuget packages are also available. Homebrew will be updated soon.

Changes from 5.2.3 to 5.2.4 (February 2018)

The main developers this time were: Sebastian Krzyszkowiak, Elias Pschernig, SiegeLord.


  • Fix errors when reading/writing 0 byte buffers (Bruce Pascoe).

  • Re-initialize TLS when Allegro is installed (Issue #865).

  • Add al_transform_coordinates_4d.

  • Don't initialize the trace mutex multiple times (Issue #874).

  • Fix 3D (non-projection) transforms with al_hold_bitmap_drawing.

Raspberry Pi port

  • Fix compilation on RPI.

Android port

  • Remove limit on the working directory length.


  • Fix build with older Android NDKs.

  • Remove glClear hack for Android 2.1.

Linux port

  • Make compositor bypass configurable in X11, and bypass only when fullscreen by default.

OSX port

  • Fix a few OSX retina scaling issues (Issue #851).

Audio addon

  • Fix ALSA lag.

  • Add an option to use the desktop window when initializing DirectSound (Issue #877).

Font addon

  • Add support for bmfont format.

Native dialog addon

  • Resize the display on Windows when hiding/showing the menu (Issue #860).

  • Detect when al_popup_menu fails to actually work under GTK (Issue #808).

  • Don't clear the top-level menu when destroying the popup menu.

Build system

  • Don't link in libm on MSVC for DUMB (Issue #847).

  • Don't use the LOCATION property (Issue #847).

  • Don't use SYSTEM for DirectX includes.

  • Add hints for mingw-w64 path locations for DirectX includes/libs.

Python binding

  • Fix the Python code-generation scripts to run under Python 2.

Lua binding

  • Add script to generate LuaJIT C API for Allegro 5 (BQ).


  • Many improvements (Andreas Rönnquist, others)


  • Add a texture to the skybox in ex_camera.


b4c538c754a8ff8592544b5ac8c608be1cada4dfa4fdd286f749d963d77ac638  allegro-
6b4fa42c7966bb954191185798b5aaa6f5bb1ed79ec28a67880ea7e556d1723f  Allegro.
346163d456c5281c3b70271ecf525e1d7c754172aef4bab15803e012b12f2af1  allegro-

Chris Katko

Woo!!!!!! Thank you for your work.


Good job. Thanks mate :-)

Edgar Reynaldo

I see you already upgraded to 7.2.0. Very nice indeed. Have to say, that Allegro comic is kind of scary. :D

Neil Roy

Very nice, and I like the prebuilt binaries. Still not sure if I ever want to compile this myself. ;)

Edit: Okay, just tried out the precompiled libs with my Deluxe Pacman 2 game, as I usually do. It seems to be a good test program as it compiled fine with previous versions and I have not worked on it at all, so it should compile fine now... of course... as usual... it did not. I am noticing something new, I don't know what it is so I don't know how to deal with it. Definitely not anything I need in my own program but...

||=== Clean: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
||=== Build: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `WebPGetFeatures':|
F:\msys64\mingw32\include\webp\decode.h|431|undefined reference to `WebPGetFeaturesInternal'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `WebPInitDecoderConfig':|
F:\msys64\mingw32\include\webp\decode.h|467|undefined reference to `WebPInitDecoderConfigInternal'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `load_from_buffer':|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|53|undefined reference to `WebPDecode'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `al_save_webp_f':|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|132|undefined reference to `WebPEncodeLosslessRGBA'|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|136|undefined reference to `WebPEncodeRGBA'|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|146|undefined reference to `WebPFree'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(opus.c.obj)||In function `init_dynlib':|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|102|undefined reference to `op_free'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|103|undefined reference to `op_channel_count'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|104|undefined reference to `op_open_callbacks'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|105|undefined reference to `op_pcm_total'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|106|undefined reference to `op_pcm_seek'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|107|undefined reference to `op_pcm_tell'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|108|undefined reference to `op_read'|
||error: ld returned 1 exit status|
||=== Build failed: 14 error(s), 0 warning(s) (0 minute(s), 10 second(s)) ===|

Of course, I should probably stop using monolith and just use the individual components I need to avoid this. But, if this helps someone else understand what is up...


Thanks, Neil, for testing, I appreciate it. There's two things here. First, the webp dependency is accidental, when I was building the binaries it picked up my globally installed version... this will require new binaries, which I'll upload shortly. The opus dependency is meant to be there, and you can download it from here You link -lopus -lopusfile.

In fact, using the individual libraries wouldn't help you here, unless you don't use image and acodec addons at all. The reason why these dependencies exist even in static libraries is that Allegro supports determining the file format at runtime (via al_load_bitmap and al_load_sample etc) which means that the linker can't know for sure that you won't use that code, and remove it.

Neil Roy

Ah, okay. I had a feeling that at least one solution would be missing links.

On a positive note: I thought the prebuilt binaries with the new version is a huge plus for this. And the locations to download them seemed fairly well organized, so koodos for that.

I just tried another clean compile with the new upload and opus links, it helped, but still missing something. I don't know if there is a specific place I should link opus? After any others? I tried at the end of my links, the start, in the middle... I am using Code::Blocks/MinGW7.2 (new one, fresh install).

||=== Clean: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
||=== Build: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_get_packet_duration':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|742|undefined reference to `opus_packet_get_nb_frames'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|744|undefined reference to `opus_packet_get_samples_per_frame'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_clear':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1479|undefined reference to `opus_multistream_decoder_destroy'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_float2short_filter':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|3131|undefined reference to `opus_pcm_soft_clip'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_decode':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|2729|undefined reference to `opus_multistream_decode_float'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_update_gain':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1332|undefined reference to `opus_multistream_decoder_ctl'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_make_decode_ready':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1363|undefined reference to `opus_multistream_decoder_destroy'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1364|undefined reference to `opus_multistream_decoder_create'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1359|undefined reference to `opus_multistream_decoder_ctl'|
||error: ld returned 1 exit status|
||=== Build failed: 10 error(s), 0 warning(s) (0 minute(s), 9 second(s)) ===|


Maybe flip the order of -lopus and -lopusfile.

Neil Roy

Just compiling Allegro myself to see how that goes, I will then try your build out again before I try my own (shouldn't make a difference if it is a linking issue). I think I did try flipping them, but... I'll try that again and let you know how that goes.

While compiling Allegro, I am seeing warnings about mixed declarations and code. Wouldn't it be best to compile this with C99 at least? C99 was a nice version of C to start with, and supported by all modern compilers these days. I prefer C11 myself but.

Oh, when I downloaded your version I found it funny that your build is dated February 28th, and it is still February 27th here... so I feel like I am trying the Allegro of the future! :P ;)

<still waiting on this compile>

Okay, my own personal compile of Allegro 5 FINALLY works, examples are working, so YAY for that. Thanks to your deps you included.

I recompiled using your build and after I flipped those, it linked just fine and the game runs, so yay for that too.

For other users, just note for them they need to link...

-lopusfile -lopus

(or for Code::Blocks)

opus that order.

I did see something on my debug screen to do with libpng, and I remember seeing this many years ago with another version and I don't recall what the solution was. The game works, I don't see a problem (yet), but this bugs me...


Update: Apparently the newer version of libpng is more strict and some PNGs may contain some sort of older data in the header. The warning is "harmless" and can be ignored. Warnings bug the shit out of me, so you need to download special software (ImageMagick) to strip the offending garbage out of your header and the warnings will go away. You could probably write your own Allegro 5 program to do this as well, which I may just do.


If I understand correctly, the colors of the offending images will appear differently on different people's screens. Stripping the wrong color profile is required to at least obtain the same rendering on everyone's screen.

Neil Roy

What I may just do is perhaps write my own conversion program using Allegro 5 to load in PNGs and resave them. See how that goes. Then I could at least automate the whole process easier. Not too big of a deal I guess.

On a positive note, been compiling this version of allegro just fine without trouble thanks to the deps included. Being able to find binaries and deps etc... easily will really go a long way to helping t his library.

I went through all the example programs. The ex_threads one crashed on me a couple seconds into it. And one other one to do with menus (ex_menu I think?), one of my menu clicks crashed it. Otherwise everything else worked great. It's been a while since I looked through the examples and there's a few more that were new to me. Looks really good I must say.

I used the GUI version of CMAKE which helped out a great deal in getting Allegro compiled, then I made Code::Blocks-MinGW Makefiles for it so I could easily load it all into Code::Blocks and compile from there which was also much nicer.

My Deluxe Pacman 2 link below is compiled with this version now.

I just noticed, when trying to compile a static, "Release" version of Allegro the following examples wouldn't compile for some reason...

Not building ex_color
Not building ex_depth_mask
Not building ex_haptic2
Not building ex_font_justify
Not building ex_font_multiline
Not building ex_logo
Not building ex_projection
Not building ex_ttf
Not building ex_audio_chain
Not building ex_synth

This could have at least partially to do with the following problem...

Performing Test TTF_COMPILES
Performing Test TTF_COMPILES - Failed
CMake Warning at addons/CMakeLists.txt:126 (message):
  FreeType doesn't compile.  Disabling support.

The rest compiles okay.


Freetype is unfortunately a bit of an annoying dependency, as it has dependencies of its own that there's no good way to automatically detect. To get the freetype in the dependency package to link, you need to pass -DFREETYPE_ZLIB=on -DFREETYPE_PNG=on when calling Allegro's cmake.

Neil Roy
SiegeLord said:

To get the freetype in the dependency package to link, you need to pass -DFREETYPE_ZLIB=on -DFREETYPE_PNG=on when calling Allegro's cmake.

Thanks, that seems to have corrected the problem. Compiling it again now.

Update: Okay, I got just about every combination compiled I could think of, Release, Debug and Profile; Static and Shared. Both individual libs and monolith, just because I could. ;)

When recompiling the examples, I retested ex_thread.exe and ex_menu. Both crashed. ex_thread crashed right away. ex_menu crashed when I clicked "New #1".


Maybe we should consider vendoring STB's excellent one file libraries and use those in case the dependency isn't found. For example, for TTF: ://

Edgar Reynaldo

What is the official C standard for Allegro? I get tons of warnings when I compile the allegro examples. I want to get rid of them.


There is no one standard, it just needs to compile on the compilers we care about. We have a warning enabled for anything that's not C89, for the sake of older MSVC compilers, but everything since MSVC 2013 could compile non C89 stuff, so that warning is a bit overzealous right now.

Edgar Reynaldo

Will you accept patches for anything compiling with warning on default settings with mingw-w64-gcc 7.2? A lot of it is "C99 standard requires declarations before code" and a few incompatible pointer types.

How do I pipe all output from make to a single file so I can search and index it?

cmd std stream redirection operators are retarded. How do I pipe stderr to stdout and then pipe that to a file?


We definitely should fix all the warnings, but sometimes fixing a warning means disabling the warning. The declaration after statement stuff is definitely of the latter variety, none of the compilers we encourage have a problem with that anymore.


cmd std stream redirection operators are retarded. How do I pipe stderr to stdout and then pipe that to a file?

thecommand > out.txt 2>&1

Neil Roy

"C99 standard requires declarations before code"

This is untrue. C99 got rid of this requirement. Only C89/C90 (they are the same version, just different standard organizations) has that requirement, C99 corrected a lot of these problems with C, including getting rid of that requirement.

If one wanted an early C standard to adopt, I would say stick to C99 at the earliest, considering some of the problems it finally corrected, like assuming ints and declarations before command requirement removed, _Bool, <stdint.h> etc...

When I recompiled Allegro (finally), I added in -std=gnu11 to the C Cmake options so it was compiled as a C11 library, which modern C compilers support. But for MSVC, I would say go for C99. It compiles C99 just fine, and has even adopted some newer C conventions to keep it compatible with C++11 or better.

SiegeLord said:

We definitely should fix all the warnings, but sometimes fixing a warning means disabling the warning. The declaration after statement stuff is definitely of the latter variety, none of the compilers we encourage have a problem with that anymore.

Yes, that warning is absolutely not required anymore at all, and it is the warning that comes up more than anything else. As I mentioned, C99 removed that requirement and added in many features that Allegro uses, so you pretty much need C99 anyhow, it added in _Bool and <stdbool.h>, which Allegro uses. It added in the different integer types with <stdint.h> and it removed the requirement for declarations before code. The last C version that required that was C90, and even MSVC supports all the features of C99, and even some newer C stuff. I think in 2018 it's time for people to let go of 28 year old standards and compilers! ;) Heck, even the C11 standard is 6+ years old, will be 7 years old this December.

Edit: With some research, the reason why variables were limited to the beginning of scope (not nessecarily the start of a function), was due to limited computer memory and CPUs at the time and single pass compilers. So if someone absolutely cannot compile Allegro due to this limitation, than their computer won't be able to run anything made with Allegro either, so it is pointless to stick to the C90 standard when C99 was such a huge improvement.


My Linux Mint distro did updated Allegro. I was surprised how much fast they added to the repositories (Ubuntu ones?).

Seems to work nicelly, so nice work and thank-you, guys. :)


So i noticed that it was an installed program that is causing the al_create_display to bug out. What would happen is the display allegro variable will still be null and the display would flicker a bunch of times.

The program is called Duet Display which allows duel screen using an ipad. When this program is installed that function call no longer works

I would like to report this somehow but don't know how to go about it


Showing my love guys! :)

Edgar Reynaldo

Nice work SiegeLord. ;)

I noticed you fixed some build issues, like finding DirectX and other libraries in the newer version of the mingw-w64 compiler cmake script. As well as adding in the static runtime option for mingw.

I attached a full build log on MinGW using the new GCC 7.2 compiling as is. It is attached here.

I know there are current and official binaries, but to hack allegro properly I needed a clean build, so I rebuilt everything. I hope these binaries are correct, otherwise I will fix them.


Included are html and chm docs, dlls and libs and includes for all dependencies including allegro. Current list of supported dependencies are FLAC, Dumb, Enet, Ogg, Vorbis, Theora, libJPEG, libPNG, zlib, PhysFS, FreeType (static only, but needs libpng and zlib sigh ) and I even threw in MAPM for anyone interested in arbitrary precision numbers and math.

Also included are the test driver and the test configs as well as dynamic debugging versions of all the examples. OOPS I forgot the demos, oh well, add that to my TODO.

I had to hack enet to produce static and dynamic versions. I had to patch theora to properly compile the libs because the examples were broken.

Full list :

mapm from git


Since I forgot the demos, I thought I would take a second look, and some dlls were in the wrong folder. I have since rebuilt the dynamic libraries and the demos and included them in a new version of the binaries. I also fixed a broken section in the chm manual. You can get them all here :


Thread #617292. Printed from