I'm pleased to present yet another release of the WIP branch of Allegro. As always, this was a mix of new features and bug fixes.

Download the souces here.

Download the windows binaries here as well as the MSVC dependencies here.

The format of the MSVC binaries changed a little bit. The static release version is now compiled with the static MSVC runtime. The static debug version, on the other hand, is removed altogether as it is not clear what runtime is best to compile it with. As the staticness matters most for releasing software, I don't think it will be a big issue to link to the dynamic version of Allegro when you want to debug it.

The Ubuntu PPA has been updated, and the OSX homebrew will be updated in a few days.

Changes from 5.1.10 to 5.1.11 (June 2015)

The main developers this time were: SiegeLord, Trent Gamblin.

Input

• Rename al_get_haptic_active to al_is_haptic_active for consistency.

  
  

• Rename al_get_num_haptic_effects to al_get_max_haptic_effects.

  
  

• Implement the missing al_is_touch_input_haptic function.

  
  

• Move the loops parameter of al_upload_and_play_haptic_effect after the id to be consistent with al_play_haptic_effect.

OSX port

• Fix mouse warping in OSX.

  
  

• Add retina display support to OSX.

Windows port

• Fix querying display modes before creating a display.

  
  

• Make the Windows joystick implementation more fault tolerant.

  
  

• Initialize display callbacks when creating faux fullscreen (Edgar Reynaldo).

Build system

• Fix the conditional compilation of sal.h (Edgar Reynaldo).

  
  

• Don't look at WinSDK when we're not on MSVC, fixing MinGW builds when MSVC is installed as well.

  
  

• Fix the static FLAC compile tests on Android and Windows.

  
  

• Make the OSX frameworks install in the proper location again.

  
  

• Add WANT_STATIC_RUNTIME CMake build option (currently MSVC-only).

Documentation

• Various documentation improvements.

Other

• Return a valid configuration from al_get_system_config before Allegro is installed. This allows you to override the various configuration options without using an on-disk allegro5.cfg.

  
  

• Compile in the logging support in release modes by default. Now logging can be turned on in release builds without recompiling the program by editing the system configuration.

  
  

• Detect file-overruns when saving configuration files (Bruce Pascoe).

Color addon

• When converting from YUV to RGB, clamp the returned values between 0 and 1.

Video addon

• Use an enum in place of magic numbers for al_get_video_position constants.

EDIT: The MSVC binaries were updated to fix the dynamic loading acodec bug, so the hashes for those two files changes

SHA256SUMS

5928cfec00dd7f3b7043d6b7254cdfe27deba0f428c4ea842f2da9357747e854  allegro-5.1.11.7z
7a071635e39105ce52cd82c8641a8f3841efbdfe8fdb39f7a5ae1be6db3be07f  allegro-5.1.11.tar.gz
a14c5fe2c7c0cf945484b998defde5815a12c377c921030236fc08d3dd878616  allegro-5.1.11.zip
64323639cc35e4ca65e3cff997d1ee01975350f170f7c3cb6f00c9da877cad51  allegro_deps-msvc2013-x64-1.1.0.zip
ccab3959b3e98a6813404ddcdbdded5fa268e94d44963ecf94b6bc169a337d6a  allegro_deps-msvc2013-x86-1.1.0.zip
81ae5d6b64e51d75bc726ec4cd75351225bdb2eed5e45d5fb696cd3bfc23c3b0  allegro-msvc2013-x64-5.1.11.zip
58c31463390e1621792e8f61f6790b94aabb6a0cb7569db26c69ff923c5a88fb  allegro-msvc2013-x86-5.1.11.zip
72f880dbb9f9f272f3145629636e7bedb6c76640cf20abfdc7a96f782231d877  mingw-w64-i686-allegro-5.1.11-1-any.pkg.tar.xz
c0cf85b60fd40d50349f9623dbeb49e95cc69eb4288a223940277374216f3dd5  mingw-w64-x86_64-allegro-5.1.11-1-any.pkg.tar.xz

