https://sourceforge.net/projects/alleg/files/allegro/5.0.9/

MD5SUMS
f7b59457388e7f57a3ec4fd4bbdbd727  allegro-5.0.9.7z
59fb41dccc300be0044cfad5fff0ca81  allegro-5.0.9.tar.gz
f4ce97136d1fc90ac061ef55549d8d4a  allegro-5.0.9.zip

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

All those header moves ...

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

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

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?

It's not a stray joystick, is it?

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

Which includes drop and motions sensors. da** linux .

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 (https://www.allegro.cc/forums/thread/611833/0) 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.

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.

APrince:

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

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

A little late, but it is ready. Windows build of Allegro 5.0.9.

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

allegro-5.0.9-mingw-4.5.0.7z
allegro-5.0.9-mingw-4.5.2.7z
allegro-5.0.9-mingw-4.6.1-tdm.7z
allegro-5.0.9-mingw-4.6.2.7z
allegro-5.0.9-mingw-4.7.0.7z
allegro-5.0.9-msvc-10.0.7z
allegro-5.0.9-msvc-11.0.7z
allegro-5.0.9-msvc-9.0.7z

Thanks a lot.

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

But this page shows Windows XP support...

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

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

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.

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

Edit:

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

Hi,

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?

Thanks

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

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)

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

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: http://pastebin.com/CgSpPs4e

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

Thanks.

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

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!;)