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

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


Shawn Hargreaves wrote:
> > 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, 

OK, I see it can be useful for setting flags that only apply on specific
sub-systems like drivers or platforms. But it seems like a kind of
strange way to access variables in general: Wouldn't it be better to
keep variables as variables if they apply on most platforms and may be
used frequently as "real" variables?

What makes me want to restrict the use of config variables is that
things like current color depth and gfx_capabilities are likely to be
used often, in time-critical situations, and from assembler, in which
case I think it would be better to keep them in variables or simple
inline functions. Plus, the C language does have variables built in
(with compile-time name and type checking) so I can't help thinking that
it seems a bit weird to try to emulate them with strings...

Even if people don't agree with my point of view, I think at least we
should agree on where to draw the line. E.g., it would certainly be
possible to do:

   al_set_bitmap("draw_sprite/source", my_sprite);
   al_set_bitmap("draw_sprite/dest", my_bmp);
   al_set_int("draw_sprite/x", x);
   al_set_int("draw_sprite/y", y);
   al_call("draw_sprite");

but it doesn't strike me as a very good idea :-)

> 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,

All right, it can be good to hide things that are very seldom used. But
I get the feeling that people try to put more or less everything in
these config files, which I would like to hear some good argument for
before I believe in. ("We can do it" doesn't necessarily imply "We
should do it".)

-- 
Sven Sandberg    svsa1977@xxxxxxxxxx    home.student.uu.se/svsa1977



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/