Allegro 5.0.9 released!
Peter Wang


Changes from 5.0.8 to 5.0.9 (February 2013)

The main developers this time were: Trent Gamblin, Elias Pschernig,
Peter Wang.


- Clean up logging subsystem at shutdown (muhkuh).

- Fix a problem with creating a display after Allegro is shut down
then re-initialised on X11.

- Fix use of clobbered return value from setlocale() on X11.

- Fix use of double math functions for float arguments (Nick Trout).


- Fix al_set/get_window position on Windows so getting/setting to the
same position continuosly doesn't move the window. (Michael Swiger)

- Add al_set_display_icons (plural). Implemented on X11 and Windows.

- Made al_get_display_mode return the closest thing to a pixel format
possible with the WGL driver (tobing).

- Move WGL context destruction out of the message pump thread and into
the user/main thread.

- Allow command-tab to work in fullscreen window mode on OS X.


- Avoid null pointer dereference when setting a target bitmap after
its video_texture has already been released (D3D).

- Make d3d_lock_region fail immediately if _al_d3d_sync_bitmap
failed, likely because the device was lost.

- Set device_lost flag immediately when d3d_display_thread_proc
finds the device is lost.

- Sync bitmaps before resizing display to prevent changes being lost
after the resize (D3D).

- Revert a faulty FBO rebinding optimisation in al_set_target_bitmap.

- Fix OpenGL extensions being completely ignored on OS X.

- Support stencil buffer on iOS.


- Partially fix mouse buttons "sticking" on Mac, e.g. holding the
mouse and toggling fullscreen window.


- Keep absolute path in ALLEGRO_FS_ENTRYs so that later changes to the
working directory do not affect the interpretation of the path.

- Set ALLEGRO_FILEMODE_HIDDEN properly on Unix.

- Make sure stat mode bits are cleared in default implementation of

- Support Unicode paths on Windows.

- Change description of al_get_fs_entry_name about not returning absolute
path if created from relative path; no longer true for either the default
or Physfs implementations.

Audio addons:

- Shut down threads properly when when destroying FLAC and modaudio streams.

- Fix PulseAudio driver trying to connect to a non-existent server forever.

Image I/O addon:

- Fixed loading interlaced .png files with libpng.

- Use Allegro built-in loaders in preference to OS X loaders for BMP/TGA/PCX.
The OS X TGA loader doesn't support alpha and this is also more consistent.

- Restored ability of the native OSX image loader to load grayscale pictures.

Native dialog addon:

- Add al_init_native_dialog_addon and al_shutdown_native_dialog_addon.

Build system:

- Rename allegro*-5.0.pc files to allegro*-5.pc. The old names are
deprecated but retained on the 5.0 branch for backwards compatibility.

- Only generate and install pkg-config files for libraries that we build.

- Install iPhone internals headers (Nick Trout).


- ex_icon2: New example.

- speed: Use builtin font.


- Documentation updates.

- A lot of code refactoring.

f7b59457388e7f57a3ec4fd4bbdbd727  allegro-
59fb41dccc300be0044cfad5fff0ca81  allegro-5.0.9.tar.gz


Thanks everyone for your hard work! I'm looking forward to using this. :)


All those header moves :'(...

Matthew Leverton

Rename allegro*-5.0.pc files to allegro*-5.pc.

What is this for? How do you use multiple versions (5.0 vs 5.1) of Allegro side-by-side?


As far as I can tell the main reason was that it wasn't sufficient for that purpose anyway since pkg-config would return just -lallegro regardless of whether you passed allegro-5.0 or allegro-5.1 (and there was no clean way to fix that). As for using them side by side... I believe you install them in different directories and then set the PKG_CONFIG_PATH and invoke pkg-config with --cflags. Never tried that approach though...

SiegeLord said:

I believe you install them in different directories and then set the PKG_CONFIG_PATH and invoke pkg-config with --cflags.

Which completely defeats the point of pkg-config.. but whatever. Only developers should care about having 5.0 and 5.1 in the same system.


Looking forward for Windows binaries... :-)


...especially the tdm-gcc-4.7.1 flavour :P :P


I've never compiled allegro with this computer, so it may be my setup.

I compiled 5.0.9 using gcc 4.6.3 on Mint Maya, and the cosmic protector demo seems to think that the up key is being pressed. I tried restarting the app, making sure that no keys were pressed, and that did not help.

I've ran many examples, and they seem fine (but none that use the up key). :-/

Is there anything you need from me to help figure this out?

Peter Wang

It's not a stray joystick, is it?

Edgar Reynaldo
vrekman64 said:

...especially the tdm-gcc-4.7.1 flavour :P :P

...which you're welcome to contribute. ;)

Hey, just wanna give a shout out to all the devs - never say how much I appreciate a fun innovative, cutting edge library like Allegro. Never ceases to amaze me how much fun I can have with this library. If only I had more time to program, and less time I had to spend on school.

Are there any areas of contribution you're looking for? What needs to be done? Is there a TODO list anywhere? I don't know how much I could get done, but maybe I could do something. :P

Trent Gamblin

It's not a stray joystick, is it?

