Allegro 5.2.7 released!


Coming through! We've got another Allegro release! One notable feature of this release is that Elias got Allegro working semi-well with Emscripten (via the SDL backend), and adjusted our website to have some runnable examples:


You can find the source tarballs and MinGW binaries here (dependencies MinGW binaries are here here). Nuget packages are available here . Ubuntu and OSX packages aren't ready yet, but will be made soon.

Here's the changelog:

Changes from 5.2.6 to 5.2.7 (March 2021)

The main developers this time were: SiegeLord, Peter Hull, Elias Pschernig, Aldrik Ramaekers, Andreas Rönnquist.

Build system

  • Allow generating projects with a suffix (lorry-lee).

  • Fix build under Clang-CL in Visual Studio.


  • Avoid some undefined behavior errors.

  • Return key modifiers in ALLEGRO_EVENT_KEY_UP and ALLEGRO_EVENT_KEY_DOWN.

  • Allow calling al_map_* color functions before Allegro is initialized.

  • Allow minimum bitmap size to be something other than 16 on non-Android platforms (controlled via allegro5.cfg).

  • Add al_get_monitor_refresh_rate (only implemented on Windows for now).


  • Fix ALLEGRO_KEEP_INDEX flag for bitmaps.



  • The experimental Emscripten support (via the SDL backend) is now documented in README_sdl.txt.


  • Move more Cocoa operations to the main thread.

  • Explicitly link CoreVideo to fix the static build.


  • Issue #1125: Speed up OpenGL extension detection (Tobias Scheuer).

  • Use Unicode APIs when enumerating joysticks.

  • Use WM_DEVICECHANGE rather than polling to detect joystick hotlugging, reducing input drops and lags (Todd Cope).

  • Fix joystick polling period.

  • Restore WinXP compatibility by using slightly older API when loading shared libraries (Julian Smythe).

  • Fix build with HLSL disabled (Julian Smythe).

  • Raise DirectInput MAX_JOYSTICKS to 32 and DEVICE_BUFFER_SIZE to 128.


  • Issue #1224: Fix bug in SDL voice driver.

Audio addon

  • Allows playing sounds in reverse by specifying a negative speed.

Acodec addon

  • Fix edge-case looping in Ogg Vorbis stream (Cody Licorish)

Audio addon

  • Use more sensible values for PulseAudio's playback buffer, potentially
    resolving some crashes and high CPU usage.

Native Dialog Addon

  • Migrate from GTK2 to GTK3. Sadly, we lose menu icons as GTK3 dropped support for them.

TTF addon

  • Allow initializing TTF addon before the Font addon.

  • Shut-down the TTF addon automatically in al_uninstall_system.

PhysFS addon

  • Fix handling of native path separators.

  • Stop using deprecated PhysFS API.

Primitives addon

  • Fix segfault in al_draw_ribbon when num_segments > 128 (Rodolfo Borges).

  • Issue 1215: Correctly handle small scales when determining subdivision level
    for high level primitives (Robin Heydon).


  • Fix LaTeX errors in the generation of the reference manual PDF.

  • Add links to examples into the reference manual.

  • Allow pressing 'S' to focus the search bar in the docs.

  • Assorted documentation improvements.



  • `ex_audio_simple` now displays instructions and supports bidirectional looping.

  • Add default files to some audio examples.


7b2a778f62e990e6f2a9135a7580d9cf679a452c72cb5a5139e6f8a54fd35152  allegro-
c1e3b319d99cb453b39d393572ba2b9f3de42a96de424aee7d4a1abceaaa970c  allegro-
2d291fd8217bbe0fcb3efff4891318e43ab8c227fafb378b3c205a37225d6f3c  Allegro.5.2.7.nupkg
23c7aeb5ab9732a170160ee02dcf87a801600af7e6fd7bdf1423d0b8cac4999a  AllegroDeps.1.12.0.nupkg




Yay! Thanks for all the hard work.

Mark Oates

Heck yea, I love new allegro releases.

SiegeLord said:

Elias got Allegro working semi-well with Emscripten

our website to have some runnable examples:


Wow. Game changer. Elias, bringin' the heat!! 🔥🔥🔥.

I've got to get on this. That's amazing.


