A few remarks about the draft spec:
* "Compiling and Linking": Although specifying "-lalut" before "-lopenal" on
the linker command line is a cunning idea to handle the current library mess
on *nices for *static* linking (entry points in the former shadowing entry
points in the latter), I'm not convinced that it will necessarily work for
dynamic linking. But I'm not an expert on the details of dynamic linking on
various platforms...
* Context handling: I fail to see the reason why we should introduce
functions like alut{Get,Set}Context and use int handles for contexts. The
OpenAL situation is fundamentally different from the OpenGL one: There is an
explicit, portable API (ALC) for handling devices and contexts, including
completely portable types to represent these. This not at all the case for
handling windows (part of GLUT's task), where every platform/toolkit has its
own functions and types and GLUT wants to hide these differences. So I
propose to remove these redundant ALUT functions and simply use the ALC
functions and types. Don't push the similarity to GLUT far...
* Error handling: We should *really* follow OpenGL/AL/ALC here and specify
that a) The first error sets the internal error state b) Subsequent errors
are not recorded if an error is already recorded c) alutGetError clears the
internal error state. Everything else would be highly confusing.
Furthermore, an alutReportErrors(void) mirrorring glutReportErrors(void)
might be handy.
* We have 2 different ways of handling different file types
(alutCreateBufferFromFile{,Image} and alutLoadMemoryFromFile{,Image}), where
the former might be able to handle more formats than the latter (see
discussion yesterday). So the question is: What does
alutEnumerateSupportedFileTypes() mean then?
* As mentioned, several times already, I think that making all the
attributes visible as parameters to alutLoadMemoryFromFile{,Image} is a very
bad idea and will definitely hurt us sooner or later. I can add my proposal
to the Wiki to see the differences, if that is wanted.
* It is OK to specify file names as "const char*", but I propose to change
the memory buffer parameters to "const void*" and "size_t". (As a side note,
please remember that POSIX file names are not sequences of characters, but
sequences of bytes. This is a serious flaw in POSIX when it comes to
displaying file names under different locales, but in C there is no real
distinction between bytes and chars, anyway. :-( )
* "Built-in Sounds": Good idea, but I propose to unify the 3
alutCreateBufferFOOWave functions into a single one with an additional
parameter specifying the wave form. Perhaps we can even merge these 4
parameters into struct then and pass a const pointer to that struct, this
looks even cleaner to me... (keep related things together, opens up more
flexibilty, etc. Downside: One more line of code to initialize the struct,
but that's not really an issue.) Again, I'd like to change the Wiki
regarding that if it's OK...
Cheers,
S.
|
