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

Just to verify, the MSVC binaries are compiled using the "XP" toolchain, yes? I ask because otherwise they won't work on anything lower than Win7--something I learned the hard way.

Yes, they use the XP toolchain.

I have put together binaries for 5.1.11 for MinGW 4.8.1 if anyone is interested.

My distribution includes statically linked examples and demos, as well as all of allegro and its dependency's libraries, headers and dlls. Static and dynamic, and debug and release monoliths are included.

You can get them from SF here :

http://sourceforge.net/projects/unofficialallegro5distribution/files/A5111distroForMinGW4-8-1.tar.7z/download

And I provide binaries for MinGW 4.8.1 to go along with them, which you can find here :

http://sourceforge.net/projects/unofficialmingw/files/mingw_4_8_1-4.tar.7z/download

You'll need 7-zip to extract them.

Simply extract twice for each archive. Rename the directories if you like, add the mingw directory to your %PATH%, set your linker and include directories, set your target link libraries, and away you go.

And now there's no reason left not to sign up for SpeedHack 2015. MinGW and A5 are neatly packaged up and ready to go, and so you should be too.

Oh, noice!

NNOOOIICE!

Thank SiegeLord for getting this release ready in time for SpeedHack. Now that's Noiice!!!1111

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

I tried the binaries, and for some reason Vorbis doesn't work (al_load_audio_stream() returns NULL), with either 32 or 64-bit builds. Not sure if anything else is broken. Self-built 5.1.11 binaries work fine.

As a minor nitpick, is there any reason these depend on libpng and jpeglib? I use native image loading (GDIplus) for my own Windows builds. That's neither here nor there though--I'm more concerned about the Vorbis issue.

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

This was swapping out the 5.1.10 self-built binaries and includes I was using (which worked) with the pre-built 5.1.11 ones in the same app, so yes, al_init_acodec_addon() was called.

I'll try using a debug build and see what's up.

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. :/

Actually I'm using the static libs. I even double-checked that I used the right dependencies (the ones linked in the OP).

What's interesting is that it works when I link against a dynamic build (including the provided debug build), only the static build fails.

So it looks like I'll have to figure out how to enable logging on the static build.

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

So it was broken then? Good to know, that saves me some time diagnosing it. Out of curiosity, what was wrong?

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.

Aha! So it was a dll problem. My spidey sense still works!

Coincidentally, the binaries I made don't seem to suffer from the same problem. "ex_stream_file.exe game_music.ogg" works ok on my end with statically built examples.

SiegeLord, out of curiosity, what option enables/disables the dynamic loading of dlls for the acodec addon?

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

What!

I've updated the binaries, hopefully now they're all set.

For GDI+, incidentally, I think the reason I prefer libpng and libjpeg is because it leads to a bit more consistency between platforms... I think we did have some issues with GDI+, but honestly I can't remember them. I'll have to explore this question next time around.

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

Neil Roy!! Good to see you, old chap!

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 prefer C too. C++ to me is the poster child for design-by-committee, like if you asked a Family Feud survey panel what they would like to have added to C and then implemented every single idea.

But I digress.

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.

@Neil Roy
According to http://sourceforge.net/p/mingw/bugs/2046/ , off_t (from unistd.h) is not conformant to at least C99, and in your case, C11 as well. It looks like you might be able to fix it by including "sys/types.h" before including allegro headers. That, or #define it yourself, as a long, which is what mingw appears to be using.

What if you try gnu11 rather than c11?

Thank you very much! This did the trick. Compiled flawlessly after that.

Incidentally, including "sys/types.h", didn't make a difference.

Edit: I have a new problem though! My game refuses to load in a sound sample which it has always been able to load, it fails to load it then freezes up.

When I look at the allegro.log file it was 153061 lines long!!! That's insane! My game didn't even make it all the way through the initialization! It barely loaded anything. There's definitely some bugs with this release. I would attach the allegro.log but it is over 22megs big! :O (note: I had deleted the allegro.log file before running this so this was a freshly made log)