Allow pressing 'S' to focus the search bar in the docs.

edit: added a follow-up on this to the issue here.


Shut-down the TTF addon automatically in al_uninstall_system.

Woo! I have workarounds for this so can fix.

Edgar Reynaldo

I submitted a news item to so we'll be on the front page for a while after Matthew approves it.


Allegro+Emscriptem: Incredible. I'm testing but on my Linux the display is not coming. Will test on my Windows partition tomorrow.

Edit: Only Skater isn't working, Cosmic Protector is working fine !!

Jacob Moena

I am quite happy that we got Clang support in the Nuget package! I got a couple new delicious compiler error messages to fix that neither GCC nor VC managed to detect. :)
Thank you! ;D


That Emscriptem work is impressive! The SPEED example doesn't have a 'try' link, is that an oversight or is there a reason for that? I can't wait to play SPEED on the web...


Examples/demos without the 'Try' button are just known not to work well with Emscripten (e.g. their main loops don't fit a somewhat restricted pattern, they use shaders etc). We can and probably will fix them at some point, Emscripten is relatively easy to develop for.


Speed would be easy to fix but it's probably better if we fix the underlying SDL2/emscripten issues which make it not work currently :)

Basically we use emscripten with no threads at all, instead of using threads the web browser has a set of timers and periodically calls into javascript. To make this work with Allegro there's a workaround where al_wait_for_event() just returns control to the web browser instead of actually waiting and then whenever the browser calls back it collects events and if any are found continues with the application.

Now if an application ever has a loop which doesn't use al_wait_for_event() (like speed which is a line-by-line translation of A4 code) - that doesn't quite work :P

It would not be too hard to fix this, however emscripten actually does have threads, just as of a few weeks ago their bundled SDL2 did not support them yet. Once that is fixed upstream everything will just work on our side without extra work :)

Karadoc ~~

In case anyone is interested, I'm attaching an ancient and somewhat janky patch that I made ~10 years ago for the native dialogs addon. I apply this patch every time I build a new version of Allegro.

Without this patch, al_show_native_message_box running on Windows cannot make dialog boxes with custom button names. With the patch, it can - but they look bad. Message boxes without custom button names are unchanged.

The reason the custom button dialogs look bad is that my implementation uses the 'system' font rather than the usual message box font. And the reason for using the system font is that I don't really know anything about the win32 api, and I was just trying to make something that worked! At the time I was writing the patch, this was the best I could come up with. (It is certainly possible to get the right font with some more code; but it isn't totally straight forward.)

In any case, feel free to use it, or not use it. I personally use it for showing debug messages, and nothing else; so I don't really care what it looks like anyway.


Edgar Reynaldo

I made a Pull Request for some code to fix a DX window flickering upon creation when MSAA is enabled. It works for FULLSCREEN_WINDOW and WINDOWED modes on my NVIDIA, but not on my integrated Intel for some reason. It also doesn't work in true fullscreen modes, so I'm requesting help with the issue if anyone has the time to look at it. This has been a longstanding bug that still hasn't been resolved.

The pull request is here (with comments) :


When compiling a new game with freshly built allegro on linux, I got:

src/text2.cpp:4:10: fatal error: allegro5/allegro_native_dialog.h: No such file or directory
    4 | #include <allegro5/allegro_native_dialog.h>

allegro_native_dialog.h is in the allegro sources, but for some reason it wasn't copied to /usr/local/include/allegro5. Could you think of any reason why it wouldn't be copied? Perhaps a new dependency on linux?

I have a second question:

I scanned the cmake output for warnings. I added libopus, libwebp and libfreeimage. There is also a complaint about minimp3. I presume that refers to this:, but it's surprisingly hard to find any further documentation with google. Any chance there are any pre-built debian packages for this?

I doubt this is related to the native dialog problem though.

Edgar Reynaldo

On Linux, the native dialog addon depends on GTK3 now. It won't be included if that is not installed when compiling Allegro 5.


Good to know. I did apt get libgtk-3-dev and things are working again.

What would be the proper place to document this? The README.txt just has this paragraph:

Linux users likely have all the dependencies already, except PhysicsFS
and DUMB. If your distribution uses separate development packages, they
will need to be installed.  The packages are probably named *-dev or *-devel.

