This questions was probably asked previously, so excuse my ignorance, however here it is:
In your opinion what is the best API to use for audio, input and windowing system integration and OpenGL. I have had a look at clanLib and SDL, but both of these aim at being more than a simple input/output library and do not focus specifically on OpenGL.
What I am really after is a library that will handle my input i.e. keyboard, mouse and joystick and that would take care of creating my OpenGL rendering contexts for me. On the audio side I’d rather stick with implementing OpenAL calls myself and I would rather manage all of the OpenGL stuff myself too (although clabLib’s state saving looks handy). Support for loading image files is also essential.
I keep dreaming of the day when we have OpenIL for input, OpenNL for network, together with OpenAL and OpenGL, giving us a seemless cross-platform (open source) solution. Maybe I need a CAT scan…
And let’s not forget OpenWL for windowing!
GLFW, GLUT, freeglut etc. are ok but they have certain problems. It essentialy boils down to the fact that they try to be a generic framework rather than a specific library. The term framework is not very well defined, that is, what goes in a framework depends on the given application. This can either lead to sometinhg SDL-like wich tries to do everything one might need and thus to bloated and complex software, where each application typically uses a small fraction of it, or something glfw-like or glut-like, which tries to provide certain often-used (but still completely irrelevant) services, like windowing and input abstraction but also provides some very basic (and useless except for simple demos and games) services like loading textures from tgas (see glfw) “for convenience”. All this leads you the user to link to a few libraries with mostly overlapping and sometimes incomplete apis and I personally don’t like any of this (although GLFW seems to be the best and very useful in many cases). On the other hand a set of libraries like RadicalHumility suggests would not have any of these problems. They would be small and simple and hence easy to debug and port, and provide calls to abstract certain common things wich are differently implemented by different platforms (like windowing, input etc.) without making any assumptions on how you’ll be using them (by e.g. hiding the rendering context behind the window) and without each providing a little bit of the other’s functionality thus wasting development and debugging time.
Ok things might not be as tragic as I’m implying as most users will be perfectly content with what GLFW or glut or whatever provides, but seperate libraries for seperate things would be pretty cool nevertheless.