These functions are declared in the main Allegro header file:

#include <allegro5/allegro.h>

al_install_system

bool al_install_system(int version, int (*atexit_ptr)(void (*)(void)))

Initialize the Allegro system. No other Allegro functions can be called before this (with one or two exceptions).

The version field should always be set to ALLEGRO_VERSION_INT.

If atexit_ptr is non-NULL, and if hasn't been done already, al_uninstall_system will be registered as an atexit function.

Returns true if Allegro was successfully initialized by this function call (or already was initialized previously), false if Allegro cannot be used.

See also: al_init

al_init

#define al_init()    (al_install_system(ALLEGRO_VERSION_INT, atexit))

Like al_install_system, but automatically passes in the version and uses the atexit function visible in the current compilation unit.

See also: al_install_system

al_uninstall_system

void al_uninstall_system(void)

Closes down the Allegro system.

Note: al_uninstall_system() can be called without a corresponding al_install_system call, e.g. from atexit().

al_is_system_installed

bool al_is_system_installed(void)

Returns true if Allegro is initialized, otherwise returns false.

al_get_allegro_version

uint32_t al_get_allegro_version(void)

Returns the (compiled) version of the Allegro library, packed into a single integer as groups of 8 bits in the form (major << 24) | (minor << 16) | (revision << 8) | release.

You can use code like this to extract them:

uint32_t version = al_get_allegro_version();
int major = version >> 24;
int minor = (version >> 16) & 255;
int revision = (version >> 8) & 255;
int release = version & 255;

The release number is 0 for an unofficial version and 1 or greater for an official release. For example "5.0.2[1]" would be the (first) official 5.0.2 release while "5.0.2[0]" would be a compile of a version from the "5.0.2" branch before the official release.

al_get_standard_path

ALLEGRO_PATH *al_get_standard_path(int id)

Gets a system path, depending on the id parameter. Some of these paths may be affected by the organization and application name, so be sure to set those before calling this function.

The paths are not guaranteed to be unique (e.g., SETTINGS and DATA may be the same on some platforms), so you should be sure your filenames are unique if you need to avoid naming collisions. Also, a returned path may not actually exist on the file system.

ALLEGRO_RESOURCES_PATH

If you bundle data in a location relative to your executable, then you should use this path to locate that data. On most platforms, this is the directory that contains the executable file.

If ran from an OS X app bundle, then this will point to the internal resource directory (/Contents/Resources). To maintain consistency, if you put your resources into a directory called "data" beneath the executable on some other platform (like Windows), then you should also create a directory called "data" under the OS X app bundle's resource folder.

You should not try to write to this path, as it is very likely read-only.

If you install your resources in some other system directory (e.g., in /usr/share or C:\ProgramData), then you are responsible for keeping track of that yourself.

ALLEGRO_TEMP_PATH

Path to the directory for temporary files.

ALLEGRO_USER_HOME_PATH

This is the user's home directory. You should not normally write files into this directory directly, or create any sub folders in it, without explicit permission from the user. One practical application of this path would be to use it as the starting place of a file selector in a GUI.

ALLEGRO_USER_DOCUMENTS_PATH

This location is easily accessible by the user, and is the place to store documents and files that the user might want to later open with an external program or transfer to another place.

You should not save files here unless the user expects it, usually by explicit permission.

ALLEGRO_USER_DATA_PATH

If your program saves any data that the user doesn't need to access externally, then you should place it here. This is generally the least intrusive place to store data.

ALLEGRO_USER_SETTINGS_PATH

If you are saving configuration files (especially if the user may want to edit them outside of your program), then you should place them here.

ALLEGRO_EXENAME_PATH

The full path to the executable.

Returns NULL on failure. The returned path should be freed with al_destroy_path.

See also: al_set_app_name, al_set_org_name, al_destroy_path, al_set_exe_name

al_set_exe_name

void al_set_exe_name(char const *path)

This override the executable name used by al_get_standard_path for ALLEGRO_EXENAME_PATH and ALLEGRO_RESOURCES_PATH.

One possibility where changing this can be useful is if you use the Python wrapper. Allegro would then by default think that the system's Python executable is the current executable - but you can set it to the .py file being executed instead.

Since: 5.0.6, 5.1.0

See also: al_get_standard_path

al_set_app_name

void al_set_app_name(const char *app_name)

Sets the global application name.

The application name is used by al_get_standard_path to build the full path to an application's files.

This function may be called before al_init or al_install_system.

See also: al_get_app_name, al_set_org_name

al_set_org_name

void al_set_org_name(const char *org_name)

Sets the global organization name.

The organization name is used by al_get_standard_path to build the full path to an application's files.

This function may be called before al_init or al_install_system.

See also: al_get_org_name, al_set_app_name

al_get_app_name

const char *al_get_app_name(void)

Returns the global application name string.

See also: al_set_app_name

al_get_org_name

const char *al_get_org_name(void)

Returns the global organization name string.

See also: al_set_org_name

al_get_system_config

ALLEGRO_CONFIG *al_get_system_config(void)

Returns the current system configuration structure, or NULL if there is no active system driver. The returned configuration should not be destroyed with al_destroy_config. This is mainly used for configuring Allegro and its addons.

al_register_assert_handler

void al_register_assert_handler(void (*handler)(char const *expr,
   char const *file, int line, char const *func))

Register a function to be called when an internal Allegro assertion fails. Pass NULL to reset to the default behaviour, which is to do whatever the standard assert() macro does.

Since: 5.0.6, 5.1.0

Allegro version 5.0.10 (GIT) - Last updated: 2013-06-16 03:02:19 UTC