Unix specifics

Under Unix you usually have two ways of redistributing your binaries. You either pack everything in a single directory, even providing Allegro in binary or source form for the user to compile. Or your program is being packaged separately from Allegro and stored in different paths. For the first case of redistribution, read section "Files shared by Allegro" from the "Dos specifics" chapter to learn more about this.

For the second type, you can ignore redistributing the setup, keyboard mappings and language datafiles, because they will be already installed in the system. This, however, is problematic if you are using get_config_text() to localise your program's text strings.

The problem is that on other platforms you usually mix your program's text strings with those of Allegro (found in the `resources' directory) to create a special language.dat. And it is likely that the Allegro library installed on the user's system already contains a datafile.dat. You can go ahead and still provide your own language.dat file, but this will mean that if Allegro is updated, your language.dat file may not contain all the text strings used by the new version.

Given the slow paced release cycle of Allegro, this might not be a concern. However, if you want to make it easy on system administrators, instead of providing your own `language.dat', you should provide the separate `xxtext.cfg' files it in a separate directory. Then, before showing the strings to the user you can detect the language setting and use override_config_file() with the appropriate localisation file and call reload_config_texts().

In order to locate things like the config and translation files, Allegro needs to know the path to your executable. Since there is no standard way to find that, it needs to capture a copy of your argv[] parameter, and it does this with some preprocessor macro trickery. Unfortunately it can't quite pull this off without a little bit of your help, so you will have to write END_OF_MAIN() right after your main() function. Pretty easy, really, and if you forget, you'll get a nice linker error about a missing _mangled_main function to remind you :-)

Under Unix resources are searched for in many different paths (see above). When a configuration resource is looked for, it is usually tried with the variations `name.cfg' or `.namerc' in multiple paths: the current directory, the directory pointed to by the ALLEGRO environment variable, the user's home directory, one or more global system directories which usually only the root user has access to and any custom paths set up with set_allegro_resource_path(). Text files, like the main allegro config file or a language text translation files are looked for in the following places:

   ./allegro.cfg
   $ALLEGRO/allegro.cfg
   ~/allegro.cfg
   ~/.allegrorc
   /etc/allegro.cfg
   /etc/allegrorc
Binary resources like the language translation files packfile (language.dat) are looked for in:
   ./language.dat
   $ALLEGRO/language.dat
   ~/language.dat
   /etc/language.dat
   /usr/share/allegro/language.dat
   /usr/local/share/allegro/language.dat
Note that if you have installed Allegro from the source distribution with the typical `make install', global files like `language.dat' and `allegro.cfg' will not have been installed. As a system administrator you are required to install them manually wherever you prefer to have them. If you suspect that an Allegro program is somehow not finding the correct configuration file, you could try using the following command:
   strace program 2>&1|egrep "(open|stat)"
The strace program traces system calls and signals. By default it outputs the information to stderr, so that's why we redirect it to stdin with `2>&1'. Since we are interested only in files being (un)successfully opened, we restrict the output of the log to stat or open calls with the extended grep command. You could add another grep to filter only lines with text like `language' or `allegro'.


Drivers JOY_TYPE_*/Linux

The Linux library supports the following type parameters for the install_joystick() function:
See also: install_joystick.
Drivers GFX_*/Linux

When running in Linux console mode, Allegro supports the following card parameters for the set_gfx_mode() function:
See also: set_gfx_mode, GFX_*/X.
Drivers GFX_*/X

When running in X mode, Allegro supports the following card parameters for the set_gfx_mode() function:
See also: set_gfx_mode, GFX_*/Linux.
Drivers DIGI_*/Unix

The Unix sound functions support the following digital sound cards:
      DIGI_AUTODETECT      - let Allegro pick a digital sound driver
      DIGI_NONE            - no digital sound
      DIGI_OSS             - Open Sound System
      DIGI_ESD             - Enlightened Sound Daemon
      DIGI_ARTS            - aRts (Analog Real-Time Synthesizer)
      DIGI_ALSA            - ALSA sound driver
      DIGI_JACK            - JACK sound driver
See also: detect_digi_driver, install_sound, install_sound_input.
Drivers MIDI_*/Unix

The Unix sound functions support the following MIDI sound cards:
      MIDI_AUTODETECT      - let Allegro pick a MIDI sound driver
      MIDI_NONE            - no MIDI sound
      MIDI_OSS             - Open Sound System
      MIDI_DIGMID          - sample-based software wavetable player
      MIDI_ALSA            - ALSA RawMIDI driver
See also: detect_midi_driver, install_sound, install_sound_input.

Unix integration routines


void xwin_set_window_name(const char *name, const char *group);

This function is only available under X. It lets you to specify the window name and group (or class). They are important because they allow the window manager to remember the window attributes (position, layer, etc). Note that the name and the title of the window are two different things: the title is what appears in the title bar of the window, but usually has no other effects on the behaviour of the application.
See also: set_window_title.
extern void *allegro_icon;

This is a pointer to the Allegro X11 icon, which is in the format of standard .xpm bitmap data. You do not normally have to bother with this at all: you can use the xfixicon.sh utility from the tools/x11 directory to convert a true colour bitmap to a C file that you only need to link with your own code to set the icon.



Back to contents