|
|
|
This thread is locked; no one can reply to it.
|
| Allegro 5.2.4 released! |
|
SiegeLord
Member #7,827
October 2006
 |
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"} 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
Raspberry Pi port
Android port
Linux port
OSX port
Audio addon
Font addon
Native dialog addon
Build system
Python binding
Lua binding
Documentation
Examples
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 |
|
Chris Katko
Member #1,881
January 2002
 |
Woo!!!!!! Thank you for your work. -----sig: |
|
GullRaDriel
Member #3,861
September 2003
 |
Good job. Thanks mate :-) "Code is like shit - it only smells if it is not yours" |
|
Edgar Reynaldo
Major Reynaldo
May 2007
 |
I see you already upgraded to 7.2.0. Very nice indeed. Have to say, that Allegro comic is kind of scary. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
Neil Roy
Member #2,229
April 2002
 |
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
|
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 |
|
Neil Roy
Member #2,229
April 2002
|
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
|
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 |
|
Neil Roy
Member #2,229
April 2002
|
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! <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"} 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. |
|
Neil Roy
Member #2,229
April 2002
|
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 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
|
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 |
|
Neil Roy
Member #2,229
April 2002
|
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
Major Reynaldo
May 2007
|
What is the official C standard for Allegro? I get tons of warnings when I compile the allegro examples. I want to get rid of them. My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
SiegeLord
Member #7,827
October 2006
|
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 |
|
Edgar Reynaldo
Major Reynaldo
May 2007
|
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? My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
SiegeLord
Member #7,827
October 2006
|
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 |
|
torhu
Member #2,727
September 2002
 |
Edgar Reynaldo said: 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 |
|
Neil Roy
Member #2,229
April 2002
|
Edgar Reynaldo said: "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! 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
 |
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. ----------------- |
|
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
 |
Showing my love guys!
|
|
Edgar Reynaldo
Major Reynaldo
May 2007
|
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 : My Website! | EAGLE GUI Library Demos | My Deviant Art Gallery | Spiraloid Preview | A4 FontMaker | Skyline! (Missile Defense) Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide |
|
|
