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

[Bob <ohannessian@xxxxxxxxxx>]

Shawn Hargreaves wrote:

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


I'm against removig the mixer. I am for some option somewhere to disable it 
though. Some programs (emulators, DUMB) already do their own mixing, and can 
support just about every sound card configuration you throw at them. Adding 
the Allegro mixer over that is a waste of CPU cycles. It would also open the 
way for mixer add-ons.


[snip]

> 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).


Then every time we need to add a new capability, we need to either change 
existing functions (not nice), or add new ones (bloat). Just MHO though. I 
like Allegro how it is, but I hate to see the kludges put in place (like 
text_mode() you mentioned, or having vertain numbers have special meaning in 
certain circumstances).


> 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!)


Why can't Alert use the user settings? Or am I missing something?

[snip]



--
- Robert J Ohannessian
"Microsoft code is probably O(n^20)" (my CS prof)
http://pages.infinit.net/voidstar/