Which didn't help me a lot in this case.

In hindsight, there was a warning in the cmake output:

-- Could NOT find MiniMP3 (missing: MINIMP3_INCLUDE_DIRS) 
WARNING: minimp3 was not found
-- Found Freetype: /usr/lib/x86_64-linux-gnu/ (found version "2.10.1") 
-- Performing Test TTF_COMPILES
-- Performing Test TTF_COMPILES - Success
-- Found PhysFS: /usr/lib/x86_64-linux-gnu/  
-- Found PHYSFS: /usr/lib/x86_64-linux-gnu/  
-- Performing Test PHYSFS_IMPLICIT_ZLIB - Success
-- Checking for module 'gtk+-3.0'
--   No package 'gtk+-3.0' found
-- Checking for module 'gthread-2.0'
--   Found gthread-2.0, version 2.64.6
-- Found THEORA: /usr/include

But I missed it, it doesn't stand out as much as the other warnings (like the one for minimp3 for example). It would be nice if the warnings were more consistent.

Edgar Reynaldo

I may make binaries again, but I think bitbucket upload is broken atm or maybe forever


Please do if you can. I don't depend on them, but I think many first-time users do.

By the way, I've also updated the dockerized allegro build environment to 5.2.7

Edgar Reynaldo

I'm kind of waiting until the pull request gets considered


Please do if you can. I don't depend on them, but I think many first-time users do.

They could use the official binaries too...

I'm kind of waiting until the pull request gets considered

The flicker one? It says it's not ready, no? It's not clear what the status of it is.

Edgar Reynaldo

I need help on that one. My approach works for windowed modes, but not fullscreen ones, and I don't know how to fix it. I was hoping someone would have some helpful comments for me as to how to keep working on it.


Ah, okay, I'll try to take a look soon then.

Edgar Reynaldo

It's total BS of course, because DX9 is insane and so is whoever designed win32 and their Tech Center.

Relevant link :

fook me they had to do fullscreen different than windowed

Trying something for fullscreen now after I RTFM

Stuck again. Tried something, didn't work. Also, allegro is destroying and recreating display internals every time it tries a new mode that doesn't work.


I wrote some code a while ago to list all audio devices for the alsa, sdl, dsound and pulseaudio backend Is anyone interested in implementing the other backends (openal, kcm, aqueue, oss)? This would allow for features like audio device selection to be implemented.


That seems like a very useful feature. Perhaps for the other backends a dummy implementation would suffice for now? I.e. return an empty list or return an error code?

I don't like the idea of delaying a good feature just because it doesn't work on some more exotic backends.

Edgar Reynaldo

Yes, that's a good feature.

I made an amendment to my pull request in an attempt to enable full scene (fullscreen) antialiasing but to no avail.

Peter Hull

FYI Aldrik's already done it, just waiting for review & merge.


I think I've found a bug, since ex_threads doesn't work on my system (Xubuntu 20.04.2, I've just realized I should update it). It just creates a bunch of small windows and then exits with a "segment violation (`core' generated)". ex_threads2 seems to work.

I have no idea how to debug threads so I can't be for much more help. BTW, since Allegro.pas version of ex_threads2 doesn't work outside GDB (but it does inside GDB ???) may be it is something similar to this old bug in Allegro 4 (just speculating).

Edgar Reynaldo

ex_threads doesn't work with DX on Windows. It creates a bunch of threads and starts them all and they all create a window, and the window creation code isn't thread safe so it segfaults.

SiegeLord - could you look at the attached allegro.log and tell me what you see? I see a whole ton of "d3d_create_fullscreen_device: Mode not supported." messages. Why is allegro trying to create an unsupported mode? Can't the display modes be sorted or filtered somehow?

I should say, they originate in d3d_check_mode called from d3d_create_fullscreen_device called by d3d_display_thread_proc called by create_display_internals, which loops over the modes checking each one.


Is that the log from ex_threads?

Peter Hull

I don't know but d3d_check_mode looks a bit strange - if EnumAdaptorModes fails the whole function returns false (line 402), I would have though it should skip that mode and continue the enumeration?

Edgar Reynaldo

SiegeLord - that's the log from my MSAA test program.


