Changes from 5.0.10 to 5.0.11 (January 2015)

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

Flagged the allegro package for Arch.

This gave me goosebumps.

Thank you.

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

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 gives you the idea that they are more frequent?

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.

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.

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

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.

By whom? Can you provide a link?

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>