Yes, they use the XP toolchain.

Oh, noice!

NNOOOIICE!

Thanks SiegeLord and Edgar, i will give it a try. Nooice.

That doesn't necessarily mean the build is broken. Did you call al_init_acodec_addon()? Did you check the cwd? Did you use the same program code run from the same location with the same directory structure as when you built your own version of allegro? It could be a lot of different things causing it to return NULL.

Edit
Also, you can try stepping through al_load_audio_stream with a debugger, and see why it is returning null. It could be as simple as not having the vorbis dll where it belongs. You can also check allegro.log in a debugging build, or you can enable the log in release mode now thanks to SiegeLord (don't know how though, sorry).

Like I said, you may have a problem with a dll. You could still be using the old version of the dll, which would probably screw things up. But that's just an educated guess I guess. :/

The situation is under control. Stand by for the fixed binaries .

For logging, incidentally, you can do:

al_set_config_value(al_get_system_config(), "trace", "level", "debug")

before al_init().

I keep forgetting about the acodec addon's "feature" of dynamic loading of the dependecies. By default, it doesn't link to any library but will instead try to open the DLL next to the executable (and a few other spots). In your case, it didn't find the OGG DLLs and refused to load OGGs as a result.

It is more annoying than anything, but it does save you from distributing FLAC.dll if you're not using any FLAC files. What I'm doing now is simply recompiling the Allegro binaries with that feature disabled.

I'm not SiegeLord, but nonetheless: The option is WANT_ACODEC_DYNAMIC_LOAD.

I tried this out using my current game "Deluxe Pacman 2" I am working on, which compiles fine with MinGW 4.7.0 & an older Allegro 5 version.

I downloaded the MinGW and binaries for Allegro you supplied and compiled it all with Code::Blocks and the compiler you supplied. I use the switch -std=c11 to compile (C 2011 project). It seems to compile okay except I get the following errors...

||=== Clean: Debug in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
||=== Build: Debug in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
c:\mingw\include\io.h|301|error: unknown type name 'off64_t'|
c:\mingw\include\io.h|301|error: unknown type name 'off64_t'|
c:\mingw\include\io.h|302|error: unknown type name 'off64_t'|
c:\mingw\include\io.h|302|error: unknown type name 'off64_t'|
c:\mingw\include\allegro5\file.h|34|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|75|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|101|error: unknown type name 'off_t'|
||=== Build failed: 7 error(s), 0 warning(s) (0 minute(s), 1 second(s)) ===|

Again, I am ONLY using the compiler + Allegro binaries you linked to here. This seems relatively minor but it would be nice if I could get it running, thanks.

Edit: Someone on other forums suggested adding "-Doff64_t=_off64_t" to the compiler flags. I tried this and it widdled the errors down to just 3...

||=== Build: Debug in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
c:\mingw\include\allegro5\file.h|34|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|75|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|101|error: unknown type name 'off_t'|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Thanks. Upon further investigation into my problem, it appears that there is a bug in the current MinGW so that if I compile as a C program with -std=c11 I get that error (also occurs with specifying certain C++ standards). So I switch to C++ compiling and now my game goes from running to freezing up during loading.

I hate having to compile it with regular C++, I feel all dirty (I prefer C).

(sigh)

I guess there was a patch someone issued for this problem (in io.h), you can read about the problem here: http://sourceforge.net/p/mingw/bugs/2104/, which I tried out, but still there are errors...

||=== Build: Debug in Deluxe Pacman 2 (compiler: GNU GCC Compiler) ===|
c:\mingw\include\allegro5\file.h|34|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|75|error: expected specifier-qualifier-list before 'off_t'|
c:\mingw\include\allegro5\fshook.h|101|error: unknown type name 'off_t'|
||=== Build failed: 3 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

I did manage to find some minor problems (unrelated to this) with my own code, so something positive came out of it, but still. I would love to be able to use a newer version of the library with my C code.

What if you try gnu11 rather than c11?