On the 11th day of this new year, let us enjoy the release of Allegro 5.0.11! For those for whom it is the 12th already, you can enjoy the 12th release of the 5.0 branch (which is 5.0.11 ).

This is a pretty boring release, except for those people for whom Allegro actually stops crashing as a result of the bugs fixed in this release. Aside from the most serious bug fixes that were merged from the unstable branch, this release comes with fancier documentation (syntax highlighting!) that has been in the unstable branch for awhile now, but hasn't graced 5.0 yet. Also, for whatever reason we never distributed the PDF manual, so here it is!. If all goes well, this should be the last 5.0.x release.

Get the sources here: https://sourceforge.net/projects/alleg/files/allegro/5.0.11/

Changes from 5.0.10 to 5.0.11 (January 2015)

The main developers this time were: SiegeLord and Peter Wang.

Core

• Fix OSX backend on OSX 10.10 (lordnoriyuki).

Audio addon

• Fix/avoid all sound examples freezing on OSX with the aqueue driver (Elias Pschernig).

  
  

• Fix a deadlock in Pulseaudio driver.

Other

• Fix build warnings.

  
  

• Improve documentation (syntax highlighting).

MD5SUMS:
b089bc78588188f7730425e252794aa8  allegro-5.0.11.7z
e9a02220fada0488ed1dec6d5a8f6d33  allegro-5.0.11.tar.gz
b859278f7984111b18f2305388593f3d  allegro-5.0.11.zip

Thanks! I guess this is nice for those who still use the 5.0.X branch.

I think if you get Allegro from your distro's package manager (apt et al) it's likely to be 5.0.x still, so hopefully the packagers will pick up on this one.
Pete

ps: SL - it's year (201)5, month 0, day 11 = 5.0.11 - surely the omens are good for this one...

Flagged the allegro package for Arch.

This gave me goosebumps.

I updated Homebrew, so the platform that benefits the most from this release is good now.

Thank you.

Thanks for doing this!
(yes, I still use 5.0.x)

Any chance the window flickering problem and not working multisampling on some ATI/AMD cards is fixed?

What bug?

That's actually 3'rd on my list of Allegro TODO things to look into!

Check it out:

~~~~ DOCS ~~~~

Document defaults for options
unreliable mode_info (not sure anymore... maybe it correctly returns NULL when it fails)

~~~~ WIN ~~~~

vertex_buffers not working?
display settings not setting correctly with D3D (a test case in C:/dev)
flickering multisampling https://www.allegro.cc/forums/thread/613548
D3D viewport vs OGL viewport - this will fall out of the projection revamp
Drawing mem bitmaps to display (D3D, ANY_WITH_ALPHA)

~~~~ OTHER ~~~~

core OpenGL context
generate allegro5.cfg programmatically
wrapping bitmaps (related to bitmap options)
set array of bitmaps for shaders
Mouse pressure is basically unimplemented
ogl_unlock_region_nonbb_fbo_writeonly shouldn't need _al_convert_data
al_calculate* functions should probably take void* instead of float*
native dialog windows buttons http://alax.info/blog/127
al_play_sample/stop_sample not thread safe -> TLS the whole thing
https://www.allegro.cc/forums/last-read/614489
al_get_audio_stream_length_secs - Should take const
https://gist.github.com/SiegeLord/6f482916dd4e0791d4f7 - Wow (probably a catalyst bug)
Collinear holes primitives http://p.baf.cc/4155 - damn lost it, ask jesseg2
Deadlock of al_install_audio on Travis
https://www.allegro.cc/forums/thread/614182
Look through old patches
CPU usage with the voice/attach to voice - seems to be just the voice running, but having trouble stopping the mixer to recover the speed...
initialization should produce an error or something, esp in debug builds
Awesome single flip not enough awesome 3.5.2
set new window title
enums used for function args (e.g. audio addon)
unify some options for bitmaps and displays (depth buffer size, multi sampling)

What was the reasoning for pushing releases more frequently?

What gives you the idea that they are more frequent?

Oho I see I am listed as owning bug#351. When did that happen? I hope the OP isn't too mad at me!
pete

SiegeLord: Yep, that the one: https://www.allegro.cc/forums/thread/613548

I have 2 computers with ATI/AMD and it gives me kinda epileptic effect on both. I have also one nVidia card. The problem is there as well, but the flickering is so fast, its almost not noticable. When I turn off multisampling, the problem is gone.

Forgive me if I sound insincere, but what's the advantage of having the non-WIP branch? Doesn't it normally have many bugs the WIP already solved, but people are supposed to use it because... it has less bugs than a WIP version?

That ambiguity has snagged me before. With Allegro, the WIP is already best from what I remember, but say, VLC, when I tried the dev branches and they crash the second they try to load a file on my computer.

The non wip branch gets bug fixes backported. The wip branch can have new bugs introduced quite often.

That said, allegro tends not to have too many nasty bugs introduced in the wip branch. Really, the WIP branch is a place where new things can be introduced, and then be broken, before stability is guaranteed. There's a reason it isn't called the unstable branch. It isn't crashy unstable, so much as work in progress.

Actually it is exactly referenced as "unstable" in many places and that's why someone thinks it's better not to use it....while WIP it's a much better way to describe it I suppose.

Yeah, it was originally WIP, and somehow "unstable" snuck in.

Too bad...thou this discussion as already been (over)done, it would help to clean up the table there.

Personally I'm in favor of jumping to allegro 6 and then making the WIP branch the only maintained one. We're already short on hands to develop the WIP branch,maintaing a "stable" branch is a lot of work that causes confusion for the Linux distro maintainers. But anyway, let's wait and see.

