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.
So what are you thoughts?
Thanks in advance.
I found GLFW very good for input, windowing, threads and loading tga files. It is easy to use, small, and efficient.
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.
I agree with zen and most of you in that separate toolkits for different tasks are highly preferrable over “complete solutions” such as SDL. In trying to integrate loads of functionality into one unified toolkit, people often neglect the complexity of each “subsystem”.
Sound in itself is a huge field. Just have a look at FMOD or OpenAL - it simply won’t be done as a subset of a larger API (here I completely ignore DirectX - it’s neither portable, efficient, open source nor representative).
When designing GLFW, I try to balance simplicity, minimalism and usefulnes. Its primary functionality is windowing + input (in my opinion, they are so tightly coupled on most platforms it’s not worth the effort to separate the two). While the windowing part of the API is kept very minimalist and inflexible (the focus is fullscreen games anyway), the input API is something I like to elaborate on (it’s already way superior to GLUT in terms of keyboard, mouse and joystick input - IMHO, and many prefer GLFW input over SDL input).
One thing that I felt was necessary for GLFW was the timer - very often neglected in other toolkits (e.g. GLUT and SDL have a resolution of 1 ms - at best), and not easy to write in a portable way.
Most other functionality in GLFW (e.g. the TGA loader routine) was added for convenience for small projects, not to replace other toolkits (such as DevIL).
The multi threading part in GLFW is always a source of debeate: is it motivated? In future versions of GLFW it will become more useful as support for multiple windows and per thread window context appear. Until then it’s just plain useful.