On Thu, May 6, 2010 at 5:56 AM, Thomas Fjellstrom
<tfjellstrom@xxxxxxx> wrote:
On May 5, 2010, Trent Gamblin wrote:
> On Wed, May 5, 2010 8:45 pm, Peter Wang said:
> > [trent sent the reply to me only]
>
> Apologies.
>
> > Yeah, ok, OpenAL is decent example. What do you think of the
> > al_get_system_config() approach? It's not really consistent with
> > the graphics subsystem but it's already there.
Just wanted to say, technically, ALLEGRO_OPENGL is different - it's not a graphics driver but a platform-independent display flag specifying whether you require an OpenGL context or not. So if we wanted to do an analogous thing for OpenAL we could do so. In practice, like with OPENGL, it would simply force a specific driver of course.
> It's not pretty but I it gets the job done. But the argument that
> a user might use a platform specific driver in a call to al_install_audio
> doesn't sound like a problem to me, because if it's a binary
> distribution, then it's either going to be the right choice or it's
> not going to work even on the platform intended (and so how well
> made could the game be if the developer makes such a decision?),
> or you're going to have source code so you can simply change a
> line in the source and if they didn't use an specific API calls it's
> going to work anyway (and if they did, then they either had a good
> reason to hard code the driver or we're back at the incompetent
> developer scenario). I personally like having all the choices left up
> to me, so that I can do what I think is right on each platform, which
> could mean one platform gets extra features (I'm thinking of OpenGL
> ES 2.0 vs 1.1 on iPhone where I will use shaders for some extra
> fancy effects) but other platforms don't lose anything.
I can see both sides points. Peter's concern is a valid one. Too many people
hard code things like display driver for no reason other than they don't
know they want AUTODETECT (and assume since they only know windows, the
DirectX driver must be fine).
But limiting options is a valid concern also.
What if we add an audio_flags parameter? For now the only flag would be ALLEGRO_OPENAL and enable the direct use of OpenAL. (Not sure how well that works right now as opposed to simply not using our audio but OpenAL directly... can always improve support and have functions analogous to al_get_opengl_texture and so on)
Also, the config method should be made to work in any case if it doesn't right now. We should not limit options - but in a good API it should not be hard to write working code (as it is in way too many APIs) but instead hard to do wrong things like hardcode a driver you don't really want to.