Sometime around midnight I started down the road of drawing text using Allegro. It has been a few years since I last used a draw text routine and it was time to see my efforts to get better 4K monitor support was feasible. I ran into a few difficulties as I was linking the Allegro 5 library into my application in a modular way. The issue revolved around link-time symbols for the FreeType library. I quickly compiled a version of the FreeType library I had downloaded earlier and added that as an input into the linker. No good. I began to recognize my fatigue as I gave cmake another spin. I went to sleep around 1 AM … ish and decided to address it later.
I woke up hours later and was ready to re-engage the process from a fresh disposition. I looked more closely at the CMake options and decided to uncheck the box for share libraries and check the box for monolith library. I did the later hours before but realized I didn’t notice the former. After the adjustments, the monolith library would build without error.
Building Allegro 5 Library
The following is the basic output from the build system as it assembles the Allegro 5 library in binary form for me to incorporate into my application. In this case, instead of making 5 or 6 separate modules, I decided to merge them all into 1 library file as my preference in this situation.
After a make install … the library was in a state to use as input into my makefile. The following is the initial result of a successful integration of Allegro 5 with my software application structure.
The following is my revised makefile that I use to build my application. If you compare this to the version from the previous article on the topic of Allegro 5, you’ll see the addition of the dlib library as well. I decided not to hand roll my own geometry (even though my earlier version seemed quite efficient) and use a library that may shorten the overall code and make the core intent at the application level more clear.
Drawing 1 Line of Text
A single line of text around 7:25 am. As small an improvement as this seems, it gave reason to consider that the Allegro 5 library will work the purposes I explained in an earlier article.
Updated Application Level Windowing Abstraction
I got back into this around 7 PM. After a couple of minutes, I got more lines of text to display from a batch of text I had set to auto-generate. This is how that looks when I resize the window.
What Happened to the Scrollbar Areas
The previous article mentioned scrollbars. It was precisely for that reason, I decided to bring in the dlib library. When you draw text with a manually crafted scrollbar, you need a good, consistent way to address scrolling while minimizing repetitive code. Some of the improvements I’ve made starts with the header file for the PrimaryDisplaySurfaceWindow.
You may notice that I manually calculate the screen dpi based on descriptions I found on Wikipedia. The formula works quite well. My first version started with the sqrt function but I noticed the hypot function and reasoned that it has a better chance of being optimized beyond my use of intermediate variables. I cache the result of the dpi calculation.
The implementation of PrimaryDisplayWindowSurface received a little polishing compared to previous versions. The code below does no work in sending visual data to the screen. The focus of the module is to gather event data from keyboard, mouse, touch screen, etc., as well as recognize environment changes such as screen width and height. More work is needed on this front, but the foundation is laid for expansion.
The Application Level
Below is the same window from earlier, but I’ve grabbed hold of one corner of the window and resized it. You may notice that as I resize the window, the text automatically clips at the boundaries of the graphical regions in which the text is output. As you will see much further down, that is code I put in to do the clipping. I do that in a coarse way now, but with the dlib library, I should have a good mechanism to do this in a more sophisticated way.
The following is the GUI at the end-user level. The code for the application level GUI is divided into separate areas of responsibility. Data Model, Visual Model, Interaction Model, and Visual Output. Near the bottom of the module are the actual calls to Allegro to draw text, lines, and colors on the screen. Allegro has evolved well in the past 3 years and I am finding it quite productive to use.