Edit2: I recompiled with MinGW 4.7.0 + Allegro 5.1.8 (though the version displayed in my console says 5.1.9) and it runs flawlessly. Log file is only 10K lines rather than 156K (and that was with a full load and run and exit). So... dunno.

That's because if _STRICT_ANSI_ is defined (which it probably is for C11) then off_t isn't defined. I didn't look closely enough. I just grepped for off_t in the include directory. :/

Gosh Neil, these releases just have trouble with your game. Is there any way you could share your code, perhaps privately? I'm sure I can solve the problem with a bit of effort. As for the log, I'm sure you can zip it up and it'll be a lot smaller. After all, it's all text anyway.

<scratch all that> Going to look at this one more time.

Okay, several issues. I am missing several DLLs, even though I compiled this with the static version of the library. Some I have, some I do not, but requiring a DLL sort of nullifies the whole idea of a static build. So far it has required libvorbisfile-3.dll, libvorbis-0.dll, which I had, it also requires libogg-0.dll which I do not have.

I compile the debug version with the library: allegro_monolith-debug-static

So I definitely am using the right one, and all my code is set to static, always has been, works with past versions of Allegro 5 static builds (all premade builds by the way, like this, not my own versions).

The game fails to load as a result, and then when it goes to exit and shut down the screen, it goes into an endless loop for the following code:

EDIT: Okay, I solved the freezing problem. I had the code to shut down the display before the code which frees up the fonts I loaded. I am not sure why that could cause a problem now and not before, but I moved my code to shut down the screen to the end of my function and it no longer freezes up, so I needed to destroys bitmaps before I destroy the screen I guess.

Still need those DLL requests gone as this IS static. Perhaps I will try compiling a non-static version tomorrow as it is now past 4am... argh. I would like it if there was an up to date release version so I could compile without the allegro.log appearing.

You're using the binaries and compiler I provided, right? I know about 2 dll dependencies, libstdc++-6.dll and libgcc_s_dw2-1.dll. That is because of the way CMake built them. The option to link statically to the CRT is not available yet. SiegeLord recently added an option to the cmake build system to do this, but it doesn't work for MinGW yet. So those two dlls still have to be packaged, even with a static build. Sorry about that.

Now, you said your static build relies on vorbis and ogg dlls? It definitely shouldn't. The examples and demos I built alongside the static libraries all work and they only rely on the two CRT dlls I mentioned above and OpenAL32.dll. I don't have a static version of OpenAL built yet, because the cmake build script they provide does not have a static version.

libogg-0.dll is provided in bin\dlls btw, along with the rest of the dlls.

Sounds like you got bit by the dynamic-load issue for allegro_acodec. By default it tries to dynamically load codecs for its supported formats, you have to clear a flag in CMake (WANT_ACODEC_DYNAMIC_LOAD I think) to disable that.

I think for the future that option should be disabled for static builds. Something to consider.

You can get a fully static build, I have a working one for minisphere (5.1.11 even), the entire game engine is self-contained in a single 2.2mb executable with no dependencies.

Yeah, this was compiled 100% ONLY with what you provided. I have the MinGW you provided in it's own folder along with the Allegro you provided in the same folder. There was no libogg-0.dll in there though... <double checks> I see why I couldn't find it last night. There is a dll folder in your main MinGW folder as well as one inside the bin folder Let me try this again.

I can live with needing dlls though, no big deal, but if some are required it should be mentioned somewhere so people aren't surprised (in that text file about static linking perhaps, for now anyhow).

<time passes>

Okay, I ran it again, this time with libogg-0.dll, libvorbis-0.dll and libvorbisfile-3.dll in the same folder and it ran without problems. I didn't recompile it to use dlls, just included those for now.

Like I said, if you're building your own statics you have to re-run CMake with the WANT_ACODEC_DYNAMIC_LOAD option cleared. Then you'll get a proper static link of all dependencies.

