RE: [AD] Proposed changes for Allegro 5 (6?)

[Shawn Hargreaves <shargreaves@xxxxxxxxxx>]

Title: RE: [AD] Proposed changes for Allegro 5 (6?)

Angelo Mottola writes:
> > - Switch to completely disable the Allegro mixer, and send
> audiobuffers to the sound card directly. (TRAC)
>
> Hum, I'm not a sound programming expert, but removing our
> software mixer wouldn't mean to loose a lot of functionalities?

It would make it much harder to write drivers for devices that
can't do good mixing themselves (eg. most of the DOS and Unix
sound drivers). The mixer isn't a requirement, just a set of
helper functions that drivers can use if it makes their job
easier. Allegro never talks straight to the mixer code: the
framework tells the driver what to do, and then some drivers
can choose to pass some of those requests onto the software
mixer. What's the problem with that? And if you lose the mixer,
how do you write drivers for devices that can't do mixing
themselves?

> > - merge blit and sprite API
>
> I agree, but how to recognize when to draw a transparent
> bitmap (sprite) or a solid one? What about using al_set(AL_BLIT,
> AL_BLIT_TRANS) or al_set(AL_BLIT, AL_BLIT_SOLID)?

My general advice is to avoid putting this kind of persistent
state into the API. Or if you are going to do it, do it totally
(like OpenGL) so that every single operation is split up into
many very small single-parameter function calls. Allegro isn't
really built like that, though, so I think it is better to avoid
having state at all. Pass parameters to functions to tell them
what to do, or if it is such a commonly used routine that this
will be a pain, split it into a family of related functions.

My experience has been that every time I did put in something
with persistent state (the text_mode() function being a prime
example), it caused problems and confusion down the road, and
I ended up wishing I hadn't done that (eg. it would be better
if the background color was always passed to text drawing
routines along with the foreground).

Persistent state causes particular problems for addon packages,
but also when other parts of the lib may need to change it
(eg. calling alert() alters some settings that the programmer
may not expect to have changed - it is loads of hassle and
housekeeping if alert() needs to track that and put the values
back when it is done!)

> > - Configuration via an OpenGL-like al_set(variable, value) system
> > - prefixing of the API
>
> Agreed on both. Al_set() could be a really powerful tool, and it would
> also give a nice side-effect: in some cases adding new features will
> just mean adding more variables/values, without overbloating (tm) the
> API with more dedicated functions.

The config routines can already do this, and were intended to support
exactly this kind of runtime setup. They could do with a nicer API
for setting multiple values on the fly, though, and maybe better docs
explaining how you can use them for such things (a _lot_ of the drivers
have settings that can be tweaked at runtime by programs using the
config override routines).

> Ok for FLI and compiled sprites, but keep the rest. Dunno about the 3d
> math, but if kept it should be possibly modified to be compatible with
> OpenGL (see matrices).

That's a tough one because whichever way around you put it, it will
be wrong for one of D3D or OpenGL. I don't think this is much of
a problem, though, as it is trivial to write a "set my X format matrix
to API that uses Y format" wrapper, and this doesn't happen often
enough for flipping the row/axis order to be a measurable performance
hit.

--
Shawn