This post is a portion of Part 2 in my on going series about 2D Game Development using the Allegro 5 library. These posts are in course order. You can see all of the posts in this course by clicking the “2D Game Development” button at the top of this site.


We have talked about 2D graphics as a whole and about the screen object in particular, but none of that gets us up and running. Much of what we see here should be familiar. This is just to fill in the blanks a little bit. Before utilizing any part of Allegro, you must first initialize it. We achieve that with the command:

int al_init();

Once Allegro is initialized, we can begin using its various functions to build our games. One such function, allows us to create our display object. This object not only describe the attributes of our screen (such as width and height), but also acts as a handle that allows us to control how images are presented. Display objects are type: ALLEGRO_DISPLAY *

and are assigned with the function:

ALLEGRO_DISPLAY *al_create_display(int, int);

Finally, before we close our game out, we need to get rid of our display. If we forget to do this, the memory allocated to the object may not get freed up, and that is a big C++ oops. We destroy our display object with the function:

void al_destroy_display(ALLEGRO_DISPLAY *);

Double Buffering

If you have any experience working with other 2D programming environments, you may have heard of a term called “double buffering”. If you haven’t, here is a little background. Computers are not capable of drawing anything more complex than triangles. Luckily for us, all objects can be represented with a fair amount of accuracy using just triangles. For instance, a square is just two triangles set next to each other. The idea is that the screen is capable of drawing triangles so quickly, that the eye is tricked into seeing whole images at once. The problem is that a flickering can often be seen because these objects are being erased and redrawn right before your eyes, one at a time. The solution, called double buffering, is drawing all of our images to a hidden, virtual, “screen” which is otherwise known as the back buffer. Then, once all of the objects are drawn, the back buffer and the front buffer (the screen) are swapped (using high speed memory transfers). The effect is that the eye sees all of the objects at the same time and there is no flicker. You might be wondering why I am telling you all of this. Well the reason is that in the new Allegro 5.0, all of the heavy lifting of creating, maintaining, and utilizing a double buffer system is handled for you. You may remember the code lines from Part 2.1:

al_clear_to_color(al_map_rgb(255,0,255));
al_flip_display();

What this is doing is coloring our back buffer hideous magenta, and then swapping the buffers so that the back buffer is now presented onto the screen. With a little bit of magic and hard work on the part of the people behind Allegro 5.0, what was once a task to implement is now just a built-in feature. Go team!

A Word on Modules

One big difference between Allegro 4.2 and Allegro 5.0 is that everything is broken down into modules. The effect is that if we want to draw primitives, we have to load the primitive module. If we want text, we load the text module. So on and so forth. This may seem like a bit of a hassle, but in reality it streamlines the behind the scenes code and makes your games faster and more efficient.

Coming up next we start getting objects up on the screen!