Allegro.cc - Online Community

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

This thread is locked; no one can reply to it. rss feed Print
 1   2   3   4 
Allegro 5.2.0 released!
bamccaig
Member #7,536
July 2006
avatar

Allegro is compatible with MinGW and Visual Studio 2012. The only hard part about building is satisfying the dependencies. If no existing binaries exist for your toolchain then you have to rebuild them all.

That means every library that Allegro depends on to give you graphics file loading, audio file loading, etc., needs to be built for your toolchain first (unless you can find binaries for that). And recursively you need to satisfy their dependencies first. For example, if Allegro needs libabc then you need to build that first, but if libabc requires libmln and libxyz then you have to first build libmln and libxyz, then libabc, and then finally Allegro! But that's a simplified model. There are probably close to 10 dependencies for Allegro, and I have no idea how deep the recursive dependency graph goes...

Only once you've recursively built (or sourced) binaries for all dependencies for Allegro can you actually build Allegro and then start making your games... If binaries exist for your toolchain then it Just Works(tm) and you can get started. That's the ideal case. But we don't have the resources to provide binaries for all possible configurations... And I'm not sure if all of the ones we do have are organized anywhere.

If it isn't the case that binaries exist then it's a chore to get Allegro building that only the most motivated users or developers undertake. In Linux most of this trouble is eliminated because the distribution package repositories already have compatible binaries for the dependencies, and several of the most popular distros also have packages for Allegro itself...

CMake itself, the build system being used for Allegro, will do its best to configure itself to build even if you are lacking dependencies... But if dependencies are missing then it will disable features of the library to the point of building a useless library that can't do what you need it to. You basically need all of the dependencies satisfied or you'll be annoyed later when your game won't run because Allegro doesn't support loading PNG files or something.

CodeDmitry
Member #16,341
May 2016

That sounds reasonable other than having to be done via CMake. I have no idea what toolchain means nor how to use all the CMake features, so it's a lot more steep of learning curve than a simpler build structure.

It's not as straightforward as photoshop signature tutorials (which also skip steps occasionally)

Polybios
Member #12,293
October 2010

Try using msys2. You can install most of the dependencies via pacman. There are also official packages for it. Once you have it set up, it's as trivial as on Linux.

bamccaig
Member #7,536
July 2006
avatar

CMake it essentially used to generate your own toolchain's build scripts. This includes generating Visual Studio project (/solution?) files. I agree, it's a frustrating learning curve to have to learn, but on the other hand without it there might not be Visual Studio support at all so it might be a saving grace for you...

The good news is that there isn't much that you need to do with CMake. Install it, fire it up, and tell it to build. There is also a GUI variant called ccmake which I imagine will be added to your Start Menu by the installer... However, the real hurdle is satisfying the dependencies which CMake does not help with (if anything, it makes matters worse by implicitly letting the build succeed without them).

A "toolchain" just refers to the set of programs that you use in software development to produce a build. In general, this means your compiler, linker, etc., but could also mean other tools needed to complete the pipeline. Binaries are sometimes only compatible with the toolchain, the compiler/linker versions, that built them, as is the case in Windows. An IDE muddies the waters for what constitutes a toolchain, which is probably why you haven't encountered the terminology before, but nevertheless one might consider your toolchain to be "Visual Studio n" (meaning all of the underlying infrastructure hidden under the surface that that implies).

If binaries exist for your version of Visual Studio and desired version of Allegro then you just need to install those and you'll be fine. If not then you will need to go through the pain to build Allegro described above...

CodeDmitry
Member #16,341
May 2016

I'll try again later. My issue is it's hard to read feedback from CMake to see where is goes wrong since it continues past many warnings and many are supposedly not indicative of anything being wrong.

The overall experience so far reminds me of trying to build Minix... took a while.

Michael Branin
Member #15,864
January 2015

