Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 5.2.4 released!

This thread is locked; no one can reply to it. rss feed Print
Allegro 5.2.4 released!
SiegeLord
Member #7,827
October 2006
avatar

Another release of Allegro!

{"name":"HDdrakZ.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/d\/3dc35bef48731a14c5c72f0153ed38c1.png","w":659,"h":666,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/d\/3dc35bef48731a14c5c72f0153ed38c1"}HDdrakZ.png

Download source and MinGW binaries at at downloads page. Ubuntu and Nuget packages are also available. Homebrew will be updated soon.

Changes from 5.2.3 to 5.2.4 (February 2018)

The main developers this time were: Sebastian Krzyszkowiak, Elias Pschernig, SiegeLord.

Core

  • Fix errors when reading/writing 0 byte buffers (Bruce Pascoe).


  • Re-initialize TLS when Allegro is installed (Issue #865).


  • Add al_transform_coordinates_4d.


  • Don't initialize the trace mutex multiple times (Issue #874).


  • Fix 3D (non-projection) transforms with al_hold_bitmap_drawing.

Raspberry Pi port

  • Fix compilation on RPI.

Android port

  • Remove limit on the working directory length.


  • Fix ALLEGRO_MAXIMIZED flag.


  • Fix build with older Android NDKs.


  • Remove glClear hack for Android 2.1.

Linux port

  • Make compositor bypass configurable in X11, and bypass only when fullscreen by default.

OSX port

  • Fix a few OSX retina scaling issues (Issue #851).

Audio addon

  • Fix ALSA lag.


  • Add an option to use the desktop window when initializing DirectSound (Issue #877).

Font addon

  • Add support for bmfont format.

Native dialog addon

  • Resize the display on Windows when hiding/showing the menu (Issue #860).


  • Detect when al_popup_menu fails to actually work under GTK (Issue #808).


  • Don't clear the top-level menu when destroying the popup menu.

Build system

  • Don't link in libm on MSVC for DUMB (Issue #847).


  • Don't use the LOCATION property (Issue #847).


  • Don't use SYSTEM for DirectX includes.


  • Add hints for mingw-w64 path locations for DirectX includes/libs.

Python binding

  • Fix the Python code-generation scripts to run under Python 2.

Lua binding

  • Add script to generate LuaJIT C API for Allegro 5 (BQ).

Documentation

  • Many improvements (Andreas Rönnquist, others)

Examples

  • Add a texture to the skybox in ex_camera.

SHA256 SUMS:

b4c538c754a8ff8592544b5ac8c608be1cada4dfa4fdd286f749d963d77ac638  allegro-5.2.4.0.7z
6b4fa42c7966bb954191185798b5aaa6f5bb1ed79ec28a67880ea7e556d1723f  Allegro.5.2.4.0.nupkg
346163d456c5281c3b70271ecf525e1d7c754172aef4bab15803e012b12f2af1  allegro-5.2.4.0.tar.gz
662b340801331743e8f09462e83e51ccbbce5cac0a9f833df5f543686c7373a7  allegro-5.2.4.0.zip
0624b9f87acc851d401f6dbc779302312e87e5eec95f95cd3b8879b7115cbf34  allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-dynamic-5.2.4.0.zip
7941825ae898fbc159abaf935c0e386d089fa651f81b40bee61c4e80170fc8d0  allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-static-5.2.4.0.zip
dfd449d8a2c1c7c0d39d227d9b0f5e1b6c653249227cdca6cc487abb6572ad16  allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-dynamic-5.2.4.0.zip
40eb9b00a5f2b1f65420af6b84bfd2f91030c8ac22da659043c8d4d1221e7dd1  allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-static-5.2.4.0.zip
b3b2d43b047594a774069cb9169a4dd060a789e3649ad472867009ffbb827092  allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-dynamic-5.2.4.1.zip
736e897fb3062fccb375c31102ea3e96fb9f8acc24e644243f982b57a225863a  allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-static-5.2.4.1.zip
babc80a523fcb99039ca443cdecb2da48a19f2ab726cff630617f096c52bb008  allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-dynamic-5.2.4.1.zip
92ee2e110c2229c8489450af98076533abc399264ca25932a981aabe81c05548  allegro-x86_64-w64-mingw32-gcc-7.2.0-posix-seh-static-5.2.4.1.zip

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Chris Katko
Member #1,881
January 2002
avatar

Woo!!!!!! Thank you for your work.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

GullRaDriel
Member #3,861
September 2003
avatar

Good job. Thanks mate :-)

"Code is like shit - it only smells if it is not yours"
Allegro Wiki, full of examples and articles !!

Edgar Reynaldo
Member #8,592
May 2007
avatar

NiteHackr
Member #2,229
April 2002
avatar

Very nice, and I like the prebuilt binaries. Still not sure if I ever want to compile this myself. ;)

Edit: Okay, just tried out the precompiled libs with my Deluxe Pacman 2 game, as I usually do. It seems to be a good test program as it compiled fine with previous versions and I have not worked on it at all, so it should compile fine now... of course... as usual... it did not. I am noticing something new, I don't know what it is so I don't know how to deal with it. Definitely not anything I need in my own program but...

||=== Clean: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
||=== Build: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `WebPGetFeatures':|
F:\msys64\mingw32\include\webp\decode.h|431|undefined reference to `WebPGetFeaturesInternal'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `WebPInitDecoderConfig':|
F:\msys64\mingw32\include\webp\decode.h|467|undefined reference to `WebPInitDecoderConfigInternal'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `load_from_buffer':|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|53|undefined reference to `WebPDecode'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(webp.c.obj)||In function `al_save_webp_f':|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|132|undefined reference to `WebPEncodeLosslessRGBA'|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|136|undefined reference to `WebPEncodeRGBA'|
C:\dev\allegro_winpkg\universal\allegro\addons\image\webp.c|146|undefined reference to `WebPFree'|
C:\MinGW_Dev_Lib\lib\liballegro_monolith-debug-static.a(opus.c.obj)||In function `init_dynlib':|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|102|undefined reference to `op_free'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|103|undefined reference to `op_channel_count'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|104|undefined reference to `op_open_callbacks'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|105|undefined reference to `op_pcm_total'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|106|undefined reference to `op_pcm_seek'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|107|undefined reference to `op_pcm_tell'|
C:\dev\allegro_winpkg\universal\allegro\addons\acodec\opus.c|108|undefined reference to `op_read'|
||error: ld returned 1 exit status|
||=== Build failed: 14 error(s), 0 warning(s) (0 minute(s), 10 second(s)) ===|

Of course, I should probably stop using monolith and just use the individual components I need to avoid this. But, if this helps someone else understand what is up...

SiegeLord
Member #7,827
October 2006
avatar

Thanks, Neil, for testing, I appreciate it. There's two things here. First, the webp dependency is accidental, when I was building the binaries it picked up my globally installed version... this will require new binaries, which I'll upload shortly. The opus dependency is meant to be there, and you can download it from here https://github.com/liballeg/allegro_winpkg/releases. You link -lopus -lopusfile.

In fact, using the individual libraries wouldn't help you here, unless you don't use image and acodec addons at all. The reason why these dependencies exist even in static libraries is that Allegro supports determining the file format at runtime (via al_load_bitmap and al_load_sample etc) which means that the linker can't know for sure that you won't use that code, and remove it.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

NiteHackr
Member #2,229
April 2002
avatar

Ah, okay. I had a feeling that at least one solution would be missing links.

On a positive note: I thought the prebuilt binaries with the new version is a huge plus for this. And the locations to download them seemed fairly well organized, so koodos for that.

I just tried another clean compile with the new upload and opus links, it helped, but still missing something. I don't know if there is a specific place I should link opus? After any others? I tried at the end of my links, the start, in the middle... I am using Code::Blocks/MinGW7.2 (new one, fresh install).

||=== Clean: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
||=== Build: Debug in Deluxe Pacman 2 (compiler: GCC GNU Compiler) ===|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_get_packet_duration':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|742|undefined reference to `opus_packet_get_nb_frames'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|744|undefined reference to `opus_packet_get_samples_per_frame'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_clear':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1479|undefined reference to `opus_multistream_decoder_destroy'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_float2short_filter':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|3131|undefined reference to `opus_pcm_soft_clip'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_decode':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|2729|undefined reference to `opus_multistream_decode_float'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_update_gain':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1332|undefined reference to `opus_multistream_decoder_ctl'|
C:\MinGW_Dev_Lib\lib\libopusfile.a(opusfile.c.obj)||In function `op_make_decode_ready':|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1363|undefined reference to `opus_multistream_decoder_destroy'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1364|undefined reference to `opus_multistream_decoder_create'|
C:\dev\allegro_winpkg\universal\opusfile-0.8\src\opusfile.c|1359|undefined reference to `opus_multistream_decoder_ctl'|
||error: ld returned 1 exit status|
||=== Build failed: 10 error(s), 0 warning(s) (0 minute(s), 9 second(s)) ===|

SiegeLord
Member #7,827
October 2006
avatar

Maybe flip the order of -lopus and -lopusfile.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

NiteHackr
Member #2,229
April 2002
avatar

Just compiling Allegro myself to see how that goes, I will then try your build out again before I try my own (shouldn't make a difference if it is a linking issue). I think I did try flipping them, but... I'll try that again and let you know how that goes.

While compiling Allegro, I am seeing warnings about mixed declarations and code. Wouldn't it be best to compile this with C99 at least? C99 was a nice version of C to start with, and supported by all modern compilers these days. I prefer C11 myself but.

Oh, when I downloaded your version I found it funny that your build is dated February 28th, and it is still February 27th here... so I feel like I am trying the Allegro of the future! :P ;)

<still waiting on this compile>

Okay, my own personal compile of Allegro 5 FINALLY works, examples are working, so YAY for that. Thanks to your deps you included.

I recompiled using your build and after I flipped those, it linked just fine and the game runs, so yay for that too.

For other users, just note for them they need to link...

-lopusfile -lopus

(or for Code::Blocks)

opusfile
opus

..in that order.

I did see something on my debug screen to do with libpng, and I remember seeing this many years ago with another version and I don't recall what the solution was. The game works, I don't see a problem (yet), but this bugs me...

{"name":"611310","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5f09a0833452f976c55bbd303d2f4ff6.jpg","w":675,"h":340,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/5\/f\/5f09a0833452f976c55bbd303d2f4ff6"}611310

Update: Apparently the newer version of libpng is more strict and some PNGs may contain some sort of older data in the header. The warning is "harmless" and can be ignored. Warnings bug the shit out of me, so you need to download special software (ImageMagick) to strip the offending garbage out of your header and the warnings will go away. You could probably write your own Allegro 5 program to do this as well, which I may just do.

Audric
Member #907
January 2001

If I understand correctly, the colors of the offending images will appear differently on different people's screens. Stripping the wrong color profile is required to at least obtain the same rendering on everyone's screen.

NiteHackr
Member #2,229
April 2002
avatar

What I may just do is perhaps write my own conversion program using Allegro 5 to load in PNGs and resave them. See how that goes. Then I could at least automate the whole process easier. Not too big of a deal I guess.

On a positive note, been compiling this version of allegro just fine without trouble thanks to the deps included. Being able to find binaries and deps etc... easily will really go a long way to helping t his library.

I went through all the example programs. The ex_threads one crashed on me a couple seconds into it. And one other one to do with menus (ex_menu I think?), one of my menu clicks crashed it. Otherwise everything else worked great. It's been a while since I looked through the examples and there's a few more that were new to me. Looks really good I must say.

I used the GUI version of CMAKE which helped out a great deal in getting Allegro compiled, then I made Code::Blocks-MinGW Makefiles for it so I could easily load it all into Code::Blocks and compile from there which was also much nicer.

My Deluxe Pacman 2 link below is compiled with this version now.

Update
I just noticed, when trying to compile a static, "Release" version of Allegro the following examples wouldn't compile for some reason...

Not building ex_color
Not building ex_depth_mask
Not building ex_haptic2
Not building ex_font_justify
Not building ex_font_multiline
Not building ex_logo
Not building ex_projection
Not building ex_ttf
Not building ex_audio_chain
Not building ex_synth

This could have at least partially to do with the following problem...

Performing Test TTF_COMPILES
Performing Test TTF_COMPILES - Failed
Performing Test TTF_COMPILES_WITH_EXTRA_DEPS
Performing Test TTF_COMPILES_WITH_EXTRA_DEPS - Failed
CMake Warning at addons/CMakeLists.txt:126 (message):
  FreeType doesn't compile.  Disabling support.

The rest compiles okay.

SiegeLord
Member #7,827
October 2006
avatar

Freetype is unfortunately a bit of an annoying dependency, as it has dependencies of its own that there's no good way to automatically detect. To get the freetype in the dependency package to link, you need to pass -DFREETYPE_ZLIB=on -DFREETYPE_PNG=on when calling Allegro's cmake.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

NiteHackr
Member #2,229
April 2002
avatar

SiegeLord said:

To get the freetype in the dependency package to link, you need to pass -DFREETYPE_ZLIB=on -DFREETYPE_PNG=on when calling Allegro's cmake.

Thanks, that seems to have corrected the problem. Compiling it again now.

Update: Okay, I got just about every combination compiled I could think of, Release, Debug and Profile; Static and Shared. Both individual libs and monolith, just because I could. ;)

When recompiling the examples, I retested ex_thread.exe and ex_menu. Both crashed. ex_thread crashed right away. ex_menu crashed when I clicked "New #1".

beoran
Member #12,636
March 2011

Maybe we should consider vendoring STB's excellent one file libraries and use those in case the dependency isn't found. For example, for TTF: ://github.com/nothings/stb/blob/master/stb_truetype.h

Edgar Reynaldo
Member #8,592
May 2007
avatar

SiegeLord
Member #7,827
October 2006
avatar

There is no one standard, it just needs to compile on the compilers we care about. We have a warning enabled for anything that's not C89, for the sake of older MSVC compilers, but everything since MSVC 2013 could compile non C89 stuff, so that warning is a bit overzealous right now.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Edgar Reynaldo
Member #8,592
May 2007
avatar

Will you accept patches for anything compiling with warning on default settings with mingw-w64-gcc 7.2? A lot of it is "C99 standard requires declarations before code" and a few incompatible pointer types.

How do I pipe all output from make to a single file so I can search and index it?

cmd std stream redirection operators are retarded. How do I pipe stderr to stdout and then pipe that to a file?

SiegeLord
Member #7,827
October 2006
avatar

We definitely should fix all the warnings, but sometimes fixing a warning means disabling the warning. The declaration after statement stuff is definitely of the latter variety, none of the compilers we encourage have a problem with that anymore.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

torhu
Member #2,727
September 2002
avatar

cmd std stream redirection operators are retarded. How do I pipe stderr to stdout and then pipe that to a file?

thecommand > out.txt 2>&1

NiteHackr
Member #2,229
April 2002
avatar

"C99 standard requires declarations before code"

This is untrue. C99 got rid of this requirement. Only C89/C90 (they are the same version, just different standard organizations) has that requirement, C99 corrected a lot of these problems with C, including getting rid of that requirement.

If one wanted an early C standard to adopt, I would say stick to C99 at the earliest, considering some of the problems it finally corrected, like assuming ints and declarations before command requirement removed, _Bool, <stdint.h> etc...

When I recompiled Allegro (finally), I added in -std=gnu11 to the C Cmake options so it was compiled as a C11 library, which modern C compilers support. But for MSVC, I would say go for C99. It compiles C99 just fine, and has even adopted some newer C conventions to keep it compatible with C++11 or better.

SiegeLord said:

We definitely should fix all the warnings, but sometimes fixing a warning means disabling the warning. The declaration after statement stuff is definitely of the latter variety, none of the compilers we encourage have a problem with that anymore.

Yes, that warning is absolutely not required anymore at all, and it is the warning that comes up more than anything else. As I mentioned, C99 removed that requirement and added in many features that Allegro uses, so you pretty much need C99 anyhow, it added in _Bool and <stdbool.h>, which Allegro uses. It added in the different integer types with <stdint.h> and it removed the requirement for declarations before code. The last C version that required that was C90, and even MSVC supports all the features of C99, and even some newer C stuff. I think in 2018 it's time for people to let go of 28 year old standards and compilers! ;) Heck, even the C11 standard is 6+ years old, will be 7 years old this December.

Edit: With some research, the reason why variables were limited to the beginning of scope (not nessecarily the start of a function), was due to limited computer memory and CPUs at the time and single pass compilers. So if someone absolutely cannot compile Allegro due to this limitation, than their computer won't be able to run anything made with Allegro either, so it is pointless to stick to the C90 standard when C99 was such a huge improvement.

Niunio
Member #1,975
March 2002
avatar

My Linux Mint distro did updated Allegro. I was surprised how much fast they added to the repositories (Ubuntu ones?).

Seems to work nicelly, so nice work and thank-you, guys. :)

-----------------
Current projects: Allegro.pas | MinGRo

TripleG
Member #16,431
July 2016

So i noticed that it was an installed program that is causing the al_create_display to bug out. What would happen is the display allegro variable will still be null and the display would flicker a bunch of times.

The program is called Duet Display which allows duel screen using an ipad. When this program is installed that function call no longer works

I would like to report this somehow but don't know how to go about it

AMCerasoli
Member #11,955
May 2010
avatar

Showing my love guys! :)

Edgar Reynaldo
Member #8,592
May 2007
avatar

Nice work SiegeLord. ;)

I noticed you fixed some build issues, like finding DirectX and other libraries in the newer version of the mingw-w64 compiler cmake script. As well as adding in the static runtime option for mingw.

I attached a full build log on MinGW using the new GCC 7.2 compiling as is. It is attached here.

I know there are current and official binaries, but to hack allegro properly I needed a clean build, so I rebuilt everything. I hope these binaries are correct, otherwise I will fix them.

Allegro524_MinGW64-GCC72_posix_dwarf.7z

Included are html and chm docs, dlls and libs and includes for all dependencies including allegro. Current list of supported dependencies are FLAC, Dumb, Enet, Ogg, Vorbis, Theora, libJPEG, libPNG, zlib, PhysFS, FreeType (static only, but needs libpng and zlib sigh ) and I even threw in MAPM for anyone interested in arbitrary precision numbers and math.

Also included are the test driver and the test configs as well as dynamic debugging versions of all the examples. OOPS I forgot the demos, oh well, add that to my TODO.

I had to hack enet to produce static and dynamic versions. I had to patch theora to properly compile the libs because the examples were broken.

Full list :

enet-1.3.13
flac-1.3.2
freetype-2.9
libdumb_kode54_v2.0.3
libjpeg-turbo-1.5.3
libogg-1.3.3
libpng-1.6.34
libtheora-1.1.1a
libvorbis-1.3.5
mapm from git
physfs-3.0.1
zlib-1.2.11

EDIT

Since I forgot the demos, I thought I would take a second look, and some dlls were in the wrong folder. I have since rebuilt the dynamic libraries and the demos and included them in a new version of the binaries. I also fixed a broken section in the chm manual. You can get them all here :

Allegro524_MinGW64_GCC72_posix_dwarf_v2.7z

Go to: