Allegro 5: a C multimedia library for games that leaves program structure to you

Allegro handles low-level platform tasks but leaves program structure entirely to you

Allegro's own description draws a boundary that matters for adoption decisions. It handles "common, low-level tasks such as creating windows, accepting user input, loading data, drawing images, playing sounds" and abstracts away the underlying platform. What it does not do is impose any program structure: "you are free to design and structure your program as you like."

This separation is a direct consequence of Allegro not being a game engine. A game engine typically provides a scene graph, entity management, a scripting layer and tooling around asset pipelines. Allegro provides none of those. A developer using Allegro writes all application logic from scratch, which gives full control but also means more work before the first game loop runs.

The audience is C and C++ developers working on games and multimedia applications who want hardware-accelerated drawing, cross-platform input and audio without being locked into an engine's architecture. The C API is described as user-friendly and intuitive, and the examples directory contains dozens of single-purpose files, each targeting one area of the API surface.

Building Allegro requires CMake 3.0 and a separate build directory

Building from source follows a two-step CMake process. CMake 3.0 or later is required, and a separate build directory is required; configuring in the source directory with `cmake .` produces an error message, and the remedy is to delete CMakeCache.txt and the CMakeFiles directory, then reconfigure from a dedicated directory.

The configuration step looks like this:

mkdir build
cd build
cmake ..

Once configuration succeeds, the build step uses `make` or an IDE depending on the compiler. Supported compilers are gcc, clang and MSVC.

One documented constraint applies to the source path: unpacking Allegro into a directory with spaces or other unusual characters in the path is a known problem. Paths with special characters cause trouble; clean ASCII paths without spaces work as expected.

Documentation is a separate build step that requires Pandoc. Building Allegro without building the documentation is fully supported, and the online documentation is available at docs.liballeg.org regardless of whether the local documentation is built.

Core library dependencies differ between Windows, Linux and Mac

Allegro is divided into a core library and addon libraries. The core library has required dependencies, and they differ by platform.

On Windows, the DirectX SDK is required. A full MSVC download is available from the Microsoft web site. Smaller downloads for MSVC and MinGW are available at liballeg.org/download.html, and some MinGW distributions include a sufficient DirectX SDK already.

On Linux and other Unix systems, X11 development libraries are required. These ship with most Linux distributions but need explicit installation when the distribution separates development packages.

OpenGL development libraries are marked as optional only on Windows, where Direct3D is an alternative rendering backend. On Linux and Mac, OpenGL is a required dependency, so a developer testing on Windows with Direct3D who then moves to a Linux build target will find that OpenGL becomes mandatory there.

Addon libraries are strictly optional but their absence disables specific capabilities

None of the addon libraries is required to build Allegro. Their absence disables the features they support.

For audio, the supported codec libraries are Ogg Vorbis (libogg, libvorbis, libvorbisfile), Opus (libogg, libopus, libopusfile), FLAC (libFLAC, libogg) and DUMB, which handles IT, XM, S3M and MOD module files. OpenAL is an audio addon option as well; the audio addon can use OpenAL, though its 3D capabilities are not used.

For fonts, FreeType provides TrueType font support. For access to archives such as .zip files, PhysicsFS is the addon dependency.

Windows users can find precompiled binaries for additional libraries at gnuwin32.sourceforge.net, requiring both the `bin` and `lib` packages. Mac users can source dependencies from Homebrew, Fink or MacPorts. Linux distributions include the required core dependencies, with PhysicsFS and DUMB as exceptions that need explicit installation from packages named *-dev or *-devel.

README_cmake.txt documents the "deps subdirectory" approach for Windows, where placing libraries so CMake finds them can be problematic.

PNG and JPEG use native OS facilities on Windows, Mac, iPhone and Android but need external libraries on Unix

Image format support has a platform split that is easy to miss during cross-platform development. On Windows, Mac OS X, iPhone and Android, PNG image support uses the native facilities of the operating system, so libpng is not required. On Unix and older MinGW, libpng and zlib are needed.

JPEG support follows the same division. On Windows, Mac OS X, iPhone and Android, native facilities handle JPEG loading and libjpeg is not required. On Unix and older MinGW, libjpeg is a dependency.

WebP breaks this symmetry: libwebp is required except on Android, where native WebP support is available.

A developer building on Mac and deploying to Linux will not encounter missing libpng or libjpeg errors locally, but the Linux build will fail without them. Setting up CI with a Linux target is the reliable way to catch Unix-specific dependency gaps before deployment.

OpenAL is required on Mac OS X but only optional on Linux and Windows

The OpenAL dependency has an asymmetry worth reading carefully. On Mac OS X, OpenAL is required, though it comes with the OS. On Linux and Windows, OpenAL is used only when explicitly requested; there is no reason to install it specifically on those platforms if it is not wanted.

The README places this detail in the middle of the OpenAL entry under addons, marked with an asterisk. The addons section lists all these libraries together, but the required status for OpenAL on Mac is flagged separately from the optional treatment on Linux and Windows, and the distinction is easy to miss on a first read.

For any project targeting Mac, OpenAL is a required dependency regardless of whether the application uses audio features, because the audio addon needs it and the OS supplies it. The practical impact is low since it ships with Mac OS X, but the dependency status differs from the other platforms and build configuration needs to reflect it.

What Allegro provides vs what a game engine provides

Allegro's own characterization of itself as not a game engine is worth taking at face value. The library supplies hardware-accelerated bitmap and graphical primitive drawing via OpenGL or Direct3D, audio recording, font loading and drawing, video playback, and abstractions over shaders and low-level polygon drawing. That is the full list from the README.

Absent from this list is anything about scene management, entity component systems, built-in physics, scripting support, an asset pipeline, or an editor. A game engine handles those concerns so that a developer can focus on game logic. Allegro does not.

For a developer who wants to write a custom engine, or who wants the smallest possible abstraction between the application and the hardware, Allegro provides the platform layer and nothing more. For a developer who wants to build a game without constructing that foundation, a fully featured engine with a scene system is the more direct path. The examples directory, with files named ex_bitmap.c, ex_audio_simple.c and ex_blend.c, demonstrates library calls, not a game.

Platform-specific README files and where to look first for your target

The repository contains a set of platform-specific README files that go beyond the main README. README_msvc.txt covers Windows with MSVC, README_make.txt covers GNU make on Unix-like systems including Linux and MinGW, README_macosx.txt has additional notes for macOS, README_iphone.txt addresses iOS, README_android.txt covers Android, and README_windows.txt and README_sdl.txt exist alongside them.

The main README explicitly directs readers to these files after the CMake configuration step, and each one covers the dependencies and build steps for that specific environment. The main README is intentionally general; the platform file is where configuration errors and dependency placement are documented in detail.

A SECURITY.md file is also present at the repository root. GitHub classifies the licence as Other because it does not match any recognized template; LICENSE.txt is the authoritative text to read before redistribution.

Editorial conclusion

Allegro 5 suits developers who want a C API for windowing, input, audio, fonts, video and OpenGL graphics without the constraints a game engine imposes. It is not the right tool if you need a scene graph, an entity system or a visual editor, because the library provides none of those. Before building, verify the platform-specific dependency requirements: DirectX SDK on Windows, X11 on Linux, OpenAL on Mac OS X. On Unix, libpng and libjpeg are required for image support unless you target a platform where native facilities apply. Read LICENSE.txt in full before redistribution, since GitHub classifies the licence as Other.

Frequently asked questions

Official sources

1. Issues
2. liballeg/allegro5 on GitHub
3. Project website
4. README
5. Releases