Is there a way to get the source and the dependancies to build for visual studio using the cmake? I like the new version of Nuget but My school prefers the old way. Using cmake and building the binaries for Visual Studio.

MiquelFire
Member #3,110
January 2003
avatar

Dependencies are a crapshoot with building with CMake. Not all of them even support CMake. Hell, I'm amazed that people can build them with the newest MSVC due to how they're unix first (to the point that it should be unix only)

---
Febreze (and other air fresheners actually) is just below perfumes/colognes, and that's just below dead skunks in terms of smells that offend my nose.
MiquelFire.red | +Me
Windows 8 is a toned, stylish, polished professional athlete. But it’s wearing clown makeup, and that creates a serious image problem. ~PCWorld Article

SiegeLord
Member #7,827
October 2006
avatar

For the official windows binaries I created CMake-based build systems for all of Allegro dependencies. I highly recommend using them and the associated scripts to build Allegro if you need to do it yourself. It might be easy enough to adapt to an older MSVC version too:

https://github.com/liballeg/allegro_winpkg
https://github.com/liballeg/allegro_winpkg/blob/master/universal/README_msvc.txt

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

Michael Branin
Member #15,864
January 2015

Thank you SiegeLord. Using that link I was able to compile it for MSVC 2013 and 2015

pmprog
Member #11,579
January 2010

Nice work!

