http://sourceforge.net/projects/alleg/files/allegro/5.0.7/

Changes from 5.0.6 to 5.0.7 (June 2012)
***************************************

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

Core:

   * Fix ALLEGRO_STATIC_ASSERT collisions from different files included
     in the same translation unit. Reported by tobing.

   * Make al_ref_cstr, al_ref_ustr and al_ref_buffer return const
     ALLEGRO_USTR* instead of just an ALLEGRO_USTR* (Paul Suntsov).

   * Make al_ustr_empty_string const correct.

   * Fix many memory leak/warnings on MacOS X (Pär Arvidsson).

   * Fix typo preventing get_executable_name from using System V procfs
     correctly. Reported by Max Savenkov.


Displays:

   * Add ALLEGRO_FRAMELESS as a preferred synonym for the confusing
     ALLEGRO_NOFRAME flag.

   * Rename al_toggle_display_flag to al_set_display_flag, retaining
     the older name for compatibility.

   * Set WM_NAME for some window managers (X11).


Graphics:

   * Force al_create_bitmap to not create oversized bitmaps, to
     mitigate integer overflow problems.

   * Removed initial black frame on all Allegro programs.


OpenGL:

   * Texture should be 'complete' (min/mag and wrap set) before
     glTexImage2D.

   * Fixed a bug in al_unlock_bitmap where the pixel alignment
     mistakenly was used as row length.

   * Fixed typo in names of some OpenGL extension functions.

   * Display list of OpenGL extensions in allegro.log also for OpenGL
     3.0.


Direct3D:

   * Fixed a bug in the D3D driver where separate alpha blending was
     being tested for when it shouldn't have been (Max Savenkov).

Input:

   * Monitor /dev/input instead of /dev on Linux for hotplugging
     joysticks (Jon Rafkind).

   * Do not permanently change the locale for the X11 keyboard driver.
     Set LC_CTYPE only, not LC_ALL.


Audio addon:

   * Fix desychronization due to inaccurate sample positions when
     resampling. Thanks to _Bnu for discovering the issue and Paul
     Suntsov for devising the correct solution.

   * Fix linear interpolation across audio stream buffer fragments.

   * Fix two minor memory leaks in the PulseAudio driver.


Image I/O addon:

   * Improve compatibility of BMP loader. In particular, support
     bitmaps with V2-V5 headers and certain alpha bit masks.

   * Fix TGA loader using more memory than necessary. Reported by Max
     Savenkov.


Font addon:

   * Use user set pixel format for fonts.

Native dialogs addon:

   * Clear mouse state after dialogs or else it gets messed up (OSX).

   * Fix some warnings in gtk_dialog.c.

   * Wrap use of NSAlert so it can be run on the main thread with
     return value.


Examples:

   * Add ex_resample_test.

   * ex_audio_props: Add bidir button.

   * ex_joystick_events: Support hotplugging and fix display of 3-axis
     sticks.

   * Add test_driver -no-display flag. (Tobias Hansen)


Other:

   * Various documentation updates.

   * Other minor bug fixes.

   * Fix whatis entries of man pages. (Tobias Hansen)

MD5SUMS:
03a6762fc6760577339be7c07b3d17f9  allegro-5.0.7.7z
e4ed66093edf45497f45411488dd82e6  allegro-5.0.7.tar.gz
b60e9dd396010e9551949770d9191892  allegro-5.0.7.zip

Thanks, devs!

I'm having one issue on OS X. Here is the error:

Undefined symbols for architecture i386:
  "__al_mangled_main", referenced from:
      __al_mangled_main$non_lazy_ptr in liballegro_main-static.a(osx_main.m.o)
     (maybe you meant: __al_mangled_main$non_lazy_ptr)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture ppc:
  "__al_mangled_main", referenced from:
      __al_mangled_main$non_lazy_ptr in liballegro_main-static.a(osx_main.m.o)
     (maybe you meant: __al_mangled_main$non_lazy_ptr)
ld: symbol(s) not found for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//cclCujt1.out (No such file or directory)
make[2]: *** [examples/ex_audio_chain] Error 1
make[1]: *** [examples/CMakeFiles/ex_audio_chain.dir/all] Error 2
make: *** [all] Error 2

Not sure what is causing the problem but it only happens on the C++ example.

Windows build is available:

allegro-5.0.7-mingw-4.5.0.7z
allegro-5.0.7-mingw-4.5.2.7z
allegro-5.0.7-mingw-4.6.1-tdm.7z
allegro-5.0.7-mingw-4.6.2.7z
allegro-5.0.7-msvc-10.0.7z
allegro-5.0.7-msvc-9.0.7z

Todd, can you confirm that ex_audio_chain is fixed if you change the main signature to:

int main(int argc, char **argv)

I wish I had thought of this yesterday.

EDIT: actually, I'm certain that's what it is.

I replaced the libraries in my Allegro 5.0.6 project and updated the paths in the Build Options. Now I'm getting a lot of undefined references in the Audio library:

Does anyone know what I'm doing wrong? Am I missing a file or something?

I'm using MinGW 4.6.2, btw.

Is there an OpenAL library in the lib folder?

Nope. But there wasn't one in the .7z-archive (I used the binaries here from Allegro.cc) either.

There should be libopenal-1.14-static-mt.a. Can you check that?

Redownloaded 5.0.7 for MinGW 4.6.2 about an hour ago. No OpenAL library in there. :/

That fixes it.

