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.

Core

• 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.

Documentation

• Various documentation updates (Daniel Johnson and others).

Other

• 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

• Adjust loop end position when calling al_set_sample_instance_length.

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.

Examples

• Add more controls to ex_audio_props.

  
  

• Add an example of using Enet with Allegro.

SHA256SUMS

34acb0346780b9d262c7e459701646a6046bec88db6056e17244c558fa1adfcc  Allegro.5.2.1.0.nupkg
d229402acca828882baa48e77a5ae3405d2d53565db4b2c834b3a7db1da66323  allegro-5.2.1.7z
9e88cda6bbe2b56fb47fe253f9b22868c821e78a19004b5742a90f66ac4fe927  allegro-5.2.1.tar.gz
124bb7892e37c8fe10c903264480ac1bc50771a8fdeefc030811eaedc4fbb0ec  allegro-5.2.1.zip
c9f6104a7125c76c78c1ec049a774402b003ac91ac2049f8906200333f09a1bf  allegro-mingw-gcc5.3.0-x64-5.2.1.zip
d94446f458bf0cde3d2fdec3e0057b13001bf30a24415e5fe5916eb8ec6c947f  allegro-mingw-gcc5.3.0-x86-5.2.1.zip
6bf48e4d4c7922f70a4d34bb5216ee169b6c415b5a77e18b868628108aa6aa90  allegro-mingw-gcc5.3.0-x64-dynamic-5.2.1.zip
f1da3d793481f08e89b392c3b4fe0ae612ae7ec31087f843f7e8ef7b5937b289  allegro-mingw-gcc5.3.0-x64-static-5.2.1.zip
319743507b87772632122ffceff1dc79eea53df7a1fe48ab2840042831591594  allegro-mingw-gcc5.3.0-x86-dynamic-5.2.1.zip
0179b124e796f015a4b9c74da73bf5941350306805b804faec37fe43b173fe1a  allegro-mingw-gcc5.3.0-x86-static-5.2.1.zip

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)

Awesome. Great work guys.

Will be working on putting together a binary distribution of MinGW 5.3.0.2 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 http://download.gna.org/allegro/allegro-bin/5.2.1/allegro-mingw-gcc5.3.0-x64-5.2.1.zip, 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:

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?

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.

YAAAAAAAAAAAA!

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 ).

Awesome