Let's start the New Year with a new WIP release of Allegro!

Get the sources here: https://sourceforge.net/projects/alleg/files/allegro-unstable/5.1.9/

Changes from 5.1.8 to 5.1.9 (January 2015)

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

Core

• Fix OSX backend on OSX 10.10 (lordnoriyuki).

  
  

• Simplify how sub-bitmaps interact with their parent bitmaps. You can now destroy a sub-bitmap at any time (not only before the parent is destroyed). Additionally, when the parent is converted using al_convert_bitmap, all the sub-bitmaps are also automatically converted.

  
  

• Switch to using unicode Win32 (e.g. this fixes using al_set_window_title with unicode strings).

  
  

• Add some Linux WM hints so make Allegro windows work more smoothly (especially with Unity).

Filesystem

• Add al_fprintf (DanielH and Tobias Scheuer).

  
  

• Add al_for_each_fs_entry, a convenience function that helps enumerating the contents of a directory more easily using a callback function (Beoran).

  
  

• Fix for al_get_standard_path with Unicode (vkensou).

Input

• Add X11 touch driver (Ryan Gumbs).

  
  

• Emulate mouse pressure for backends that don't support pressure.

  
  

• Added Windows haptics driver, XInput joystick driver (Beoran).

  
  

• Fix OSX joystick deinitialization.

Graphics

