Community hub
0 subscribers8 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Allegro (software library).
Nothing was collected or created yet.
Allegro (software library)
View on Wikipediafrom Wikipedia
| Allegro | |
|---|---|
 Logo | |
| Original author | Shawn Hargreaves |
| Developer | Allegro developers |
| Initial release | early 1990 |
| Stable release | 5.2.11.2[1]
/ January 4, 2026 |
| Repository | |
| Written in | C |
| Operating system | Windows, Linux, macOS, Android, iOS, web browser et al. |
| Type | Multimedia and Games SDK |
| License | Allegro 5: zlib[2] |
| Website | liballeg |
Allegro is a software library for video game development.[3][4][5] The functionality of the library includes support for basic 2D graphics, image manipulation, text output, audio output, MIDI music, input and timers, as well as additional routines for fixed-point and floating-point matrix arithmetic, Unicode strings, file system access, file manipulation, data files, and 3D graphics. The library is written in the C programming language and designed to be used with C, C++, or Objective-C, with bindings available for Python, Lua, Scheme, D, Go, and other languages.[6] Allegro comes with extensive documentation and many examples.
Allegro supports Windows, macOS, Unix-like systems, Android, and iOS, abstracting their application programming interfaces (APIs) into one portable interface. It can run also on top of Simple DirectMedia Layer which is used to run Allegro programs in web browser using Emscripten.[7]
Released under the terms of the zlib license, Allegro is free and open source software.
History
[edit]Initially standing for Atari Low-Level Game Routines,[8] Allegro was originally created by Shawn Hargreaves for the Atari ST in the early 1990s. When Hargreaves realized the platform was dying, he abandoned the Atari version, and reimplemented his work for the Borland C++ and DJGPP compilers in 1995. Support for Borland C++ was dropped in version 2.0, and DJGPP was the only supported compiler. As DJGPP was an MS-DOS compiler, all games which used Allegro therefore used DOS, attracting the enthusiast scene for that legacy system.[9] Around 1998, Allegro branched out into several versions. A port to Windows, WinAllegro, was created, and also during this time, a Unix port of Allegro, XwinAllegro, was created. These various ports were brought together during the Allegro 3.9 WIP versions, with Allegro 4.0 being the first stable version of Allegro to support multiple platforms.
Allegro 5
[edit]Current development is focused on the Allegro 5 branch, a complete redesign of both the API and much of the library's internal operation. Effort was made to make the API more consistent and multi-thread safe. By default, the library is now hardware-accelerated using OpenGL or DirectX rendering backends where appropriate. Many of the addons that existed as separate projects for Allegro 4 now interface seamlessly with Allegro proper and are bundled with the default installation. Allegro 5 is event driven.
See also
[edit]References
[edit]- ^ "5.2.11.2 Release". 5.2.11.2 Github Release Page. Retrieved 4 February 2026.
- ^ Allegro Development Team. "The giftware license". Retrieved 2013-11-16.
- ^ Harbour, Jonathan (2004). Game Programming All in One, Second Edition. Course Technology PTR. ISBN 1-59200-383-4.
- ^ Steinke, Lennart (2003). Spielprogrammierung. BHV Verlag. ISBN 3-8266-8075-8.
- ^ Deitel, P. J. (2006). C How to Program. Prentice Hall. ISBN 0-13-240416-8.
- ^ List of Allegro language bindings
- ^ "Welcome to Allegro!". GitHub. 23 September 2022.
- ^ Forum posting by Shawn Hargreaves
- ^ Wilson, Hamish (2024-04-09). "Building a Retro Linux Gaming Computer Part 41: The Worm Turns". GamingOnLinux. Retrieved 2024-04-13.
Although the project does see continued support to this day with the Allegro 5 branch, for much of its history Allegro was very much associated with the MS-DOS freeware scene that was still going strong well into the early 2000s.
External links
[edit]Allegro (software library)
View on Grokipediafrom Grokipedia
Allegro is a free and open-source cross-platform software library primarily designed for video game and multimedia programming in the C and C++ languages. It abstracts low-level tasks such as creating windows, managing input devices (including keyboard, mouse, and joystick), rendering 2D and 3D graphics via hardware acceleration with OpenGL or Direct3D, handling audio playback and recording, loading images and fonts, and supporting shaders and video playback.[1] Unlike full game engines, Allegro focuses on providing modular building blocks to simplify development without imposing a specific architecture.[2]
Originally conceived by programmer Shawn Hargreaves in the mid-1990s as a set of routines for the Atari ST platform, the library evolved into a collaborative open-source project with contributions from hundreds of developers worldwide.[2] The name "Allegro" derives from the Italian word meaning "quick, lively, or bright" and serves as a recursive acronym for "Allegro Low LEvel Game ROutines."[2] Its first major iteration, Allegro 4, was released in the late 1990s and became widely used for 2D game development on platforms like DOS, Windows, and Unix systems, maintaining backward compatibility back to version 2.0 from 1996; however, active development on this branch ceased years ago, with only occasional bug fixes.[2]
The current major version, Allegro 5 (first released in 2011), represents a significant redesign to leverage modern hardware and APIs, breaking backward compatibility with earlier versions while introducing enhanced modularity, better support for mobile devices, and integration with 3D graphics pipelines.[2] As of November 2025, the latest stable release is version 5.2.10.1 (December 2024), hosted on GitHub under the liballeg organization since 2015, with ongoing community-driven development facilitated through forums, a Discord server, and periodic game jams.[3] Allegro 5 supports a wide array of platforms, including Windows (via MSVC and MinGW), Linux, macOS, Android, and iOS, enabling developers to write portable code with minimal platform-specific adjustments.[2]
Key features include hardware-accelerated primitives for drawing, timer and event systems for smooth animations, extensible add-ons for physics and networking (though core library avoids these to remain lightweight), and bindings for other languages like D, Python, and Lua.[1] The library has been instrumental in the indie game scene, powering titles such as Micro Mages[4] and String Tyrant[5], and continues to emphasize portability, performance, and ease of use for hobbyists and professionals alike.
Overview
Purpose and Scope
Allegro is a cross-platform, open-source C library designed to handle low-level tasks essential for video game and multimedia applications, such as window creation, graphics rendering, audio playback, and input management.[1][6] The library originated in the mid-1990s, when Shawn Hargreaves developed it initially for the Atari ST platform, focusing on simplicity and portability to support 2D-focused development amid the platform's declining popularity.[6][7] Its core design goals center on providing hardware abstraction layers for graphics, sound, and input devices, thereby facilitating rapid prototyping and seamless cross-platform deployment without requiring developers to manage platform-specific details.[2][6] Allegro primarily targets independent game developers and hobbyists who require a lightweight, flexible foundation for building 2D games and interactive multimedia projects, serving as an accessible alternative to more comprehensive frameworks like SDL for low-level control or higher-level engines like Unity.[1][2] Over time, it has evolved to include support for multi-threading in modern versions, enhancing its utility for contemporary development workflows.[2]Licensing and Platforms
Allegro has been released under the zlib license since version 4.9.6, a permissive open-source license that permits free use, modification, and distribution for any purpose, including commercial applications, subject to minimal requirements such as retaining the copyright notice and disclaiming warranties.[8] This licensing model, also applied to Allegro 5, facilitates broad adoption by developers while ensuring the library remains accessible without restrictive copyleft obligations.[9] The library supports a wide array of platforms, including Windows, macOS, Linux and other Unix-like systems, Android, and iOS, enabling cross-platform development with a unified interface.[2] Additionally, Allegro provides experimental support for targeting web browsers through Emscripten compilation, leveraging the SDL backend for HTML5 compatibility and allowing games to be compiled for modern web environments using Emscripten, which targets WebAssembly and JavaScript.[10] For hardware compatibility, Allegro utilizes OpenGL and Direct3D backends to provide accelerated rendering on supported systems, falling back to software-based methods when hardware acceleration is unavailable or incompatible.[1] As of 2025, Vulkan integration is not supported.[11] This approach ensures functionality across diverse graphics environments. Portability is enhanced by Allegro's abstracted application programming interfaces (APIs), which encapsulate platform-specific details like window creation, input handling, and graphics initialization, allowing developers to maintain a single codebase deployable across desktop, mobile, and web targets with minimal adjustments.[12] Early versions focused on MS-DOS, but subsequent iterations prioritized multi-platform abstraction to support evolving hardware and operating systems.[2]History
Origins and Early Versions
Allegro was originally conceived by Shawn Hargreaves in the early 1990s as a personal project targeted at Atari ST game development, where it provided foundational routines for graphics and input handling.[6] As the Atari ST platform waned during its development, Hargreaves shifted focus and ported the library to MS-DOS using the DJGPP compiler, releasing version 1.02 in 1995 as the first public version.[13] This port enabled broader adoption within the PC gaming community, leveraging DJGPP's capabilities for 32-bit programming under DOS.[6] The primary motivations for these early versions centered on overcoming constraints of DOS-era hardware and software, particularly the limited graphics modes like VGA at 320x200 resolution with 256 colors, by offering a streamlined API for essential tasks such as sprite manipulation, palette management, and keyboard/mouse input.[6] This unified interface simplified multimedia programming for games, abstracting low-level details into accessible functions for timers, sound, and basic rendering.[6] Initial community engagement grew through open-source distribution channels and early online forums, fostering volunteer contributions that refined the library's core features before its migration to platforms like SourceForge for collaborative development.[14]Allegro 4
Allegro 4.0 marked the first stable multi-platform iteration of the library, released on December 10, 2001, expanding beyond DOS to include native support for Windows, X11/Unix, and BeOS through improved portability layers that abstracted platform-specific operations like graphics and input handling.[13] This shift enabled developers to target multiple operating systems with a unified API, building on the DOS-centric foundations of prior versions while addressing growing demands for cross-platform game development.[15] Key enhancements in the 4.0 series focused on graphics and audio capabilities, introducing hardware-accelerated rendering via DirectDraw on Windows and OpenGL support through the separate AllegroGL addon, which allowed for efficient 2D blitting and primitive drawing in truecolor modes.[15] Audio features included a basic software mixer for digital playback in 8/16-bit mono or stereo formats, supporting WAV and VOC files, alongside MIDI handling with drivers for Sound Blaster, Adlib, and platform-specific interfaces like DirectSound on Windows.[15] These additions provided a more robust foundation for multimedia applications without requiring external dependencies for core functionality. The series progressed with version 4.2.0 in November 2005, which adopted the zlib license to simplify redistribution and commercial use while maintaining backward compatibility; subsequent releases like 4.2.3 in 2007 added support for additional platforms such as QNX.[16][13] The final stable release, 4.4.2, arrived on May 19, 2011, incorporating minor bug fixes for stability across supported systems but underscoring persistent challenges including a single-threaded architecture that limited concurrent operations and API inconsistencies between modules like graphics and sound.[17] Furthermore, reliance on deprecated backends, such as GDI for Windows graphics fallbacks, contributed to performance issues on modern hardware.[15]Allegro 5
Allegro 5.0 was launched on February 6, 2011, as a complete rewrite of the library by the liballeg community, with development tracing back to 2002. This version emphasized greater modularity to allow for easier extension and maintenance, support for multi-threading to handle concurrent operations more effectively, and hardware acceleration through backends like OpenGL and Direct3D for improved performance in graphics-intensive applications.[18][19] The architecture underwent significant shifts to modernize the library, introducing an event-driven system where events from sources such as input devices, timers, and displays are aggregated into queues for efficient processing—created viaal_create_event_queue and queried using functions like al_get_next_event. Naming conventions were standardized with a consistent "al_" prefix for functions (e.g., al_create_display), promoting readability and reducing legacy inconsistencies from prior versions. Additionally, the addon system enables modular extensions, such as the native dialogs addon for platform-specific UI elements or the PhysicsFS addon for virtual filesystem handling, with community addons available for networking via third-party integrations like enet.[20][19][21]
The 5.x series evolved through subsequent versions, with the 5.1 branch beginning as an unstable release on November 20, 2011, and maturing to include enhanced mobile support, such as improved iOS and Android ports with touch input handling and fullscreen options by around 2014-2015. The 5.2 branch debuted in stable form around 2017, adding features like better OpenGL 3.x support. The latest stable release, 5.2.10.1 on December 28, 2024, focuses on bug fixes, including Emscripten improvements for web platforms and iOS build compatibility, alongside optimizations like Android joystick enhancements.[18][22]
Ongoing maintenance occurs through the official GitHub repository at liballeg/allegro5, where community contributors drive releases via pull requests, addressing deprecations in older backends like Direct3D 9 while prioritizing cross-platform stability across Windows, Linux, macOS, web, and mobile.[19]
Features
Graphics and Rendering
Allegro's core graphics API centers on bitmap handling, where theALLEGRO_BITMAP structure represents 2D images that can be created programmatically with al_create_bitmap for offscreen rendering or loaded from files, and managed through al_destroy_bitmap for cleanup. Blitting operations enable efficient copying of bitmaps or specific regions to the target, using functions such as al_draw_bitmap for full images and al_draw_bitmap_region for partial draws, supporting hardware-accelerated transfers where available. Drawing primitives, provided via the primitives addon, include lines via al_draw_line, circles via al_draw_circle and al_draw_filled_circle, as well as polygons and other shapes, with text rendering handled through the font addon's al_draw_text and related functions. Color manipulation employs the ALLEGRO_COLOR type, with alpha blending integrated through premultiplied alpha formats like al_map_rgba and blending modes set via al_set_blender, allowing transparent overlays and compositing effects essential for 2D visuals.[11][23]
Rendering backends in Allegro provide hardware acceleration through OpenGL on most platforms and Direct3D on Windows, automatically selected based on the display driver during initialization with al_set_new_display_flags, while falling back to software rendering for compatibility on unsupported hardware. This setup leverages framebuffer objects in OpenGL for rendering to bitmaps without direct screen access, ensuring consistent behavior across backends. Transformations for scaling and rotation are matrix-based, using the ALLEGRO_TRANSFORM structure manipulated by al_scale_transform for uniform or non-uniform scaling and al_rotate_transform for angular adjustments around specified axes; these can be composed with al_compose_transform and applied globally via al_use_transform or locally to bitmaps with al_draw_scaled_rotated_bitmap.[24][11][25]
Image formats are loaded into bitmaps primarily through the image addon, which must be initialized with al_init_image_addon; native support includes BMP, DDS (load-only with DXT compression), PCX, and TGA for direct loading and saving via al_load_bitmap and al_save_bitmap. Additional formats such as PNG and JPEG are handled via external libraries like libpng and libjpeg, integrated seamlessly once the addon is active, enabling broad compatibility for game assets without custom loaders.[26]
Advanced features enhance rendering efficiency and flexibility, with GLSL shader integration introduced in version 5.1.0 and expanded in 5.2+ through the ALLEGRO_SHADER object, allowing attachment of vertex and fragment shader sources with al_attach_shader_source and activation via al_use_shader for custom effects like post-processing or procedural textures. Primitive batching optimizes performance in sprite-heavy games by using al_draw_prim or al_draw_indexed_prim with vertex buffers created by al_create_vertex_buffer, minimizing draw calls and GPU uploads for large sets of lines, circles, or textured quads.[27][23]
Audio and Input Handling
The audio subsystem in Allegro 5 provides comprehensive support for sound playback and mixing through its dedicated addon, enabling developers to handle audio in cross-platform applications. Core functionality includes loading and playing audio samples viaal_load_sample and al_play_sample, which support formats such as WAV, OGG, FLAC, OPUS, and tracker modules like IT, MOD, S3m, and XM through the acodec addon.[28][29] Samples can be reserved for simultaneous playback using al_reserve_samples, with control over volume, panning (including ALLEGRO_AUDIO_PAN_NONE for mono), speed, and loop modes like ALLEGRO_PLAYMODE_ONCE or ALLEGRO_PLAYMODE_LOOP.[28] For larger files or background music, audio streams allow real-time data feeding via al_create_audio_stream and al_play_audio_stream, generating events such as ALLEGRO_EVENT_AUDIO_STREAM_FRAGMENT for buffer management.[28]
Voice mixing forms the backbone of the audio pipeline, where voices represent hardware audio devices and mixers combine multiple samples or streams into a unified output. Developers create voices with al_create_voice specifying channel configuration (e.g., mono, stereo) and depth (8-bit, 16-bit, or float), then attach mixers using al_attach_mixer_to_voice for layered audio effects.[28] Mixer quality can be adjusted via al_set_mixer_quality for linear or point sampling, and playback status is queried with al_get_mixer_playing.[28] Backends include OpenAL for cross-platform compatibility and DirectSound on Windows, ensuring low-latency output across systems.[28] Post-processing callbacks allow custom effects on attached audio objects.[28]
MIDI support in Allegro extends the audio capabilities with sequencer and output device handling, often integrated via addons that leverage external synthesizers for software-based playback.[30] This enables rendering of MIDI files containing note data and instrument instructions, typically small in size, into audible output without native format loading in the core acodec addon.[30]
Input handling encompasses keyboard, mouse, joystick, and touch devices through dedicated APIs that integrate seamlessly with the event system. The keyboard module, installed via al_install_keyboard, captures key presses and releases using ALLEGRO_KEYBOARD_STATE snapshots from al_get_keyboard_state, with checks via al_key_down for specific keys like ALLEGRO_KEY_A or modifiers such as ALLEGRO_KEYMOD_SHIFT.[31] Mouse input, managed by al_install_mouse, provides position (x, y), wheel (w, z), button states (e.g., ALLEGRO_MOUSE_BUTTON_LEFT), and pressure via ALLEGRO_MOUSE_STATE from al_get_mouse_state; custom cursors are set with al_set_mouse_cursor.[32] Joystick and gamepad support, via al_install_joystick, distinguishes standard joysticks from gamepads using ALLEGRO_JOYSTICK_STATE for axes (-1.0 to 1.0) and buttons, with hotplugging handled by al_reconfigure_joysticks and mappings based on SDL 2 formats.[33] For mobile platforms, touch input since version 5.1.0 supports up to 16 simultaneous touches through al_install_touch_input and ALLEGRO_TOUCH_INPUT_STATE, capturing positions, deltas, and IDs in events, with mouse emulation modes like ALLEGRO_MOUSE_EMULATION_MODE for compatibility; gesture recognition is facilitated by processing multi-touch events in application code.[34]
The event system unifies all input sources into a single queue for efficient handling in multimedia applications. Events from keyboard, mouse, joystick, touch, and audio are aggregated using ALLEGRO_EVENT_QUEUE created with al_create_event_queue, where sources register via al_register_event_source for FIFO delivery.[35] Developers poll non-blockingly with al_get_next_event or al_peek_next_event (returning false if empty), or wait with al_wait_for_event_until for timeout-based loops.[35] The ALLEGRO_EVENT union accommodates all types, including timestamps and source IDs, supporting multi-threaded scenarios where user events are emitted via al_emit_user_event with manual synchronization for thread safety.[35] This design enables non-blocking input processing and callbacks through event-driven loops, essential for responsive games.[35]
Timers and Add-ons
Allegro's timer module provides high-resolution timing capabilities essential for managing frame rates, animations, and other time-sensitive operations in real-time applications. The system supports the creation of multiple timers with configurable speeds, measured in seconds per tick, allowing for precise control over event generation. For instance, timers can be initialized usingal_create_timer, which returns a timer object if successful, and started with al_start_timer to begin incrementing the counter and emitting ALLEGRO_EVENT_TIMER events at the specified rate. These events facilitate callbacks and synchronization by integrating with Allegro's event queue, enabling developers to handle timing without polling.[36]
Timers in Allegro accommodate variable rates through dynamic adjustment via al_set_timer_speed, which updates the interval without stopping the timer, supporting adaptive scenarios like slowing animations. Pausing and resuming are handled by al_stop_timer and al_resume_timer, respectively, preserving the current count to maintain continuity upon resumption. The module ensures synchronization by atomically updating the counter with functions like al_add_timer_count, preventing race conditions in multithreaded environments. High-resolution support reaches microsecond granularity where platform drivers allow, though some may cap at milliseconds, making it suitable for frame-rate control in games targeting 60 FPS or higher.[36]
The add-on system in Allegro 5 adopts a modular architecture, separating optional extensions from the core library to reduce dependencies and enhance maintainability. Add-ons are built alongside the core but linked separately, loaded dynamically at runtime via functions like al_init_addon for specific features. This design allows developers to include only necessary components, such as the native dialogs add-on for platform-native file selectors and message boxes, which uses al_create_native_file_dialog to open system dialogs without custom implementation. Similarly, the PhysicsFS add-on, known as allegro-physfs, integrates the PhysicsFS library for abstract file I/O, enabling reading from archives like ZIP files through standard Allegro file handles like al_fopen.[37]
While official add-ons cover utilities like native dialogs and file I/O, third-party extensions such as WidgetZ provide GUI functionality, building on Allegro's primitives for widget-based interfaces. Installation of add-ons typically involves compiling them with the core and linking the appropriate library (e.g., -lallegro_dialog for native dialogs), with runtime initialization ensuring optional loading. This extensibility supports chaining, where add-ons like PhysicsFS can overlay core file operations for virtual filesystem mounting.
Utility functions within Allegro and its add-ons include abstractions for file I/O, such as the core's ALLEGRO_FILE interface extended by PhysicsFS for archive support and compression handling in formats like ZIP. Compression is further aided by add-ons like the memfile add-on, which allows loading files into memory for efficient I/O in resource-constrained environments. Math helpers emphasize fixed-point arithmetic for legacy compatibility, using the al_fixed type—a 32-bit signed integer with 16.16 fractional precision—for operations like multiplication (al_fixmul) and trigonometry (al_fixsin), ideal for systems lacking floating-point units. These utilities prioritize portability, with fixed-point routines offering accuracy to about four decimal places within a -32768 to 32767 range.[38]
Performance considerations in the timer and add-on systems focus on low-overhead design for real-time applications, with timer events processed efficiently through the event queue to avoid blocking. For example, multiple timers can be chained for layered animations—such as a master 60 Hz timer triggering sub-timers at 30 Hz—without significant CPU load, as counter increments are lightweight and atomic. Add-ons maintain this by using dynamic loading, minimizing binary size and initialization costs, ensuring suitability for embedded or performance-critical game loops.[36]
Development and Usage
Language Bindings and Interfaces
Allegro provides a primary interface through its C API, which is designed for procedural usage and includes object-oriented wrappers in C++ for enhanced convenience. The library provides headers such asallegro5/allegro.h for the core functionality and addon-specific headers like allegro5/allegro_image.h. This structure facilitates seamless integration into C and C++ projects, with the C API serving as the foundation for all bindings. Developers include these headers in their code while linking against the compiled library.[39]
Official bindings are available for Python, utilizing ctypes to directly interface with the C API functions without requiring compilation of custom wrappers. Community-maintained bindings extend support to languages including Lua (via projects like allua and lallegro), D (DAllegro5), Go (go-allegro), C# (Allegro.Bindings), Java (jallegro), and Scheme (Chicken Scheme bindings). Additional community efforts include examples of JavaScript integration through Emscripten-based web ports that compile the C API to WebAssembly for browser-based applications. These bindings typically mirror the C API's structure, enabling cross-language access to Allegro's features while handling language-specific memory and type conversions.[40]
Usage in Allegro follows procedural paradigms, beginning with initialization calls such as al_init() to set up the core library, followed by addon installations like al_install_keyboard() for input handling. Programs typically implement an event loop using al_create_event_queue() to register sources (e.g., timers, displays) and process events via al_wait_for_event() or al_get_next_event(), ensuring responsive multimedia applications. Cleanup involves paired uninstall functions, such as al_shutdown_system(), to release resources properly. Thread-safety is managed through thread-local state, with guidelines recommending the use of al_set_target_bitmap() to specify per-thread rendering targets and avoiding concurrent access to shared resources without synchronization.[39]
Best practices emphasize robust error handling, as most al_ functions return boolean values indicating success or failure, allowing developers to check and respond to issues immediately after calls. Resource management adheres to an install/uninstall pattern for subsystems and explicit creation/destruction for objects like displays and bitmaps, preventing leaks in long-running applications. For bindings, integration methods often involve loading the shared library and mapping C structures to native types, with documentation from each project providing language-specific examples.[39][40]