Whilst OpenApocalypse moved to SDL2 (I'm not as involved these days), I still prefer Allegro for all my dev needs.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Michael Branin
Member #15,864
January 2015

Yours are not for MSVC correct?

Edgar Reynaldo
Member #8,592
May 2007
avatar

Ariesnl
Member #2,902
November 2002
avatar

Very nice!
I'll take a deeper look at it when I have the time.
Keep up the good work.

@ Edgar Reynaldo.. thanks.. exactly what I'll need in the future.

Perhaps one day we will find that the human factor is more complicated than space and time
(Jean luc Picard)

Mark Oates
Member #1,146
March 2001
avatar

In case anyone was using the binaries I provided (NeilRoy) I repackaged it due to the possibility of older versions having snuck into the distro. Redownload from the link provided.

https://sourceforge.net/projects/unofficialallegro5distribution/files/A52GITdistro2.tar.7z/download

It WORKS!! :D:D:D

Publishing a binary of my TINS entry soon. ;D

Neil Roy
Member #2,229
April 2002

I compiled a debug version, and it worked fine for my game, but my level editor crashed, which is really strange, and I'll explain why...

First off, the point where it crashed...

#0 0041DF5E	al_install_keyboard() (C:\LIBS\A5GIT\allegro5\src\keybdnu.c:133)
#1 00405388	main(argc=1, argv=0xb518a8) (C:\Develop\Projects\Deluxe_Pacman_2\p2_main.c:99)

Line 99 in my level editor is this...

I don't know what the line is in the allegro source, I don't have that. But as you can see, it shouldn't be crashing here for me. It never returns from the install function, but crashes with a seg fault inside of it.

The strange thing is, I also compiled my game (which is a separate compile) and it ran fine in debug mode, yet it initializes the keyboard as well. Both compiles on my level editor and my game were clean compiles by the way.

I haven't tested the release version yet, I'm about to and will post below...

Okay, I just tried to compile my main game in release mode and still getting a segmentation fault when I try to run it. Doesn't even open up a window. Yet it compiled and ran fine in debug mode. Same as last time, very strange. I wonder if is related to the level editor failing in the keyboard init function?

Note, nothing is changed in my game, it compiles and runs flawlessly with previous versions you released of Allegro 5. This is the only one it fails with. And I made certain to add in dsound to the libraries linked (still needed that).

Edit: Okay, I changed release mode so it compiles with a console, then added some printf()s and sure enough, it is crashing inside the keyboard init, as I suspected. But it only crashes there in release mode, not in debug mode for my game. My level editor seems to crash there in debug and release.

Ariesnl
Member #2,902
November 2002
avatar

Segmentationfaults can be caused by anything in the code before. Doublecheck your code. Use valgrind, it will probably generate a lot of (false ?) errors within Allegro.And it doesn't like switching ownership of objects eigther. But when you skip those, what remains should be the problem.
I had such a problem some weeks ago with my startrek game. I was reading beyond some array when I refactored from #defines to enums. I forgot to remove a number of loaded sounds and use an enum sentinel instead.
Resulting in an segmentation fault in my communication module. But only in the release version. In the debug version some ships where cloaking the wrong way, without any error !

Perhaps one day we will find that the human factor is more complicated than space and time
(Jean luc Picard)

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil Roy, double check that you've re-copied the appropriate dlls into your game folder. Sometimes that causes segmentation faults in allegro startup functions. I will look at line 133. It would only crash if the system driver had not been init'ed. So check al_init. It's probably a version mismatch error that is preventing allegro from being inited properly.

The lines of code cited are from the compiler's point of view, not yours. So they point to the source I compiled the library from.

Neil Roy
Member #2,229
April 2002

Ariesnl said:

I had such a problem some weeks ago with my startrek game. I was reading beyond some array when I refactored from #defines to enums. I forgot to remove a number of loaded sounds and use an enum sentinel instead.

I would agree if I had been working on my game at all since I installed the new version of Allegro, but I have not. At all. I only load it and recompile for new versions or bugs, otherwise I haven't done much with it lately. The game compiles and runs fine, to see it, just click the link at the bottom of this message, download and install "Deluxe Pacman 2", the version available now is from 5.1.13. Just before this. I compiled that exact same code, no changes what so ever and it has a fault, one that does not exist in the previous Allegro code. So something in 5.20 has changed.

Neil Roy, double check that you've re-copied the appropriate dlls into your game folder. Sometimes that causes segmentation faults in allegro startup functions. I will look at line 133. It would only crash if the system driver had not been init'ed. So check al_init. It's probably a version mismatch error that is preventing allegro from being inited properly.

It's statically linked. There are no DLLs needed. I did note that the version is still reported as 5.1.13 instead of 5.20. Otherwise, if it was in my code, it would not work at all for any version. But the last version, 5.1.13 works fine.

If it is a version mismatch, than it is with the newer version as it reports 5.1.13 still.

In any event, I'll switch back to 5.1.13 which works.

Edit: Here's the code my game runs before it crashes. Not much, it starts in main, a couple variables are declared (nothing fantastic, ints, floats the usual)...

dp2_main.c

#SelectExpand
1int main(int argc, char *argv[]) 2{ 3 bool redraw = false; 4 bool pressed_key[ALLEGRO_KEY_MAX]; 5 double start_time; 6 char levelname[TEXT_BUFFER] = ""; 7 bool player_found = false; 8 bool scared_ghost = false; 9 int players = 0; 10 int cplayer = 0; 11 bool skip_level = false; 12 ALLEGRO_SAMPLE_ID back1, back2; 13 int backplay, oldbackplay; 14 float pitch; 15 int jump; // new level to jump to 16 17 initialize();

...it then immediately jumps to an initialize function which does the following...

initialize() function;

#SelectExpand
1static void initialize(void) 2{ 3 char s[TEXT_BUFFER] = ""; 4 5 al_init(); 6 7 uint32_t version = al_get_allegro_version(); 8 unsigned char major = version >> 24; 9 unsigned char minor = (version >> 16) & 255; 10 unsigned char revision = (version >> 8) & 255; 11 12 // print C version in console 13 printf("C version: %lu\n", __STDC_VERSION__); 14 printf("Allegro version: %i.%i.%i\n", major, minor, revision); 15 16 al_init_image_addon(); 17 printf("Image addon installed\n"); 18 al_init_primitives_addon(); 19 printf("Primitives addon installed\n"); 20 al_init_font_addon(); 21 printf("font addon installed\n"); 22 al_init_ttf_addon(); 23 printf("TTF addon installed\n"); 24 al_install_keyboard(); /// << Crashes inside this function

That's it! You see ALL the code my game runs up until the crash, this is all of it. It is compiled with a C compiler, with MinGW (the version Edgar provides as a download) as a staticly linked compile, no DLLs. As you can see, not much going on in my game up until this point, and all of this runs fine with 5.1.13.

Edit2: I just noticed something when testing this again... the release version which crashes reports Allegro version: 5.2.1 where as the debug version which does not crash reports Allegro version: 5.1.13! Now I done a clean compile for both, I even manually deleted ALL the old Allegro 5.1 files as well as manually deleted all the object files, just to be certain before compiling... so...

Edgar Reynaldo
Member #8,592
May 2007
avatar

You're not checking return values. al_init could fail, and that could be the reason al_install_keyboard is failing. Are you sure you're linking ONLY to the new libs?

I will try your code here in a bit and see if it crashes for me.

EDIT
Neil, you in the code you posted you never call al_init(). It crashes for me too. :/

bamccaig
Member #7,536
July 2006
avatar

If al_install_keyboard crashes and there is no serious memory corruption going on then it's probably because al_init fails too. Make sure you check your return values (could more easily catch problems like this without resorting to a debugger)! This is beginner stuff!

Chris Katko
Member #1,881
January 2002
avatar

Why is initialize static?

[edit] Also, since this version mismatch issue seems to be a FAQ.

1 - I really think we need a FAQ wikipage. Is this the proper wiki?

https://wiki.allegro.cc/

2 - Is there a change we can make to force Allegro 5's headers to check whether the library is the right version on start-up? I've run into this issue a few times (debug vs release versions being different is a PITA!), including when I was trying to get DAlleg up and running.

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

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil Roy
Member #2,229
April 2002

Sorry, I haven't been working on it. My game runs just fine with older versions of the lib. Just not this one.

I'll try again with error checking code in there. I don't know why I don't have it honestly, I normally have it for all init functions. <shrug>

Okay, you're right, al_init() failed, and I think I understand why now.

al_init() basically calls: bool al_install_system(int version, int (*atexit_ptr)(void (*)(void)))

Well, look at what it calls! It passes in the VERSION... and as I have already pointed out, there is a version mismatch. It reports v5.1.13 for the debug version, and v5.2 for the release version, so my guess is that it passes in v5.2 in release which is cauing a problem somewhere. It would explain why 5.1.13 works fine for me, and the debug version of 5.2 works fine (it reports 5.1.13) but the release does not (it reports 5.2). In any event, the problem is not in my code (aside from not reporting the error). Actually, had I reported the error, I probably would have never found this problem as it would have ended before the version was reported, or whatever... <shrug>

Sorry I didn't reply sooner, but... just not working on this as much now. I would like to update it if possible but... 5.1.13 works, no problems, this does not.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Neil, did you remember to update your headers? Were you pointing to the right include directory? Because the headers were updated along with the library. That might explain why it is reporting as 5.1.13. In my headers for the distro it reports 5.2.1 as ALLEGRO_VERSION_INT in include\allegro5\base.h on lines 56-58.

If your debug version reports the wrong version, you may be using older headers somehow, perhaps by not updating your include path for the debug version.

My best guess.

Edgar.

Edit
Is there a detailed guide somewhere to setting up Allegro with MSVC 2015? I got as far as creating a solution, installing the allegro nuget package, and then trying to set relative include directories but I don't know what the base search directory is or whether you can even use relative include paths with MSVC. I want to make a portable solution to build my ManyMouse project with. Don't even get me started on how many warnings MSVC is throwing out at me. It's gonna take me days just to get them all sorted. Does the nuget package use .lib files for allegro? Or something else?

 1   2   3   4 


Go to: