It has been 14 years since Allegro 5 was first announced and nearly 5 years and 2 months since version 5.0 was released. After many years of development in the unstable branch, I am excited to announce that a new stable version of Allegro is ready for release!

Allegro 5.2 brings forth many features from the 5.1 branch and exposes them with a stable interface with guaranteed source and binary compatibility. This includes things like shader support, limited support for 3D game development, video playback, Android and (functioning) iOS support. Some features, however, are not quite ready for prime time and therefore remain unstable. To avoid the codebase divergence that prevented 5.0 from receiving many bugfixes from the 5.1 branch, these unstable features coexist in the same branch, but must be opted into before being used.

This release would not have been possible without the help of the many people who have contributed to Allegro over the years. In addition to the 'core' developers that have been around since time immemorial, many of the most exciting features of Allegro have been contributed by people who started using Allegro relatively recently. Even without making code contributions, simple users of Allegro who made suggestions, bug reports and simply used the code have also been invaluable to making Allegro as high quality as it is today.

In many ways, the game development community have abandoned native libraries like Allegro. Despite this downturn, many still create great games with Allegro as foundation, and I think Allegro still has a niche to fill. Allegro 5.2 is an important milestone, but it is not the end of the road. There are still many bugs to fix, features to add and games to write.

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.

On a technical note, Allegro 5.2 is source but not binary compatible with Allegro 5.0. Additionally, the semantics of some functions have changed, but hopefully not in a way that affects most programs.

Changes from 5.1.13.1 to 5.2.0 (April 2016)

The main developers this time were: SiegeLord, Polybios, Mark Oates, Elias Pschernig and Jonathan Seeley.

Core

• Add al_is_event_source_registered (koro).

  
  

• Make destructors log messages more meaningful.

  
  

• Mouse emulation API for touch devices is now unstable.

  
  

• Rename al_convert_bitmaps to al_convert_memory_bitmaps.

Input

• Haptic API is now unstable.

Android port

• Fixed bogus display destruction on Android which previously caused zombie states.

OSX port

• Fix OSX mouse state position scaling.

  
  

• Fix other various scaling issues.

  
  

• Make toggling ALLEGRO_FRAMELESS work.

  
  

• Fix an issue where fullscreen windows would occasionally leave empty space for the titlebar.

  
  

• Fix incorrect debug assert in the audio addon.

Windows port

• Make Allegro apps DPI-aware by default, which means that they won't be scaled by the OS.

  
  

• Fix compilation for the CPU detection code on some compilers.

  
  

• Don't sync the D3D bitmap when locking with WRITE_ONLY.

  
  

• Remove dsound.dll runtime loading.

  
  

• Don't link xinput and d3dx9 libraries (they are still required at runtime though if you're using the relevant features).

  
  

• Fix a bug where al_wait_for_event_timed can block despite 0 timeout (Aldo Nunez).

Build system

• Install PDB files when building with MSVC.

Documentation

• Fix source links for API entries with multi-line prototypes.

  
  

• Make the readme look prettier on GitHub.

  
  

• Tons of assorted documentation improvements, especially for the audio addon.

Other

• Add a stability system where some unstable APIs need to be opted into by defining ALLEGRO_UNSTABLE before including Allegro headers.

Audio addon

• Fix sporadic deadlocks

  
  

• Recorder API is now unstable.

Native dialog addon

• `al_toggle_menu_item_flags` is now unstable.

TTF addon

• Add an option to pre-cache the glyphs, useful for platforms where the current algorithm is buggy (typically some Android devices).

Video addon

• Temporarily remove FFmpeg backend, as it was too buggy, didn't build and was too hard to fix.

Examples

• Make ex_vsync less likely cause a seizure.

  
  

• Make ex_draw_bitmap and ex_touch_input switch in/out on Android.

  
  

• Add documentation to ex_bitmap (Daniel Johnson).

  
  

• Improve ex_logo text entry experience.

SHA256SUMS

dd47d4a72e8a81e947c303d6cebf5056bba1e56f77339ce5481e5d33bf0841ce  Allegro.5.2.0.0.nupkg
fc8ef6597461f11adaf43b95329ea4a825cd387659643f4046f0b2f07fcd7c53  allegro-5.2.0.7z
af5a69cd423d05189e92952633f9c0dd0ff3a061d91fbce62fb32c4bd87f9fd7  allegro-5.2.0.tar.gz
7890acb70eb05edf4ec99e9b63b60c22af7bf387e34f023207ad1c4fa56484b8  allegro-5.2.0.zip
c1e272f2e2f6be80cb567829ebaa10efec854e44a8da7d0d8b02a9143b5d2dbb  allegro-mingw-gcc5.3.0-x64-5.2.0.zip
aee66be54bec6dca60ae6f6f892a447aae2d17e29b29d110bb29fee73947830c  allegro-mingw-gcc5.3.0-x86-5.2.0.zip

As always well done everyone, and many thanks.

Excellent!

"Unstable API" means: It's there, but still under development, i.e. the API is not guaranteed to be around in the next version. It could change or be removed completely.

As to the 5.2 release, it means that developers didn't think those parts were "mature" enough to be introduced as something the next releases would have to be compatible to. So they were marked as "unstable". This is what "is now unstable" means.

There are short notes in the docs why the specific API is considered unstable, too. For example, about audio recording :

About haptics:

Instead of marking the whole 5.1 branch as "unstable", there is now only one branch with parts of it marked as unstable. Note it's about API.

Well, knowing Allegro 5's history, it's a good release date.

I feel like the best solution would be to step up and send them a patch. The fact that you're on 5.0.10 and not 5.0.11 means they're not quite up to date even for 5.0... Once I make the Ubuntu 5.2 packages, perhaps I could send them as is to Debian (since that's where they came from originally anyway).

We just need a hard look at it and see what's up with it. It might be fine as is. Did you have any issues with it (aside from that sample length issue; did you resolve it?)?

Whoops... that's bad.

I thought you were playing games with my heart, when I looked at the date. Awesome!

That would be AMAZING to get an up-to-date Allegro stable release through package managers.

Tested on WinXP. Even my old notebook is able to run it nicely.

I found some odd keyboard behavior in Allegro 5.1.13 on Windows 10. If someone with 5.2.0 installed could test some code for me I would appreciate it. The thread with the code is here :
https://www.allegro.cc/forums/thread/616179

Because of the new mind control ability of 5.2

EDIT: building it on my Win7x64 installation. I'll report the state of audio recorder fragments and may test for Edgar's problem.

Google has done some amazing work. They actually send differential updates that are tiny compared to the full thing. Like hundreds of kbytes and sometimes less. They actually have it aware of code building process and the resulting binary code sections and compress them separately. I don't recall the specifics but it was something crazy.

I missed a word in that last post. It's for Google Chrome:

https://www.chromium.org/developers/design-documents/software-updates-courgette

Check out article. They do all kinds of crazy pre-linking hinting tricks.

Looks like it could be applied to anything else though!