Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon Join the GFS Discord Server!
3. November 2017

Welcome to part one in our tutorial series covering Allegro, an open source C game library/media framework.  For a bit more of an overview and a video version of this tutorial be sure to check out this video.  In this tutorial series we are going to cover the basics of getting started with Allegro, from creating your basic app, to drawing graphics and playing audio.

In this part we are going to illustrate creating a project using Visual Studio 2017.  Allegro is also available on Linux and Mac, but we are not going to cover the getting started process on these platforms.  All of the code in subsequent tutorials will be applicable for all platforms.

Allegro supports NuGet, which makes setting up a new project in Visual Studio incredibly easy.  Let’s start off by creating a Hello World example.  Let’s get started.

Start off by creating a new Windows application in Visual Studio.  Select File->New->Project…


Next select Visual C++, then Windows Console Application, name it and give it a location, then hit the OK button.


In the Solution Explorer, for your newly created project, right click References and select Manage NuGet Packages…


Next click Browse, enter Allegro in the text field, then click the download icon.  Click OK if prompted with an additional dialog.


And done!  You have now configured Allegro for use.  In this example however we are going to need two additional libraries.  Allegro is modular in nature and you only enable the functionality you need.  Our application is going to display Hello World on screen and this is going to require a pair of libraries for text and font support.  Don’t worry, it’s easy.

In the Solution Explorer, select your project, like so:


Now either right click and select Properties or press Alt + Enter.  This will bring up the Properties Window for your project.  On the left hand side, located and select Allegro 5, then locate and enable Truetype Font Addon and Font Addon, like so:


Click Apply then Ok to close the dialog.  We are now ready to code.

You should have a file created for you with the same name as your project, in my case it’s HelloWorld.cpp.  Double click it in the Project Explorer window and replace it with the following code:

#include "stdafx.h"
#include <allegro5/allegro.h>
#include <allegro5/allegro_ttf.h>
#include <allegro5/allegro_font.h>