SiegeLord - that's the log from my MSAA test program.

Try the patch from here

Dizzy Egg

Would it be possible (in the next build) to update the HLSL to something higher than v2?

Or even make it possible to choose which HLSL version to use? v2 is really limiting on the number of instructions that can be used.


I've done some updates and, on my Xubuntu 20.04LTS ex_threads doesn't work (freezes the computer) but ex_threads2 seems to work.

Edgar Reynaldo

@SiegeLord - sorry for the slow reply

So, your patch works for my Nvidia GPU, but not the onboard intel.

Which means, all the multisample requirements are being met, for fullscreen, fs window, and windowed mode, but ONLY with my Nvidia.



Which means, all the multisample requirements are being met, for fullscreen, fs window, and windowed mode, but ONLY with my Nvidia.

You mean, in the logs, it tries the first mode and succeeds? What happens with the Intel, it still tries many modes before it fails?

Bob Keane

It's great to see Allegro is constantly developing. I think I have a question or two though. I heard previous versions did not work well with Windows using C code. Has that been addressed or is that a major version issue? Also, has it been released on Fedora?

Bob Keane said:

I heard previous versions did not work well with Windows using C code

That's still an issue. To be clear, you can write your entire program in C, but you need to link in the C++ runtime, since Allegro uses some C++ internally. If this can be fixed, it won't require a major version.


Also, has it been released on Fedora?

No idea.

Peter Hull

On Fedora, dnf will install 5.2.4. I don't know who (if anybody) is in charge of updating that.

Edgar Reynaldo

SiegeLord - to be clear, it may be succeeding, but if allegro doesn't report the number of samples to be other than zero, it turns red. That's the only way I know if its ms.

What exactly is affected by msaa? Primitives? Triangles? Fonts? Bitmaps?


SiegeLord - to be clear, it may be succeeding, but if allegro doesn't report the number of samples to be other than zero, it turns red. That's the only way I know if its ms.

If you look at the logs on your Intel system, do lines like this:

display  D E:\usr\libs\Allegro52X\src\display_settings.c:212  debug_display_settings           [   0.51161] color: 32 (rgba 8880), depth: 0, stencil: 0, acc: 0000, samples: 0/0

Have the samples line be anything other than 0/0?


What exactly is affected by msaa? Primitives? Triangles? Fonts? Bitmaps?

It affects everything with polygon edges that aren't aligned to pixels.

Edgar Reynaldo

SiegeLord, in every case with the Intel, they all report the format as supporting 0/0 samples, all 64 of them for fs.

Yeah, the Intel reports everything as 0/0 samples. This laptop is from 2015, it's Windows 10, and the integrated chipset is Intel HD 5600 .

And by the way,

does anyone know what it takes to build MinGW-W64 with GCC 10 support? I despise MSYS2 and I want to build distributable binaries for MinGW-W64 since the package manager fell off the planet.



Why do you despise msys2 ?

Edgar Reynaldo

Because it tries to be like Linux on Windows but it sucks.


This thread shall live on.

Will there be a release to address some of the problems?


Will there be a release to address some of the problems?

No. Point releases are pretty much just for newly broken releases (like it doesn't build or something) or regressions; these issues have been there for over a decade, they're not worth releasing over.

I do want to release 5.2.8 earlier than next year though...

Edgar Reynaldo

I think it's worth it this time. MSAA and no window flickering? Some people are still using custom builds and need binaries that are fixed. I'll probably do it sometime soon. Pissed that mingw-w64 binaries are still stuck on GCC 8.1 and I don't know how to build MinGW-W64 with GCC 10 or I would build binaries for that too.

EDIT The log deadlock sucks too.


And yet msys 2 is having gcc version 10.3.0 ;-p


i had problems with minGW too

something related to the symbol _moddiv4 is missing in mingw library available only w64-mingw

now i'm using MinGW bundled with Qt Creator, works fine and my previous mingw i686 DWARF
installation didn't go well with Allegro 5.2.7

this problem can be fixed if you build allegro by yourself
but doing it on windows sucks

Edgar Reynaldo

I put together a compile guide for A5 on Windows with MinGW-W64. Read it here :

The link is in my sig too.

Thread #618381. Printed from