I just downloaded the ZIP version of the MinGW 4.6.2 archive and this one has the Open AL libraries in it, so it seems that only the 7z archives are missing it.

However, I don't know where to put the Open AL library in the linker settings. This is my current setup:
Link
Where do I have to put Open AL? I assume somewhere after Audio?

EDIT:
Wait... nevermind. It seems the files actually ARE in the 7z archive. Wonder how I missed them! 0_o
Still the question: Where in the list do I have to put the Open AL library?

EDIT:
I put it directly after Audio, now it's working.

^ this is why when people email me at work with problems I wait 3 hours and usually the problem is fixed without stopping me from doing useful stuff like drinking coffee, talking to people or browsing

Normally I wait a little longer before asking questsions myself, but I swear I looked through the folder two or three times and didn't see the Open AL library in it until I downloaded the ZIP version.

If I'm looking at a large folder, I just open a command prompt and do a "ls | grep -i fragment_of_a_name_im_looking_for" instead of trying to find it by skimming. Yes I know you can use wildcards directly with some flags.

In the context of tech support, when people give me direct answers to direct questions, I don't believe them.

Hmm, maybe I should take that to heart, and question the answer I got from you earlier

Since I'm fiddling with python for the moment, I checked the WANT_PYTHON thing in the cmake gui and built it. This is my result for python

pepsi@fractal:/home/prog/allegro-5.0.7/build/python 03:13 PM $ python allegro.py 
os name posix
Cannot find function al_draw_tinted_scaled_rotated_bitmap_region
Cannot find function al_get_parent_bitmap
Cannot find function al_set_display_flag

Python version is

pepsi@fractal:~ 01:25 AM $ python
Python 2.6.6 (r266:84292, Nov 27 2010, 17:27:14) 
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
> 

I added the 'print "os name " + os.name" myself just to make sure it was something sensible.

I'm not worried about it, I wouldn't make a game in python anyway, just curious.

Have you copied the libraries to the right location? AFAIK, make install doesn't do that.

I've got a huge mess in /usr/local/lib that looks like this (small sample)

-rwxr-xr-x 1 root  root  4710193 Aug 25  2011 liballegro-debug.so.5.1.0
rw-r--r- 1 root  root  1597544 Apr 25 23:01 liballegro-static.a
lrwxrwxrwx 1 root  root       17 Nov 10  2011 liballegro.so -> liballegro.so.5.0
lrwxrwxrwx 1 root  root       19 Jun 27 14:58 liballegro.so.5.0 -> liballegro.so.5.0.7
-rwxr-xr-x 1 root  root  4658243 Nov 16  2011 liballegro.so.5.0.5
-rwxr-xr-x 1 root  root  4954349 Apr 18 16:36 liballegro.so.5.0.6
-rwxr-xr-x 1 root  root  5112993 Jun 27 14:56 liballegro.so.5.0.7
lrwxrwxrwx 1 root  root       19 Aug 25  2011 liballegro.so.5.1 -> liballegro.so.5.1.0
-rwxr-xr-x 1 root  root  4772604 Aug 26  2011 liballegro.so.5.1.0
lrwxrwxrwx 1 root  root       30 Nov 10  2011 liballegro_acodec-debug.so -> liballegro_acodec-debug.so.5.0

so I'd guess they are. I did issue an ldconfig btw.

[EDIT]

Well I copied a python OOP example off the web, and when I added one more instance it crashes. Ghod, even Borland could do better than that! (except for not finding out how bad it was before writing 70K sourcecode programs). I want my 24 hours back.

[EDIT2]

I added this tiny little OOP program into the paperclip if anybody wants to play with it.

I mean the libs/includes you get in build/python. Did you copy them to your python system folder?(ps: I don't inow the exact location they should be, you might want to read the python readme file)

Python was included in the distro, and I've been using blender all this time with no problems. I'm glad the blender addon devs know all the painful workarounds to make their little toy language work.

I wasn't talking about the readme on how to use python, I was talking about the readme on the python part of allegro. There are instructions on which files you need to copy where to make it work.

I've once again decided not to use Python (happens every couple years when I try it anyway), in spite of all those programming jobs on Craigslist that I see while looking for a job. It would also be somewhat handy to have an export option to output what I need directly instead of making a C version to read the OBJ files that Blender can export with .py files (not that they work half the time anyway). So I'm all better now and don't care about allegro and python.

Will the allegro-5.0.7-msvc-10.0.7z work on msvc-12? I'm guessing no, if that's the case then I'll have to use the msvc12 compiler to compile allegro 5?

Try it out. I'm sure you have the 5 minutes to check.

The shared libs are more likely to work than the static ones, I would think.

Actually I did try it out, and it worked with allegro.h haven't tried any of the addons. But the second question still remains.

Should work fine if you use DLL version.

Hi-five! slaps

Going to have a look at this when I get home. Although those warnings never led to any bugs that I noticed, it's probably best that they're fixed.

Could someone explain to me why did they change this:

There is now a quick white "blink" at program startup. IMO for game development default black startup backbuffer was a good idea.

If you imediately clear and then flip the display yourself, it should fix that. And now you can pick the colour yourself, or draw a bitmap (so long as the image loading doesn't take too long).

Thanks! That did the trick.

The problem was if you wanted the game to start with a title screen, then there was a black flash. Ideally the window would only appear at all on the first call to al_flip_display. (Probably by setting some "hidden" flag on window creation.) That way we could be sure the shown contents are what the user wants from the first frame on. If anyone wants to make a patch for it...