EDITED 05/05/2017
Hey everybody,
Just finished my build of Allegro 5.2.2 for MinGW 5.3.0.3. Sorry it took so long. There were issues with DirectX and other things that slowed me down.
Get your MinGW 5.3.0.3 here :
https://sourceforge.net/projects/unofficialmingw/files/MinGW5302v3.tar.7z/download
Get Allegro 5.2.2 here :
https://sourceforge.net/projects/unofficialallegro5distribution/files/Allegro522_MinGW5303.tar.7z/download (Bug in PhysFS, don't download)
Fixed version of 5.2.2 with PhysFS 2.0.3 patch applied :
And for classic Allegro users, here's the link to Allegro 4.4.3 :
There will be a new version of MinGW coming out soon with new releases for the mingwrt and win32api packages. I'll upload it as soon as it's ready. It will still be compatible with 5.3.0.3.
The binaries for Allegro 5.2.2 come with both html and chm docs, as well as all the dependent libraries allegro needs for full functionality. Included are DUMB, FLAC, enet, PhysFS, Ogg, Vorbis, Theora, Freetype2, TurboJpeg, LibPNG, and Zlib. Headers and libraries included. All of the examples are included as dynamic debugging executables. All three demos are included.
In the main directory of the distribution you'll find a .bat file that will set up your environment to run the examples, test program, and demos that come with it.
Happy trails!!!
Edgar
]]>Wow! Thank you for providing these, Edgar!
]]>Thanks again for the updated CHM docs. Still the best reference format!
]]>Thanks for the work.
Is there any binaries for Android?
I myself can build for MingW but am still stuck with Android build...
]]>There is a repository for Android binaries, take a look here:
]]> There is a repository for Android binaries, take a look here:
https://github.com/liballeg/android
Thank.
It requires Android Studio, Java, and Maven?
Is there any way to use pure JNI (pure C++) to compile an Allegro rided Android application?
I've ever tried SFML Android, it doesn't require those tools, and I can just use Android.mk to build SFML itself and also my game, though it's Android support not quite good.
Going the Android Studio way is probably easiest.
Building from the command-line is more involved. It requires ant and I'm not even 100% sure it can be done on Windows. For Linux, there is an (somewhat outdated) article on the wiki here: https://wiki.allegro.cc/index.php?title=Running_Allegro_applications_on_Android
You'll always need Java, the Android SDK plus the NDK for Android C/C++ development.
]]>Google deprecated the old NDK tools, so instead of Ant and ndk-build you now use Gradle and CMake. You do not need Android Studio at all, the steps will basically be identical without it. Just when the instructions say:
Android Studio will create these files in your new project's folder (among others):
app/src/main/java/.../MainActivity.java
app/src/main/cpp/native-lib.cpp
app/build.gradle
app/CMakeLists.txt
Create those files yourself instead
]]>I had someone ask me how I produced the binaries. Step by step, here is how I did it.
0. Install MinGW, CMake, the June 2010 DXSDK and Git.
0a. Build dependencies for Allegro. Most build with cmake, but some like ogg, flac, vorbis, and theora need MSYS to build.
0b. Download sal.h from liballeg.org. This is necessary for compatibility with the DXSDK, which searches for sal.h. Get it here :
http://download.gna.org/allegro/files/sal.h
(This will change soon, as gna.org is closing down).
1. Clone Allegro 5 from Git. Here is the URL :
https://github.com/liballeg/allegro5.git
2. Unpack allegro.
3. cd allegro
4. mkdir build
5. cd build
6. cmake-gui ..
7. Press configure and select Mingw native compilers.
8. Edit CMakeCache.txt and find the line that says HAVE_STRERROR_S=1. Delete the one and leave the right hand side empty. This step is for users of the mingwrt version 3 and below. This won't be necessary once mingwrt 5 is released, as strerror_r and strerror_s are included.
9. Go back to cmake-gui and configure all the dependencies, making sure all the directories are right. Options I selected are SHARED and WANT_MONOLITH as well as the Build type which is either [Debug | Release | RelWithDebInfo | Profile]. (Tip, don't build the docs in profile mode, they take forever and hang).
10. Press generate in cmake-gui once you have your options configured.
11. Go back to the command line, making sure mingw/bin is on your path and type 'mingw32-make' and 'mingw32-make install' and it should build everything. Don't worry about the warnings. Most of them are from building as C90 instead of C99.
12. Repeat steps 9 through 11 as needed for each different build configuration desired.
If you have any problems, post here and I will try to help.
]]>Nice work as always! Thanks.
I'm curious, which MinGW do you use? That is, where did you download it?
The Allegro version being reported by this Allegro is 5.2.3 by the way. (deja vu... didn't we have this happen before?)
]]>It's because I built Allegro from GIT. That's why it says v5.2.3. Are you having compatibility issues again?
I download MinGW exclusively from Sourceforge and unpack each archive into a master mingw folder. Once all the components are together, I tar and 7zip them. Of course I add in GDB, grep, and diff for convenience. I use the latest available versions of each package.
]]>It's because I built Allegro from GIT. That's why it says v5.2.3. Are you having compatibility issues again?
Good memory, I forgot about that, but nope. Just to test this for you, I done clean compiles of my Deluxe Pacman 2 game (Allegro 5) and had zero issues (just the wrong version, which only shows up in my debug info). I done a clean compile on my Deluxe Pacman 1 game as well with your Allegro 4 libs you also linked to and also no issues.
All in all, seems like a successful build. Many thanks, and God bless for your efforts.
I download MinGW exclusively from Sourceforge and unpack each archive into a master mingw folder. Once all the components are together, I tar and 7zip them. Of course I add in GDB, grep, and diff for convenience. I use the latest available versions of each package.
Good to know. There's a few MinGW builds out there so I was curious which you went with. Thanks.
Edit: Oh, and the compatibility issues I had the last time, I believe were my fault in the first place for mixing up versions. I am more careful about that now.
Edit2: I tried out another Allegro 5.2.2 build for MinGW 6.2.0, 32 and 64 bit versions, got compile errors galore so... sticking to Edgar's build. Just so you know.
]]>Good memory, I forgot about that, but nope. Just to test this for you, I done clean compiles of my Deluxe Pacman 2 game (Allegro 5) and had zero issues (just the wrong version, which only shows up in my debug info). I done a clean compile on my Deluxe Pacman 1 game as well with your Allegro 4 libs you also linked to and also no issues.
All in all, seems like a successful build. Many thanks, and God bless for your efforts.
Edit2: I tried out another Allegro 5.2.2 build for MinGW 6.2.0, 32 and 64 bit versions, got compile errors galore so... sticking to Edgar's build. Just so you know.
That's what they're there for. Did you try out the MSYS2 Build of MinGW-w64? Are those the binaries you're talking about?
]]>That's what they're there for. Did you try out the MSYS2 Build of MinGW-w64? Are those the binaries you're talking about?
Yeah, I tried the setup from https://www.allegro.cc/forums/thread/616753 and it didn't work.
I now have a new problem. I don't know if it is related to me trying that other build out or not but now when I run my Deluxe Pacman 2 game, after doing a clean build with your library, it compiles okay, but it won't load in any of the Truetype Fonts. I have them stored in a PAK file (ZIP) I access using physfs. I have other files in there that are loaded in okay, BMP fonts I also have. But the TTF give errors.
I tried hiding the folder that I normally put Allegro into (a separate folder than my MinGW install). I put ONLY your build files into the MinGW32 directory directly (normally I don't do that, so nothing else is in there, it's the same MinGW32 you provided as well) but still a no go. So... perhaps this was a problem that was already in your build that i somehow missed?
The thing is, I haven't been programming my game AT ALL... so I haven't changed anything. I even went over the link order of the libraries and made certain they are in the order you listed (note: physfs was not listed in the libs you mentioned, nor was dsound, though they were needed to compile).
I haven't tried reverting back to an older build of yours yet, but I may soon if there is nothing else I can do.
EDIT: I just recompiled using your Allegro 5.2.1 build you released before this and it compiled and ran fine. This one compiles fine, but won't load TTF. BMP fonts loaded and displayed fine.
]]>Can you load a TTF file fine outside of your game or outside of your pack file? Try ex_ttf and ex_font and see what they do for you. Run the batch file inside of the main allegro 5.2.X folder and then run both of those example programs and tell me if they work for you. Have you copied the dlls properly into the packman executable?
]]>The game works perfectly with Allegro 5.2.1. And my game is statically linked. It isn't physfs or the BMP fonts would not load either, but they do. And if it was my setup, Allegro 5.2.1 wouldn't work either.
]]>I looked at the change logs for 5.2.X and I didn't see much to do with the ttf addon except for some pre-rendering caching routines for Android.
Like I said, does ex_ttf or ex_font or ex_physfs work for you? I provided them with the examples. Just run that batch script and then run the examples from the command line.
]]>Like I said, does ex_ttf or ex_font or ex_physfs work for you? I provided them with the examples. Just run that batch script and then run the examples from the command line.
Sorry, I just tested them all. All work except ex_physfs. It doesn't work. I tested the same ones with your older 5.2.1 build and they all work (including physfs) with it. So the problem appears to be with physfs. Which still seems strange as my bitmap font loads with physfs but not the ttf. That should help narrow the problem down anyhow.
It kind of bugs me that there is no error message when ex_physfs fails at all.
]]>I used PhysFS 2.0.3 in my build. Can you provide a debugging build of your program? Link to the static debugging monolith instead? Either it's failing to load the ttf, or it's failing to find the ttf inside the zip.
Can you do a short example program that fails? Like with a test font inside a pack file you open with physfs? That way I could test it on my own computer.
]]>I always build my debug version with the debug version of the library. But I compile using what you provided.
Actually, I just realized I can attach the allegro.log here for you to examine. I just deleted it, then recompiled and reran it so this log is fresh.
I'll attach it to this.
I noticed the following line in that log...
font E C:\LIBS5303Build\allegro5\addons\ttf\ttf.c:891 al_load_ttf_font_stretch_f [ 3.17001] Reading Fonts/Verdana_Bold.ttf failed. Freetype error code 85
edit: I noticed someone else had a similar problem years ago, but they had no response to their post and I don't know if they ever got it resolved.
]]>That comes up as :
FT_ERRORDEF_( Divide_By_Zero, 0x85,
"division by zero" )
Can you try replacing it with your system font for VerdanaBold? Where did you get it from? Can you try loading your Verdana_Bold outside of physfs? Can you upload your font here so I can play with it?
Can you replace your old copy in the zip file with a fresh copy of the font? Wherever you got it from???
]]>Can you try replacing it with your system font for VerdanaBold? Where did you get it from? Can you try loading your Verdana_Bold outside of physfs? Can you upload your font here so I can play with it?
Can you replace your old copy in the zip file with a fresh copy of the font? Wherever you got it from???
1) Replaced verdana bold with a new copy of it from the same source, even changed the filename. Same problem.
2) Tried loading the font from outside the ZIP file, from a normal folder and it loaded no problem. The very next font that tried to load from the ZIP file failed, a totally different font. Also note that I successfully loaded a BMP font from the same ZIP file without problems.
3) It's not just THIS font, it's ANY TTF. I tried a totally different TTF. They load fine from a normal folder, they do not load from the ZIP. Yet Allegro 5.2.1 loads them just fine from all locations. I ONLY compile with the libraries YOU supplied each time, with the same compiler you supplied. The program is compiled with the exact same settings each time, both with Allegro 5.2.1 and with the version in this forum. Yet I have zero problems with 5.2.1, so something changed between versions.
Also, note my previous message where someone had the exact same problem with the exact same divide by zero error back in 2014 (I linked the message) so this is nothing new I guess.
a) Which version of Freetype did you use for Allegro 5.2.1? Was it the same version this time, compiled the same way?
b) Which version of Physfs did you use with 5.2.1? Was it the same version this time?
I used Freetype 2.7.1 and PhysFS 2.0.3 along with Allegro 5.2.3 from GIT after the 5.2.2 source release.
You say it won't load from a zip file. Have you set the correct interface? There are two.
]]>You say it won't load from a zip file. Have you set the correct interface? There are two.
Here's a snippet of code;
I added in comments. Everything else I load from the ZIP file loads just fine. I load in a special bitmap font from the ZIP file without problems, it's what you see when you see "Loading..." when you run the game, it displays no problem. ONLY the TTFs will not load from the ZIP.
Oh, and those are mainly just fonts I think I grabbed from the Windows/fonts folder. I have since been using GNU Free fonts for newer projects (http://ftp.gnu.org/gnu/freefont/).
And obviously I got the interface right or how would it have worked fine with Allegro 5.2.1?! Seriously, this is NOT on my end. Nothing changed other than me recompiling with the newest version, and I recompiled with the compiler you supplied and the libraries you supplied only. Otherwise, there was no change. As I said, it worked before. And the example physfs program doesn't work and I didn't have anything to do with compiling that. That alone should prove it is not on my end.
I'm not concerned anyhow. I'll stick with using 5.2.1.
]]>Off-topic: whose smart idea was ".tar.7z"? 7z archives can contain directories. No need for a tarball. Worse yet, the 7z utilities aren't smart enough to extract a tarball automatically so you have to extract them twice. It looks like MinGW is doing this, which is probably dumb, but maybe there's a good reason for it. Otherwise, there's no reason at least you could skip the tarball and spare the user some senseless fuss.
]]>No, that was my idea. tarring helps when you combine it with 7z. It makes for a much smaller archive than if you just 7z it straight from the beginning.
Neil,
The only difference between the 5.2.1.1 binaries and these is FreeType 2.6.5 instead of 2.7.1 in the newer version. The version of PhysFS used is the same, 2.0.3.
Can you provide a small demo program that shows what is wrong? That fails to load a ttf from an archive?
]]>I guess the other reason is that tarballs preserve Unix permissions, but that probably doesn't apply to you. I wonder how .tar.xz compares to .tar.7z. I imagine MinGW must have xz by now... Though I guess that's chicken and egg for MinGW itself.
]]>Can you provide a small demo program that shows what is wrong? That fails to load a ttf from an archive?
Sure, just grab your physfs example you compiled. It fails. No need for one from me. I'm done with this. My next project will use SDL2.
I won't sit here playing twenty questions when I already showed that it worked with 5.2.1, and it doesn't work with this. I have changed NONE of my code... can you understand English?! IT WORKED BEFORE... IT DOESN'T WORK NOW... the ONLY thing that has changed is the Allegro version. I even used the compiler YOU provided.
If it was MY CODE, it would NEVER have worked. Download my Deluxe Pacman 2 game in the link in my signature. That is 5.2.1, and you will see it loads the fonts and uses them no problems with physfs. 5.2.2 (5.2.3GIT) here... will not.
This exact same problem came up 3 years ago in 2014 with someone else (I provided a link to their message earlier here). And they had the same problem, same error, same divide by zero or whatever... so obviously this is nothing new.
If you REALLY need an example, it's easy, make a zip, put a TTF into it, try and load the TTF using Allegro, loading the TTF from the ZIP with this version.
]]>Have a little patience with me Neil?
I'm not in any way accusing you of it being your fault.
I'm trying to narrow down the cause so I can fix it. The allegro version is not the only thing that changed. The freetype version changed also. It could be a bug in either library. There's not much you can screw up when compiling physfs or freetype, except which libpng you (choose to) use.
I've never used physfs before. I don't know why it would be failing to find the file within the archive, but it is, or it is mangling the file when reading it. That in turn depends on zlib.
So you can see, there's quite a few things that could go wrong.
I'll try to make an example to test this, but I don't have a lot of free time right now. :/
]]>If you scroll up, I have had patience. But there are no other answers I can give you. I compiled it with Allegro 5.2.1 and it works fine. I compiled it with this Allegro, and it will not load. I have had ZERO code change in my own game code as I don't work on that game anymore except to update it with newer versions of Allegro.
When I recompiled it, I recompiled it with the MinGW compiler you provided. I totally delete my old compiler folder and replace it entirely with yours. I have my libraries in a separate folder, so it wasn't corrupted somehow either.
The only libraries I use with this is Allegro. The only PNG I use is whatever comes with Allegro.
And as I already stated, the physfs example you compiled in the examples folder doesn't work. So, no need to really make something else, you already have something that fails in your example folder. That was not compiled by me at all, but it fails, so that is probably the best place to look.
My apologies but... when I get continually asked what I did wrong, or differently when I did nothing wrong, I get a little annoyed. I've told you all I can. I use the library properly, Lord knows I have enough experience with it and the problems. I am very careful to check everything and to report all errors, even where none are probable.
SOMETHING was changed between Allegro 5.2.1 and this one to do with Freetype and Phyfs. That's where I would look. Perhaps switch back to any older versions you used and recompile that physfs example with it and I would be happy to test it out. But... there's not much more I can do on my end.
]]>Bumping the thread to give me more time to investigate this.
An older version of zlib may fix this.
EDIT
Actually, the version of zlib used in the 5.2.1.1 build was 1.2.8 where the version of zlib used in the 5.2.3 build is 1.2.11. That might be the problem.
EDIT2
Todd Cope tried it with zlib 1.2.8 and it didn't work for him either, so I think it must be Allegro somehow.
Follow my explorations of the bug here :
https://www.allegro.cc/forums/thread/616847
EDIT3
From a reply on the mailing list, there's a known bug in PhysFS 2.0.3 when it uses zlib 1.2.11. Objects fail to load from inside the zip file. There is a patch for it here :
PhysFS 2.0.3 patch for zlib 1.2.11
I have also attached the patch for posterity in case the download link ever goes down :
Download patch here
Neil,
I will make new binaries soon.
Edgar
EDIT4
New binaries are available. Please download the new ones with the physfs fix applied.
]]>Nice work Edgar :-)
]]>New binaries are available. Please download the new ones with the physfs fix applied.
Wow, I have to give you credit. You have far more patience than I do.
I'll check that out. Thanks.
Edit: Recompiled my Deluxe Pacman 2 game with this and it now works fine. I'll probably make up some new levels for my game and then upload a newer version compiled with Allegro 5.2.3 later on today. Great work!
Edit2: The new version of my game, updated with your new version of Allegro (plus 10 new levels ) is now available for download (at the link in my sig) if you're curious.
]]>{"name":"c4e922ca818caa4dd2e2f818e4169050_aww-crying-face-awwww-awww-meme_400-400.jpeg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e6ab006bd617595f7e65f24f3dc6954.jpg","w":400,"h":400,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/7\/e\/7e6ab006bd617595f7e65f24f3dc6954"}
]]>SCRATCH THAT. It works.
]]>{"name":"awkward-meme.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/7\/07633931745ab55bc91f1da58f41ccce.jpg","w":400,"h":400,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/0\/7\/07633931745ab55bc91f1da58f41ccce"}
]]>Okay, fixed the problem. It works. WHEW!
The problem THIS TIME was in the following line:
font_verdana = al_load_ttf_font("pak/Fonts/verdanab.ttf", 18, 0);
the path had "pak/" in there, which is the path of my folder outside the zip, I forgot to change it back to the zip (which doesn't have "pak/" in there. I had changed it while trying to figure out this problem with the last compile you did, to see if it would load outside of the ZIP but forgot to change it back with this compile.
Ah well, it was worth it just to make bamccaig feel awkward.
]]>Fantastic work, Edgar!
]]>{"name":"610881","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/4\/e4ac1659ca690c44f5dc7478064beb48.png","w":1920,"h":1080,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/4\/e4ac1659ca690c44f5dc7478064beb48"}
Credit for the expression[1] goes to my fianceƩ. She recently commented on the magical giraffe that was recently born. I don't have social media accounts because I think it's harmful to give so much information to corporations, but I digress. I don't know much about it, other than the birth was apparently due for a ridiculous amount of time. My understanding was that the mother was in labor for weeks or months. Again, I don't care or follow this shit so I might be mistaken, but that was the impression I got from how stupid people were about it.
All that aside, my finaceƩ announce it to me excited when it happened. At this point, from the hype, and what I imagined was the timeline, I figured it might have been different giraffes and just a big gimmick. I told her, "It's probably a different giraffe!" She quipped back without missing a beat, "you're a different giraffe!" So now I'm trying to make it stick. Pass it on.
The image is random and not attached to the saying. Feel free to make a better one if you want to share it as a meme.
bamccaig, quit barfing on my thread
Again, the link for the new binaries is at :
Thanks Neil for testing them.
]]>Thank you very much, it all works pretty well for me. Before, I was staying with mingW 4.6.2 for so many years because other versions had bugs, so it was good to get a new version that was not crazy. I put it next to my other MingWs in the directory C:\MingWEdgar .
Since then I rebuilt my version of HGE with the new MingW, then implemented hgeSprite (renamed bgeSprite) in Allegro. Someone had told me a long time back that Allegro would be a good option to develop HGE because of its multi-platform capability, and after looking around a bit, I agree, mostly because all of the transforms are there. So I could create an HGE-like functionality in Allegro whether or not it is a full engine.
Oh yeah, I forgot about the batch rendering/VBOs that Allegro calls deferred rendering. That is also a must for an HGE-like functionality.
Sorry for the long post and HGE and again, thank you.
]]>Thank you for using them byorn54. What I really need is people to test the distribution for me. Sometime soon mingwrt5 will come out and I will update MinGW. The allegro binaries will still be compatible though.
]]>