I rebuilt the two static libraries with that option disabled. Here they are :

https://www.allegro.cc/files/attachment/609500

I'll update the SF download later today.

Yay! That worked, many thanks for your work on this.

Edit: New version up, compiled with this, complete with proper installation program (Windows) etc... if you're curious. The game is fully functional, just needs a few things added (multiplayer option etc). Compiled with Code::Blocks, and the MinGW + Allegro supplied in this thread.

http://home.cogeco.ca/%7Edeluxe.pacman/zips/DPacman2_2015JUN26.zip

Glad it all works now. Just to be clear, did you compile with the official static binaries and observed that they required the ogg etc DLLs? I thought I fixed that... .

Yup, I did. No more DLLs needed. I don't keep my DLLs in my system path anywhere just so I can know what is and is not needed.

The ZIP I linked to is what I compiled with no DLLs and works as is. I got more work done on it today, so far I am quite pleased with this version. I may actually get my game done (actually, I got it done today, just bug testing it now).

I have a problem with ex_dualies.
When I run it the resolution changes to 640x480 on both my monitors, but don't came back to the original aspect when I quit.
Edit: ex_win_full does the same but only on my main monitor.

Edit: ex_vertex_buffer textprintf output seems messed up
{"name":"609573","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/d\/3dafb0dcbf63884187fb78f55f8434c2.jpg","w":647,"h":510,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/d\/3dafb0dcbf63884187fb78f55f8434c2"}

Can you point out what's wrong? It seems okay to me.

What's wrong is the display format of the fps.
EDIT: but maybe users are used to see fps in e mode.

Haha, scientific notation for fps. That's new.

Ah... that was just me wanting FPS with only two significant digits, but being too lazy to write a routine to do that rounding myself.

Somehow scientific notation makes that FPS look so much better!

I feel like I have a high end computer looking at these numbers. But I have not !

Hey guys I followed the link, but my download wasn't the version 5.1.11 but the version 5.0.11. Is it stable?

I never noticed this until today, because MinGW's bin folder was in my path (it no longer is). But when compiling my game, it now says "libgcc_s_dw2-1.dll is missing", but I statically link it with my game, always have (with "-static" in my linking options, which has always worked with past Allegro libraries, but now this one). All I can assume is that Allegro 5.1.11 has not been statically linked with libgcc_s_dw2-1.dll?

I'm starting to require the inclusion of more and more dlls with this build. I can include this dll if need be, but the static version of this library is definitely broken.

Neil
I told you before, that my build of A5.1.11 depends on OpenAL and the CRT dlls. If you need to know which dlls a program is dependent on, use Dependency Walker. It's because the option to build the allegro dll with a static crt isn't available yet through cmake, so even the static versions depend on OpenAL and libgcc_sw2 and libstdc++.

In order to get rid of the mingw dlls, you have to compile/link everything with `-static -static-libgcc -static-libstdc++`

Right, but Allegro's cmake doesn't support that yet. :/

Not that hard to add it

Actually, cmake does support it, at least when you use cmake-gui... it allows you to edit the used CFLAGS. My speedhack entry I compiled with -static-libgcc -static-libstdc++ which is enough to not depend on any DLLs at all (I didn't need the -static - but I also don't know what it would do).

You can modify the cflags through the cli and tui interfaces as well.

Well that takes care of the CRT and Allegro, but I still can't build OpenAL statically with cmake.

Yes, as for openal, just disable it... I don't think anyone created binaries with openal enabled - we mainly have it for osx support only.

Not a big deal for me. It would be nice to have no DLLs needed, but including them wasn't too big a deal. I appreciate your efforts as is a lot.

I've adjusted my binary package to use debugging examples and to use statically linked monoliths that don't depend on the CRT or OpenAL anymore, so theoretically no dlls should be needed anymore.

Get the libs here :
static_libs.7z

and you'll have to wait for the debugging examples, since SF won't let me upload anything at the moment...

SF is borked

SF pukes.