The first time I wrote about the Allegro graphics library (see Build a C++ Cross Platform Program with Allegro) was Feb. 2013. I gave a walkthrough of building a basic application Window using Allegro on Microsoft Windows and Linux. Over time, I moved on from Allegro and explored SFML. As I clarified my goals more, I then embraced FLTK in which I completed a software application in C++ that uses FLTK, SQLite and Gnome Xml. All was well and I was looking forward to updating the program when the prospect of Hi-DPI became a reality. Higher resolution displays do not exactly prevent programs from running, but do pose productivity challenges.
I looked at the roadmap for FLTK and considered that it may be quite a ways out before version 2.0 arrives. I looked at the bug reports for FLTK 1.3.3 and realized that there may not be the kind of movement on Hi-DPI support that would be useful. I briefly made changes to the FLTK source code and decided that is not my path at this time. That began a brief journey of a few weeks in which I looked at various native graphics API.
I dusted off old books I had on OpenGl. Reviewed the status of C++14 support among various API. Examined some of the viewpoints out there for and against different API. After taking everything in, I saw that one API in particular seemed to quitely get a general nod of approval within the noise about graphics API. That was Allegro.
Allegro 5 Graphics Library
I was very familiar with Allegro a few years ago. A few days ago, I decided to give it a try and determine if things had improved from when I last used it. The problems I had with Allegro the last time around was in compiling it. I documented how to compile Allegro for various platforms in 2013 but I wanted a process that was more compact and to the point when creating a static library. At the time, the Allegro library was not easily inclined towards this approach. Today, it is … thankfully.
The other problem had to do with the way Allegro handled window creation. I found it uneven and oddly represented in some cases. I never expressed these misgivings until now, but I had some small trepidation about trying Allegro again given some of the issues with polish (that’s really what those issues are after all). I downloaded Allegro 5 (which I think was borderline unstable last time I tried it) and hoped for the best.
So far, I am pleasantly surprised. It works well. I still do not like the reliance on CMake for the build. I think a configure script is a smoother, more repeatable way to build API binaries from source, but CMake is a good alternative. Anyway, what really intrigued me about using Allegro is the various constructs in Allegro that improve productivity when creating a graphically detailed program. It is still more granular than FLTK, but I think it will do well once I evaluate its handling of fonts.
Compiling the Application
I put together a Makefile to compile the application I build with C++14 (compiler directives) and Allegro. The following Makefile is a minimum Makefile to build the source code shown further down. As you can see, my path to the Allegro library static binaries I emitted with CMake/make is a few levels up from where I keep source and make file. If you repeat this, it doesn’t matter where you put the Allegro 5 library static (or shared) binaries as long as the Makefile (and thus the compiler) can see them. All this for properly rendered fonts? Yes, it is worth it.
Allegro 5 Graphics Library Window – Initial Baseline
The following is source code I wrote from scratch on Nov. 1st and Nov. 2nd 2016. About 4 hours each day. I skipped today to write this article. Much of my progress is from muscle memory working with Allegro in the past, the Allegro PDF manual you can download from their website, and a little experience. I didn’t use the Internet or StackOverflow for the initial stages. Simply re-read the Allegro PDF manual and made progress. The main issue I had at first was in my use of al_draw_filled_rectangle. I read the documentation wrong and saw it as x1, x2, y1, y2. No idea why, but with 3 successive calls to al_draw_filled_rectangle, the first call produced the correct result but the other 3 did not. Those 3 calls did not look the way it does now, it was 3 separate lines. Maybe I was just tired (this was late evening), but I managed to remember points are x,y and after skimming the documentation a few more times, I finally read it right. After that, things came together properly.
After everything was done (with a little effort at optimization of the al_draw_filled_rectangle calls), I then decided I didn’t like the visual tearing I got when I resized the window. For that, I did look on the Web, and saw the consensus on StackOverflow regarding blitting and bitmap buffers. Since I am not using either of those directly, none of the StackOverflow solutions I came across (I only looked at 4 or 5 pages) was useful. I immediately went back to the approach I was taking in rendering. I decided to simply put another call to al_flip_display() on line 141 and that (combined with eliminating unnecessary display calls on line 195) fixed the main issue I had.
The code you see will not be the final version. Things are a bit rough in terms of style, clean-up, variable lifetimes, etc, but it is a basic starting point for anyone wanting a quick start with Allegro 5.
Result on Fedora 24 Linux under the Default Gnome Desktop
I begin by executing it directory from the same directory I build the executable. The executable is compiled with debug features so it is large for what it does, but you can change that easily in the Makefile. The I launch the program. While the program is running, I leave detail messages in the command-line window that helps with glancing some of the active values in the application. It is also a suitable environment to immediately launch gdb (which I had to do on a few occasions) and check out the root causes of error. Finally, the result of the effort described so far in just 8 hours split across 2 evenings (6 – 8 and then again 10is till midnight). More to come.