• Add block compression pixel formats (ALLEGRO_PIXEL_FORMAT_COMPRESSED_RGBA_DXT1/DXT3/DXT5) for compressed video bitmaps. This includes an API to fetch compressed block size ( al_get_pixel_block_width/height/size) as well as API to load and unload compressed bitmap data without paying a runtime compression cost ( al_lock_bitmap_blocked). Unfortunately, due to patent concerns this last feature is disabled for OpenGL (if you think those concerns don't apply to you, you can enable it by passing -DWANT_OPENGL_S3TC_LOCKING=1 to cmake).

  
  

• Make real fullscreen modes work on OS X again. May not be perfect still. (thanks to SDL).

Shaders

• Don't clobber the 0'th texture unit in OpenGL and Direct3D. This simplifies working with shaders.

Android port

• Bump minimum Android API level from 10 to 12 (aka version 3.1).

  
  

• Add controller support to the Android port. An accelerometer 'joystick' is still the first joystick. Supports two analog sticks and 10 buttons (A B X Y L1 R1 DPAD_L DPAD_R DPAD_U DPAD_D). Supports hotplugging and theoretically multiple joysticks (needs testing).

  
  

• Set correct orientation at startup on Android (thanks to Aikei_c).

Build system

• Various CMake fixes.

Other

• Add Travis and AppVeyor continuous integration support.

  
  

• Fix a lot of memory leaks.

  
  

• Many documentation improvements.

Audio addon

• Disallow attaching a mixer to itself.

  
  

• Fix uni- and bi-directional looping of zero-length samples.

  
  

• Fix/avoid all sound examples freezing on OSX with the aqueue driver.

Image addon

• Add functionality to load Direct Draw Surface files (.dds). Only compressed pixel formats are supported (DXT1, DXT3 and DXT5).

Dialog addon

• Fix native file dialog default paths on Windows (Edgar Reynaldo).

  
  

• Fix unintended behaviour in al_set_menu_item_flags (Malcolm Harrow).

  
  

• Fix some bugs with native menus in OSX.

Video addon

• Fix for now undefined AVCODEC_MAX_AUDIO_FRAME_SIZE (Dennis Busch).

TTF addon

• Fix a crashing bug in the TTF addon.

  
  

• Make al_load_ttf_font_stretch return NULL if invalid width/height are passed.

Font addon

• Add multi line text output for the font addon ( al_draw_multiline_text, al_draw_multiline_textf and al_draw_multiline_ustr).

Primitives addon

• Fix some sharp-angle polyline drawing bugs.

Examples

• New examples: ex_compressed, ex_font_multiline.

  
  

• ex_dir: demonstrate al_for_each_fs_entry.

  
  

• ex_haptic2: demonstrate hotplugging.

MD5SUMS:
02565b8661532a25ae768ba31aa41a3b  allegro-5.1.9.7z
05baacbd06fb1e08dad202f057541ee5  allegro-5.1.9.tar.gz
58de0daa6bf85b108a221c6c569b8cb0  allegro-5.1.9.zip

Woo! Thanks to all the contributors for their hard work and contributions

SPLENDID!

Great work everybody!

oooh, the star of the show

Yeah, I contributed that functionality with SiegeLord's help. Glad to finally have a new release! And thanks to everyone and a happy new year!

Oh yeah... not sure why that's uncredited. It's my first time releasing Allegro, I don't know how change-lists works .

I agree that al_draw_multiline_* series implements a fantastic and long-awaited feature. (The new sub-bitmap functionality also falls into this category.) At the same time, simple bug fixes and documentation additions improve Allegro just as much as feature additions. It's great to see both.

Thank you, devs and everyone involved! You guys are awesome!

Here are a few compiler warnings being discussed in #allegro (using freetype2 2.5.5-1 and ffmpeg 1:2.5.2-2):

Did anyone catch that compressed textures are now supported (thanks to SiegeLord)? These can save loads of video memory if you're not using pixel art.

EDIT: I believe they need to be enabled manually at compile time due to potential patent implications.

The story behind compressed textures is like this:

By default, you can load non-compressed textures and compress them on the fly. Check out ex_compressed as it does exactly that. This is typically 3-4x slower than keeping them un-compressed. That's why typically you want to compress them ahead of time (also the quality varies between GPUs so you might get better quality if you compress them yourself ahead of time).

By default you cannot load pre-compressed textures with OpenGL (you can load them fine in D3D) unless you compile Allegro with that feature enabled.

Yea,texture compression is cool, but due to the patent problems of DXTC it's probably a good idea to try and implement support in the future for ETC and ASTC which are not patent-encumbered. Should be faster than waiting for the patent to lapse

I did not, but I want to try it now. Thanks for the addition (and explanation), SiegeLord. The compile-time option for OpenGL sounds like a good solution.

Great work and big thanks for all your efforts everyone.

Congratulations

By the way, typo in the date of official site's news page(http://alleg.sourceforge.net). It should be 2015.

That's just embarassing . Thanks!

Yeah. The only issue is that I think the desktop GL support for those is spotty. For mobile, however, we pretty much will have to implement more formats. I decided not to wait that long though .

Yeah, the other compression algorithms may not be supported on all desktops, but that's entirely out of our hands. We'll have to wait until OpenGL implementations catch up. With some conditional compilation, etc, and maybe a query interface to heck which compression algorirthms are available, this could be solved without too much of a hassle.

Looking for binaries for MinGW 4.7.0 please and thanks.
Edit: actually, for any version of MinGW, preferably a modern version, I'm willing to upgrade my MinGW for it.

Feels good see a new release from time to time. Thanks for the effort!

I usually don't comment new releases because I'm sort of a GIT folk , but I MUST commend all the developers for the incredible piece of software which is Allegro.

I the last weeks (since till tomorrow I'll be unemployed! ) I had the chance to play around the source and try to make my way through it to be able to contribute and...

...well, THIS library my fine gentlemen is incredibly modern and well-tought.

So triple kudos to all developers of this great tool, absolutely outstanding.

Cheers
-pkrcel

Here you can find my unofficial distributions of MinGW 4.8.1

MinGW 4.8.1

and my unofficial Allegro 5.1.9 binary distribution. It comes with src, static linked example programs, dlls and static and dynamic libraries for most every dependency, and debug and release versions for Allegro 5. You need 7zip to unpack it. Once installed right click on the 7z file in Explorer and select 'Extract here' or wherever you want it.

Allegro 5.1.9 binary distribution for MinGW 4.8.1

Many thanks for that!

Edit: Tried it out with MinGW 4.8.1, had too many compile errors. I think certain libraries are missing from this like OpenAL. Reverting back to 5.0.10 and MinGW 4.7.0. I'll have to see if I can't figure out how to compile this beast. :/

Got some signed/unsigned comparison warnings from the latest ttf.c:

addons/ttf/ttf.c:290:18:
    for (y = 0; y < face->glyph->bitmap.rows; y++) {
                  ^
addons/ttf/ttf.c:296:24:
          for (x = 0; x < face->glyph->bitmap.width; x++) {
                        ^
addons/ttf/ttf.c:309:24:
          for (x = 0; x < face->glyph->bitmap.width; x++) {
                        ^
addons/ttf/ttf.c:331:18:
    for (y = 0; y < face->glyph->bitmap.rows; y++) {
                  ^
addons/ttf/ttf.c:336:24:
          for (x = 0; x < face->glyph->bitmap.width; x++) {
                        ^
addons/ttf/ttf.c:346:24:
          for (x = 0; x < face->glyph->bitmap.width; x++) {
           ^    ... j/k ^ it's here

Thanks for that compilation output . It's fixed in git latest.

But I never compiled OpenAL. Wait, I have it. I don't know if cmake linked against this openal or another version I had installed so I will rebuild openal and allegro. OpenAL would only compile a shared version with cmake but is now included in the headers and libs and bin directories. I also recompiled the examples to be debug static link. I then recompiled the debug and release shared and static monolith versions of allegro 5.1.9.

Get the updated MinGW 4.8.1 Allegro 5.1.9 binary package here
Make sure it says A519distro2.7z

Great stuff... but now Sourceforge is temporarily offline. It's as if I was not meant to use this version. I'll try again later.

Edit: Okay, I got it downloaded and installed. My game compiled okay with it (I am curious, I staticly link my libs, so libOpenAL.dll.a confused me as there wasn't a static version, the game runs, but will this need the dll? It seemed to run without it <confused>)

The game ran with no problems or errors when compiled with MinGW 4.7.0 and Allegro 5.1.8 (I had recently started using 5.1.8, I used to use 5.0.10), this was compiled with a fresh MinGW 4.8.1-4 and the Allegro you supplied.

Anyhow, game ran fine, but when I went to exit the game it froze. Even in debug mode it wouldn't show me which line this happened on (Code::Blocks) so after some crude searching I narrowed it down to this line:

al_destroy_display(setting.screen);

setting.screen being set with:

   setting.screen = al_create_display(WIDTH, HEIGHT);
   if(!setting.screen) {
      a5_error(AT, setting.screen, "Create display failed.");
      shut_down();
      exit(1);
   }

Most of the time when it froze, the only way to shut it down was to close the console screen (if I ran it in release mode, which has no console, than I was screwed, only the task manager could shut it down then). There was two times it crashed that a message momentarily flickered on the screen (closed the console, then a message appeared and the console would close before I could read it). The second time this happened I hit my printscreen and captured it.

(most text is from my game, just the assertion failed line is new)
{"name":"609239","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/2\/1293fca4dd91c95e8656623d288c57b7.jpg","w":651,"h":312,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/2\/1293fca4dd91c95e8656623d288c57b7"}

Edit: also, my game now requires "libogg-0.dll" to run, even though it is statically linked.

Edit: Just tested my editor as well (which is separate from the main game and uses no sound effects at all) and it actually exits okay, but the al_create_native_file_dialog() function doesn't work at all for saving, only loading.

Here's my code, this works with 5.1.8 no problem (except there is no default filename, which is the main reason I want 5.1.9 to work)...
file_dialog = al_create_native_file_dialog(".//level001.dp2", "Save Level", "*.DP2", ALLEGRO_FILECHOOSER_SAVE);

Changed ".//" to "//" at the start and it brought up the dialog for saving, but still no default filename at all.
file_dialog = al_create_native_file_dialog("//level001.dp2", "Save Level", "*.DP2", ALLEGRO_FILECHOOSER_SAVE);

Wow, you're having quite a bit of issues!

This is a weird place for it to crash... if you can, could you place a breakpoint in that file and paste backtrace? I don't know if it can be done easily from Code::Blocks though... I'll see if I can investigate it a bit later.

That's just the way Edgar compiled the library.

Have you tried just "level001.dp2" without any slashes? That seemed to work for me (on Win7).

Is there a way to link statically to the dependencies in a dynamic cmake build? I just let cmake handle that stuff for me. You can just use the static versions if you don't want it dependent on other stuff too.

You have to provide the default name. And what directory are you trying to start in with .// ? That isn't valid on Windows. But .\\ is.

Not sure. If I had to guess, it'd be just by manually selecting the static libraries as dependencies (or just making sure only the static libraries can be found by cmake).

I am trying to access the same folder the game is installed in. And this works with 5.1.8 without errors with .//. However, I did provide the default name (see my post, I showed the code I used). In any event this is a moot point due to the crash which takes place. 5.1.8 works though (with 4.7.0, premade) so I'm using it currently. Would be nice to get that default filename working.

Maybe I'll try it again, just to test if I can get that part working anyhow, to see if it was just my own error in how I was doing it (one less thing to think about).

Edit: Okay, I tested it out before saving this reply and the default filename does now work. Good. So that's one less problem. I guess the whole ".//" and "//" was wrong. Someone had posted that as a way for just checking the same folder as the executable so that is why I used it. Seemed to work with 5.0.10 and 5.1.8, but that was probably just a fluke that it worked.

I may end up statically compiling the level editor with 5.1.9 +MinGW 4.8.1-4 so I get the default filename (as it doesn't crash on exit, not sure why not, it doesn't use a lot of things the main game does though) and 5.1.8 + MinGW 4.7.0 for the main game to avoid the crashes as it doesn't need the default filename feature anyhow. I have both versions of the compiler installed presently. Meanwhile I may try my hand at compiling it again myself. I came close last time. Now that I uninstalled World of Warcraft I have plenty of time on my hands.

This worked for me in the past, thou it's been a while now since I have a more flexible build environment in which I use dynamic linking (nothing to distribute yet! )