int main()

	ALLEGRO_DISPLAY * display = al_create_display(640, 480);
	ALLEGRO_FONT * font = al_load_ttf_font("YARDSALE.ttf", 64, 0);

	while (true) {
		al_clear_to_color(al_map_rgb(255, 255, 255));
		al_draw_text(font, al_map_rgb(0, 0, 0), 0, 0, 0, "Hello World");

This code follows a pretty common pattern in Allegro.  We always start off by initializing the Allegro libraries with a call to al_init().  You will notice in this example we also need to init the two addons we included.  This is true for all addons use in Allegro as you will see shortly.

This code then creates a window 640x480 in size, loads a font named YARDSALE.ttf with a size of 64pt.  Next we run an infinite loop clearing the background to white ( in RBG format, each number from 0 – 255 is the amount of that could, Red, Green and Blue respectively ).  We then draw the text using our font and this time the color black.  All this time we have been drawing to an offscreen buffer.  Call al_flip_display() to make this offscreen buffer visible to the user.

There are a few things to note about this example… first it can’t be exited.  Don’t worry, we will cover that in a future tutorial.  It also leaks resources like a sieve.  Each load, create or init call has a corresponding call to free those resources up when we are done with them.  We will also cover this in a future tutorial.

The final thing you might notice is we used a font called YARDSALE.ttf…  guess we need that font don’t we?  That font is available for download here, simply download the zip file and copy the file YARDSALE.ttf.  Of course if you have your own TTF file, you can feel free to use it, just be sure to change the file name in the code.  Now the question remains… where do you copy it?  This is actually an area that Visual Studio C++ developers often get tripped up… I certainly do.  You want this file to be copied into the Working Directory of your application.  You can determine or set this directory in the Properties panel of your project. 


Copy the TTF file to this location.

Now you can run your code by hitting F5 or clicking Local Windows Debugger in the toolbar.  If everything went according to plan, you should see:


Congratulations, you’ve just created your first Allegro application!  On thing you might notice is a DOS window in the background, like so:


Don’t worry, getting rid of this window is pretty simple.  Once again, open up the Properties window of your project.  Now locate Linker->System on the left hand side.  Select SubSystem, then Windows instead of Console.


Voila, no more console window!  One other thing you may notice… due to the fact this application is an infinite loop, it never actually shuts down and you can’t close it using the X icon.  For now you can exit the application in Visual Studio using this button:


Or by hitting Shift F5.  Well that’s it for Part One, congratulations, you’ve created your very first Allegro application.  Next we will look a bit closer at our game loop and making exiting our game a lot easier.

Back to Table Of Contents


26. June 2017

The Esenthel Game Engine has been under development for more than a decade and yet I had never actually tried it before now.  They recently released a Fantasy Tech Demo illustrating recent functionality added to the engine.  After trying out the demo, I decided to give Esenthel a shot.  The following video is a quick hands-on with the Esenthel Game Engine. Esenthel is a C++ powered/scripted game engine with a full editing environment as well as Visual Studio integration.

The Essenthel Engine has a free trial available for download and is available for Windows, Mac and possibly Linux.  The full version is a commercial subscription for 11.40$ a month or 114$ annually.  A source license costs double that amount.


2. August 2016


Allegro is a C/C++ game library with a found place in my memory.  It was one of the very first, freely available open source 2D C/C++ frameworks and it continues to be developed to this very day.  In fact, Allegro 5.2.1 was just released.


From the change logs.


  • Optimize bitmap holding a bit (Bruce Pascoe).

  • Add al_get/set_depth/samples (OpenGL only for now).

  • Optimize destruction performance when you have thousands of objects (e.g. sub-bitmaps).

  • Use low floating point precision for the OpenGL fragment shaders, which helps performance a lot on mobile platforms.

  • Don't stop and join the timer thread when stopping the last timer (prevents unnecessary delay in this situation on some platforms).

  • Add al_backup_dirty_bitmap and al_backup_dirty_bitmaps to more finely control when bitmap context backup is performed.

Android port:

  • Fix Android app issues when woken up during sleep.

  • Specify the Android toolchain file on the command line now. ANDROID_NDK_TOOLCHAIN_ROOT now has to be specified in an environment variable.

OSX port:

  • Improve joystick enumeration (Todd Cope).

  • Make al_set_new_window_title work correctly.

  • Don't send duplicate mouse move events.

  • Fix mouse warping behavior.

  • Exit fullscreen mode if ALLEGRO_FULLSCREEN_WINDOW is set when destroying a display (otherwise if you destroy and recreate display without terminating the program, a white window kicks around).

iOS port:

  • Make it compile again.

  • Don't backup textures as it is unnecessary.

  • Update minimum iOS to version to 6.1.

  • Disable the native png loader in favor of libpng, as it is broken on Apple's end.

  • Create library when creating the archive.

Windows port:

  • Fix the D3D target bitmap bug.

  • Clear display to black right away to avoid an ugly white flash.

Raspberry Pi port:

  • Fix system cursor support.

Linux port:

  • Make al_set_new_window_title work correctly.

Build system:

  • Use PROJECT_SOURCE_DIR and PROJECT_BINARY_DIR instead of CMAKE_SOURCE_DIR and CMAKE_BINARY_DIR. This lets you use Allegro as a sub-project in your CMake project.

  • Fix GDIPlus finding in cmake-gui (Bruce Pascoe).

  • Add .gitignore and ignore build/ dir (Mark Oates).

  • Fix building examples with non-Allegro dependencies with the monolith build.


  • Various documentation updates (Daniel Johnson and others).


  • Add more #include statements in Allegro headers, so it's easier to use them in isolation (Jordan Woehr).

  • Allow marking tests as being hardware only.

  • Prefix some private Allegro macros and types to not pollute the namespace.

  • Make set_shader_uniform api const-correct (Bruce Pascoe).

Audio addon:

  • Adjust loop end position when calling al_set_sample_instance_length.

Acodec addon:

  • Allow file-backed audio streams to be restarted after they finish.

  • Add Opus codec support.

Image addon:

  • Fail gracefully if not built with PNG/JPG loaders.

Native dialog addon:

Font addon:

  • Make al_get_text_dimensions and al_get_glyph_dimensions return exact bounding boxes (koro).

  • Add ALLEGRO_GLYPH structure and al_get_glyph, allowing for some additional optimization when drawing fonts.


  • Add more controls to ex_audio_props.

  • Add an example of using Enet with Allegro.

GameDev News

24. July 2016


Traditionally I don’t recommend beginners start with C++.  There are a number of reasons behind this opinion, most of which are explained in this video.  Most of the reasons however have very little to do with the language itself (which does of course have some downsides) and more to do with the build system, linker and limited included libraries.  I recently discovered a library aimed at beginners that alleviates a great deal of the downsides of learning using C++, raylib.  It’s free, open source (available on Github) and provides most of the functionality you require to make a game.  Most importantly, it’s aimed at beginners meaning the library is easy to use and comes with a turn key installer that enables you to hit the ground running.

If you are interested in learning more about raylib, be sure to watch this video (also embedded below).


The key features of raylib are:

- Written in plain C code (C99)
- Uses C# PascalCase/camelCase notation
- Hardware accelerated with OpenGL (1.1, 2.1, 3.3 or ES 2.0)
- Unique OpenGL abstraction layer (usable as standalone module): [rlgl]
- Powerful fonts module with SpriteFonts support (XNA fonts, AngelCode fonts, TTF)
- Outstanding texture formats support, including compressed formats (DXT, ETC, ASTC)
- Basic 3d support for Geometrics, Models, Heightmaps and Billboards
- Materials (diffuse, normal, specular) and Lighting (point, directional, spot)
- Shaders support, including Model shaders and Postprocessing shaders
- Powerful math module for Vector and Matrix operations [raymath]
- Audio loading and playing with streaming support (WAV, OGG, XM, MOD)
- VR stereo rendering support with configurable HMD device parameters
- Multiplatform support: Android, Raspberry Pi, HTML5, Oculus Rift CV1
- Custom color palette for fancy visuals on raywhite background
- Minimal external dependencies (GLFW3, OpenGL, OpenAL)


The part I found most impressive though is the installer.  It comes with a pre-configured version of the MingW compiler and Notepad++ set up for development right away.  Basically you run the installer, open notepad++, start writing code and hit F6 to run it.  No dealing with setting up a compiler, learning about linkers and all the various things that make the C++ learning curve so painful.  Well, most of the things...


I should point out quickly, while I’ve been calling it a C++ library, it’s actually a C library.  This is a minor distinction as it is perfectly usable in C++ and feels like C++.  It comes with a copious amount of examples, with very easy to understand code.  Here for example is an, um, example that illustrates loading and drawing images:

*   raylib [textures] example - Image loading and drawing on it
*   NOTE: Images are loaded in CPU memory (RAM); textures are loaded in GPU 
memory (VRAM)
*   This example has been created using raylib 1.4 (
*   raylib is licensed under an unmodified zlib/libpng license (View raylib.h 
for details)
*   Copyright (c) 2016 Ramon Santamaria (@raysan5)

#include "raylib.h"

int main()
    // Initialization
    int screenWidth = 800;
    int screenHeight = 450;

    InitWindow(screenWidth, screenHeight, "raylib [textures] example - image 

    // NOTE: Textures MUST be loaded after Window initialization (OpenGL context 
    is required)

    Image cat = LoadImage("resources/cat.png");             // Load image in CPU 
    memory (RAM)
    ImageCrop(&cat, (Rectangle){ 100, 10, 280, 380 });      // Crop an image 
    ImageFlipHorizontal(&cat);                              // Flip cropped 
    image horizontally
    ImageResize(&cat, 150, 200);                            // Resize flipped-
    cropped image
    Image parrots = LoadImage("resources/parrots.png");     // Load image in CPU 
    memory (RAM)
    // Draw one image over the other with a scaling of 1.5f
    ImageDraw(&parrots, cat, (Rectangle){ 0, 0, cat.width, cat.height }, (
    Rectangle){ 30, 40, cat.width*1.5f, cat.height*1.5f });
    ImageCrop(&parrots, (Rectangle){ 0, 50, parrots.width, parrots.height - 100 }
    ); // Crop resulting image
    UnloadImage(cat);       // Unload image from RAM

    Texture2D texture = LoadTextureFromImage(parrots);      // Image converted 
    to texture, uploaded to GPU memory (VRAM)
    UnloadImage(parrots);   // Once image has been converted to texture and 
    uploaded to VRAM, it can be unloaded from RAM

    // Main game loop
    while (!WindowShouldClose())    // Detect window close button or ESC key
        // Update
        // TODO: Update your variables here

        // Draw


            DrawTexture(texture, screenWidth/2 - texture.width/2, screenHeight/2 
            - texture.height/2 - 40, WHITE);
            DrawRectangleLines(screenWidth/2 - texture.width/2, screenHeight/2 - 
            texture.height/2 - 40, texture.width, texture.height, DARKGRAY);

            DrawText("We are drawing only one texture from various images 
            composed!", 240, 350, 10, DARKGRAY);
            DrawText("Source images have been cropped, scaled, flipped and 
            copied one over the other.", 190, 370, 10, DARKGRAY);


    // De-Initialization
    UnloadTexture(texture);       // Texture unloading

    CloseWindow();                // Close window and OpenGL context

    return 0;


All examples are a single .c file and there are plenty of them.  All you need to do is open them in Notepad++ and hit F6 to run.


At the end of the day, I still don’t personally think C++ is the ideal language to learn game programming, or programming in general.  However if you are going to start using C++, raylib is the single best starting point I have ever seen.  In fact, let me know if you would be interested in a beginner C++ tutorial series built around this library, let me know!


The Video


12. July 2016


Today Torque 3D released version 3.9 and in a somewhat odd release blog post they spoke mostly about the plans for the next release.  Torque is an MIT licensed open sourced 3D game engine written in C++.  This release constitutes 515 commits with the major releases being proper roll over to deferred renderer, an initial implementation of entity/component and DirectX 11 integration.


As mentioned earlier, the majority of the release blog post covers features intended for the 4.0 release:

So, here's a main features list that we're looking at bringing into Torque for 4.0:

  • Physically-Based Rendering. This is, unsurprisingly a pretty big one. Luckily, it's also most of the way done! The only main piece that needs finishing is reflection probes, and the core features are in. From there it would just be a matter of dialing in the supporting art pipeline and tweaking the math to make it look as good as possible.
  • MacOS support. This was originally slated for 3.9, if you look at the 3.8 release blog, but a lack of machines to test on, and the age-addled old platform code made it impractical to really tackle initially. The good news is, near the end of 3.9's development, with SDL and epoxy to take a LOT of the workload off, huge strides were made and it's actually almost completed. There's still some issues with rendering on some machines and catching errors and warnings that crop up, but it's looking very practical to have MacOS as an official platform for 4.0! You can see Timmy's screenshot in the 3.9 RC thread showing off T3D running on MacOS with his and JeffH's work now.
  • SDL as the main platform layer. Torque3D's supported SDL for quite a while now, and it's naturally the main platform layer for Linux(and MacOS). However, it's been a little bit of a red-headed stepchild to the Win32 platform code. For 4.0, that's changing and SDL will be adopted as the core platform layer with whatever glue needed sitting atop it. This will drastically simplify the platform code and make it easier to maintain. It also offers a good bit of future proofing should any other platforms come into the equation down the line. SDL's stuff is very nearly at parity with the Windows side, it's pretty much just a matter of jumping over the last bits and doing cleanup/bugfixes to make it rock-solid.
  • New Project Manager The old project manager was useful, but was hacked together with QT and php, so maintaining it was a little sketchy and fell by the wayside for the more standard CMake gui. However, there's lots of management things CMake can't do, which is why the Project Manager will be making a comeback, it'll just be a graphical frontend sitting upon the more standard cmake project generation. This new PM will let you manage your updates, and hopefully in the future hook into online repositories for easier grabbing and integration of updates as well as fetching content packages without hassle.
  • New Shadergen As great a job as the current workhorse does of generating shaders for all the many materials you need to make a game, updating and expanding it has proven to be a pretty annoying thing to deal with due to how it's structured. Excellent peice of tech, but a chore to maintain, just like ye olde German tanks in WW2. As such, we'll be looking into restructuring shadergen to not only make it easier to update and expand upon in the backend-sense, but also easier to build materials/shaders for the end user as well, up to, and probably including a node-based approach for engineering your fancy shaders for your fancy materials.
  • Graphics API refinements DirectX 9 has proven to be a monstrous workhorse of the graphical APIs, reliably serving well beyond what anyone though it would. However, while it has proven to be a rock-solid API, the time has come to retire the poor girl and send her off to the glue facto-eeeer, the farm. Yes. As such, DirectX 11 will be taking over as the main Dx rendering API, and will continue to see refinements to bring it up to speed now that Dx9 isn't hampering it or OpenGL. Timmy's been poking at this and has noted improved performance in Dx11 by quite a lot, and some gains in OpenGL as well.
  • Threads. Threads for days One major blocker to rendering performance that even dropping Dx9 won't help is that we curretly don't thread or do much to optimize out the render calls themselves. That'll change in 4.0. We've been brainstorming the optimal approach for a few months now and have a pretty solid plan of attack that will see the render calls threaded out, and also proper batching of rendered geometry where appropriate. So fewer, faster drawcalls for the same workload. We'll also be looking at threads for handling resource loading and spawning of objects to cut out all those hitches when the map starts or stuff is created.
  • Hardware Skinning Another thing that's been pretty much complete outside a few oddball behaviors we'll be getting in there is Hardware Skinning. When it's behaving, the current implementation already notes a huge improvement in performance for animated meshes, so getting it polished up and in should be a huge, immediate performance boon.
  • Physics API T3D's had a physics abstraction layer for a long time now, and it's been pretty useful in letting the end user decide if they wanted PhysX or Bullet. However, Torque's stock physics has still served a useful niche in being network-reliable, or lightweight for basic physics mechanics, and some people find it to be a pretty workable thing. As such, the Torque physics will be converted over into a Physics plugin, so all physics and collisions will go through the Physics API and standardize all the behavior for that across the engine, cleaning up quite a lot and making it easier to maintain.
  • Entities, Components, and Assets This is the big one from non-rendering side. 3.9 already has the initial implementation of the entity/component stuff, as well as the Assets/Modules systems, but they're not yet fully utilized. That'll change in 4.0. If you've been checking out my work blog with the recent updates, I've been covering work I've been doing on the improved asset pipeline, as well as continued work with the Entity/Component stuff. For 4.0, this will become the standard, and all existing gameplay classes(Vehicle, Player, Item, Shapebase) will be replaced with GameObjects built of entities and components to do the same work. The idea is to give users a similar base to what is in Torque now in terms of starting objects, but remove all the bulky, hardcoded functionality. It should be a standard point, not an anchor, after all. Tying to that, we also will have:
  • Assimp support This was actually mostly done back in the day, just some issues with animation stuffs and a few other minor problems. I'd poked at this with some R&D time a while back, so it shouldn't take much tweaking to get it polished up and hooked into the assets system, which will allow quite a few new 3d model formats, including FBX.
  • A new base template This is also basically complete. This will be a much more streamlined starting template intended to easily drop in modules, assets and the like into to build up your game project, as opposed to having to spend time stripping out the stuff you don't need. Numerous ancillary improvements also help load times, easier to read and comprehend code and the like. This will replace the empty and full templates, cutting down on the effort needed to maintain(no need to duplicate changes).
  • Vive support This comes from our own Mango's efforts. It's pretty much done, but didn't quite squeak in for 3.9. It will be going into 4.0 for sure.

GameDev News

See More Tutorials on!

Month List