RE: R: R: R: [AD] Allegro 5 new config routines, alpha 1

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Sven Sandberg writes:
> I presume this means that some config variables are in a 
> config file on disk, while others (like these) only exist 
> in memory? Why?

It opens up the config system from being only useful for the user
to set preferences, to a general means of communication between
the program, library, and drivers.

This already sort of happens, and I think is a natural evolution
from supporting config options at all. If you have a driver that
allows the user to set options with config variables, it is
natural that other bits of code may also want to control those
same options of that driver, so why not make the same mechanism
available to both users and other functions? (otherwise the
driver would have to implement and document multiple paths for
the same functionality).

The existing override system sort of more or less allows programs
to control drivers in this way, but is ugly and confusing and not
very flexible: it occured to me that it would be good to make
this nicer, and then that if it could be made nice enough, it
might be a quite generic solution for a lot of library to program
communication.

> What's wrong with 
> 
>     if (al_get_gfx_capabilities() & AL_GFX_CAN_TRIPLE_BUFFER) {
>         ...
>     }

Nothing at all. But there are a lot of far more obscure options,
many of which only apply to specific drivers on specific 
platforms, or which only a very few people would ever care
about. Exposing each of these as functions seems nasty to me
(huge numbers of trivial functions with one-line implementations,
namespace pollution, and massive problems with binary 
compatibility between versions), and global variables are out
as they cause their own set of portability and compatibility
problems.

If the library just provides get, set, and hook functions, addons
and drivers can be free to expose a huge mess of specialised
things that only they care about, without endagering binary
compatibility, without cluttering up the primary top level API,
and also because all this would be runtime linked it would
be trivial for programs to give up gracefully on other platforms
that don't provide whatever they are trying to use.

Eg. rather than all the non-Windowed mode implementations having
to provide dummy "is_this_windowed" functions that always just
return false (there are already a lot of such dummy routines,
and in danger of soon being an explosive number of combinations
of them), how much nicer it would be if platforms that are 
windowed can expose info about it, platforms that are not can
just ignore the whole issue without writing any code at all,
and programs can query this at runtime by checking
al_get_bool("system/is_windowed") and seeing if this is set or
not.

I don't feel especially strongly about it, but I do think it might
help to tidy up the API a bit, while still allowing a way for
drivers and modules to expose lots of gory inner details.


-- 
Shawn