Which includes drop and motions sensors. da** linux >:(.

Are there any areas of contribution you're looking for?

Before we release 5.2 it'd be good to have the bug list in good shape, so fixing any of them would be a big help.


So, Where Are The 5.0.9 Pre-Built Binaries? ??? ???


Does this release fix this ( issue? Because I don't see that among the changes...

//Edgar: I know I was supposed to test it myself, and you said I could do it... But I have come to the conclusion that on one hand I believe that I really could do it on the other hand making so would probably stress me to the extent that I would really have to become a sailor.

Edgar Reynaldo

So, Where Are The 5.0.9 Pre-Built Binaries? ??? ???

Jeez man, give it a few days. They'll be out as soon as the packager has time to get them out. You're welcome to build the source code yourself if you're in a big hurry. ;)

Peter Wang


- Sync bitmaps before resizing display to prevent changes being lost
after the resize (D3D).


I didn't have a joystick attached. I would research and try to fix myself, but I haz no internet juice...

I'm calling ISPs tomorrow, though. Maybe I'll be of some use around here one day... :P


Peter Wang: Thanks. I was wondering if that item is actually "it".

Michał Cichoń

Thanks a lot.

Matthew Leverton

Do these Windows binaries require Vista?


Do these Windows binaries require Vista?

I suppose it depends on the runtime. Starting with MSVC 11.0 (Visual Studio 2012) - you need Vista+.


Building OK with mingw32-make
Building OK with mingw32-make -j (in less than half a minute ^^ ) except that my terminal color switched to red.

I'm testing how it works now.

Good job :-)

edit: typo fix

Matthew Leverton
simast said:

I suppose it depends on the runtime. Starting with MSVC 11.0 (Visual Studio 2012) - you need Vista+.

But this page shows Windows XP support...


I think the Visual Studio application needs vista to run, not necessarily the executables compiled in it (?) ???


But this page ... shows Windows XP support...

To get your executable to run under Windows XP with Visual Studio 2012, you need to:

1) Build with Visual Studio 2012 (Update 1 installed and required for XP support)
2) Select a special "v110_xp" Platform Toolset in project options.

and to run..

a) Statically link with MSVC 11.0 runtime
b) Have Visual C++ 2012 Redistributable (Update 1) installed on your machine.

I take it the allegro binary builds that were posted above had the default "v110" Platform Toolset selected - which requires Vista+ to run.

Edit: See this blog post for more info.

MS had the idea they can silently drop Windows XP support.. but then got lots of heat based on their decision and that's why now you have this whole separate Platform Toolset and Update 1 fiasco :)

Matthew Leverton

That's helpful. I'm just trying to answer somebody's question on Stackoverflow. I would guess that the Allegro binaries weren't built that way, and thus do require Vista.

Neil Roy

Many thanks for posting the binaries. It's much appreciated.


If you think version for some toolchain is missing, let me know.

I don't suppose binaries for 4.7.1 TDM would be possible? It's what comes with Code::Blocks by default now and I wouldn't mind upgrading my 4.6.1 to it. (ie: allegro-5.0.9-mingw-4.7.1-tdm.7z)

I would compile it myself but I always seem to have problems. Maybe I'll try again.


You know, maybe we should convince he code blocks people to package allegro 5 , it's mature enough....

david nickson


I can't seem to get ALLEGRO_MIN_LINEAR and ALLEGRO_MAG_LINEAR to work with allegro 5.0.9 and Direct3D.
I think my code is correct as it works when I set al_set_new_display_flags( ALLEGRO_OPENGL );
I've read in the changelog of version 4.9.22: "Added three new bitmaps flags ALLEGRO_MAG_LINEAR, ALLEGRO_MIN_LINEAR, ALLEGRO_MIPMAP. Removed the config settings for linear/anisotropic min/mag filtering. DirectX side not yet updated."
Is it still not working on allegro 5.0.9 ?
Was it fixed in an unofficial version or has someone a fix?


Trent Gamblin

That was a long time ago. It should be working now. What do you mean by "it doesn't work"?

david nickson

Thanks for the reply,

It looks like that the allegro_min_linear/allegro_max_linear is not taken into account with direct3d rendering.

I attached an image to show the differences.
On the left, it's a screenshot with opengl rendering.
On the right, with direct3d rendering.
The top image is enlarged on the screen, so it should use allegro_max_linear.
On the bottom image, the numbers are displayed smaller than their texture, so it should use allegro_min_linear.
I also tried using allegro_mipmap, but I still have the issue.

I'm using allegro 5.0.9 (precompiled versions)

Trent Gamblin

Can you either 1) post your code or a small example that demonstrates this or 2) try running ex_filter (since you're using the binaries you may have to download the 5.0.9 source and compile it.)

david nickson

Thanks for the suggestions, it was very helpful

I compiled the ex_filter sample and it didn't have the bug.
Then I remembered that I render everything using the primitives addon.

I updated the ex_filter sample to use al_draw_prim and could reproduce the issue.
The updated sample with the bug is here:

I also uploaded a screenshot : top is opengl, bottom is direct3d


Trent Gamblin

I guess the primitives addon may change some state, thought not sure why it would change that particular state. Don't even have Allegro on this computer to check. My initial guess is the shaders primitives uses get it wrong?


Looks like in OpenGL the sampler state is a bitmap property, while in D3D it is a display property... i.e. you need to re-set it before every draw call. I fixed this in 5.1.

I think this also affects the shader stuff (I didn't see if the sampler states are set anywhere for textures other than the first one). It's a little late, so I won't be able to fix this myself.

EDIT: Incidentally, a workabout that might work (untested) is to draw the affected bitmaps with al_draw_bitmap_region (just use a 0 width destination, so nothing is actually drawn). Allegro doesn't bother to reset the sampler states, so they will remain set correctly when the primitives code runs. The proper fix will be in 5.0.10 though (and is already in 5.1 branch and will be in the 5.1.6 snapshot).

david nickson

The workaround with an empty al_draw_bitmap_region works!
I'll use this while waiting for a stable binary release with the proper fix.

Thanks a lot Trent and SiegeLord!;)

Thread #612056. Printed from