Allegro 6? We just got done coming out with Allegro 5 in the last few years. There's no API change that justifies bumping the major version up again. Further, the WIP version is not a substitute for the 'stable' version. The WIP version is subject to API and ABI changes where the stable version is not. Calling it Allegro 6 would be utterly confusing to the point where no one would use allegro anymore. It's bad enough people still think allegro 5 has the same api as allegro 4.

By whom? Can you provide a link?

Then there would never be a stable api to base your programs on. why would anyone decide to use allegro? the whole point of the stable branch is that it can be depended upon.

If distros get confused over wip branches, they are dumb.

It's been talked about, but not super recently.

Personally, I do want to drop the stable branch and have only the 'unstable' branch. I think the way Allegro does it is atypical, and only results in a buggy stable branch without really any benefit over a more fine-grained API stability approach.

In my vision, this would involve tagging individual API entries with their stability, and then having the user opt-in into the unstable API. If they don't, then there'd be some sort of guarantee that things would keep compiling. I'm still working out the ABI details of that, if that's even possible. If you know any projects that do it this way, please tell me as I'd like to take a look.

Opting in would look something like this:

#define ALLEGRO_UNSTABLE
#include <allegro5/allegro.h>

I agree with SiegeLord here, although we have to investigate how to keep a stable API and add WIP ones at the same time in one branch. If 6.0 is too radical let's just jump to 5.2. A rose by any name...

#define ALLEGRO_UNSTABLE
#include <allegro5/allegro.h>

This is a really, really good idea.

When you think about it, the implementation is the same as DEPRECATED warnings.

#define ALLEGRO_UNSTABLE
#include <allegro5/allegro.h>

Hmm, I don't know if I agree. Wouldn't that mean that the allegro source would be littered with a bunch of #ifdefs around every single difference between the stable and 'unstable' branches? It sounds like it would lead to a maintenance and compilation nightmare to me.

I do want a ALLEGRO_NO_DEPRECATED as well .

This'd just affect the headers. I'm thinking ALLEGRO_FUNC and ALLEGRO_UNSTABLE_FUNC. Either way, there wouldn't be a 'no unstable features' CMake option or anything.

How do you expect to handle ABI compatibility? Especially when "unstable" things are removed or renamed?

Don't know yet... maybe all of this is impossible .

I thought it'd might be possible to somehow split the unstable features into a separate optional library... Not sure if that is possible if they share the same source file. Maybe some clever linker scripts?

For C a stable ABI can be achieved by not changing the parameters to functions and only adding new members to structs, not removing or reordering them. That means once a function is declared to be a stable API, it can't change it's parameters anymore nor may it be removed. But with some #define preprocessor tricks this can be remedied easily enough.

It would very well be possible to do this with what SiegeLord proposes.

I'm not a dev, so maybe you're talking about internally. But if you mean externally, I see no reason people should expect an "unstable" function never to change. The same way between the existing two branches.

[edit]

But it looks like you're talking about internals. What's the problem this introduces? If you've got, say, a DLL, and you add a new function, do all the other functions get moved around and broken? Surely dynamic libraries work on a function name level and not a byte offset?

I guess in the case of a compiled program, but the DLL ABI changes, "function name exists but was changed" or "you are calling a depreciated unstable function". But couldn't we introduce some boilerplate for those rare cases, where we have a list of functions that immediately flag a critical-level allegro error that says, "This program is calling a depreciated function. There has likely been a DLL version mismatch."

Additionally, since we'd be forcing people to use ALLEGRO_UNSTABLE, it's the developer's fault if they make the assumption that functions will never change and doesn't statically link, or provide updates.

[edit]

Doing some reading. This seems like a fairly good attempt at C++ ABI, if you're wanting something to read for fun.

Basically, they use extern "abi" {}, and the OS (not the compiler) defines how that section must be implemented. And to deal with std::library issues (std::vector is a huge issue that can't even be used in public library functions), they introduce std::abi::library functions which are binary stable.

I was talking more about the dll's or so's themselves. But it doesn't seem to be a problem. At most we'll have to worry about public types that are allocated statically (ie: ALLEGRO_COLOR, but why would that change all that often?)

@Chris Katco:

That's an unimplemented proposal for C++ which is a huge mess when it comes to a stable ABI due to naùe mangling. Name mangling of C++ is the reason why there is ,no stable ABI and slower dll loading with c++. Plain C doesn't have any of those problems to keep the ABI stable when you stick to a few basic rules. Another reason why plain C is better.

Yes, yes. But a man can dream, can't he?

So I checked Linux GCC, Windows GCC (via MinGW) and MSVC, and they all support the general ABI idea I was going for. Basically, if your program doesn't use a function from a shared library, then the next version of the library can safely remove that function without breaking ABI compatibility. So if you compile your code without ALLEGRO_UNSTABLE in e.g. 5.2.0, then your code will continue to work with DLLs produced for any later 5.2.x version. If you do use ALLEGRO_UNSTABLE, then your program is only guaranteed to work with the very same version your compiled for (i.e. 5.2.0 in this example).

This is the same ABI guarantee we currently provide with the current dual branch arrangement. Code compiled with 5.0.x works with shared libraries with version 5.0.y where y >= x. Code compiled with 5.1.x works only with shared libraries with the same version.

It occurs to me that we could actually provide an option to build Allegro without any visible unstable entries, for things like Debian which might not like these unstable ABI breakages.

A cursory search reveals that gstreamer has done this for years.

Hah, great. Although I still prefer my opt-in approach more than silencing a warning. I get the impression many people routinely turn a blind eye to warnings .

Yeah, I get that impression, too. Besides, opting-in feels more appropriate.

Re #allegro: Apparently, __declspec(deprecated) is the deprecated macro for MSVC. I don't have MSVC, so I can't test it.

Edit: Hehe, I think you may have already found the Stack Overflow post...