No external libs, just plain source. Looks great? I use it myself, works very nice. =)
The author has no problem with users including them in their own projects, of any type:
"Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:"… and the restrictions is very easy to follow.
I’ve had a look at LodePNG before, and it seems very nice. If we were going to keep the image loading part of the API then I would definitely consider using it. However, that part of the API will be removed in 3.0.
Probably something like monitor enumeration and selection, multiple windows, OpenGL 3.0 support, error reporting facility, better support for C++ and yet to be determined input system improvements.
Also some things that other libraries do better will be going away, like the current, primitive image loading facility.
Mostly because people keep mistaking it for a serious image loading facility and make feature enhancement requests like the one that started this thread. There are already wonderful libraries available for loading images in all manner of formats, so people are much better off using them than being distracted by a silly Targa loader in GLFW.
I certainly agree that the GLFW should be focused more on what it is intended for and not superfluous features. However, having a common API for loading images, displaying text, ect can be very useful for quick project development. Have you ever thought about separating the project or having a side API which works along the GLFW to do those types of things?
There already exist (multiple) other APIs which work along side OpenGL (and thus implicitly GLFW) to do each of these things. Here’s a good list: http://www.twilightsembrace.com/personal/gamelibs.php (see the section titled Image and Font Handling)
With so many good libraries out there, why create and maintain a "GLFW version" of each of them?
Ok, suppose the glfw team decides to add/incorporate x image loading facility in their framework.
1) There are already TONS of image loading facilities out there which makes it very redundant.
2) If they used another library (which, more or less will be), more dependencies = more compliation problems
…2b) If they happen to use another library which is source only,
…For the case of stb_image, it does load png, jpeg and bmp but do you know that it doesn’t support interlaced png and progressive jpeg? eventually, people will request support for it…
…In any case, they’ll have to support more code and some people may wonder/complain why they’re not using the “official” implementations.
3) there will always be something lacking. Soon people may not just request for an image loading facility but also an image AND texture loading facility.
4) Evenually, there will be requests left and right on supporting image format y.
Ok, suppose the glfw team decides to add/incorporate x image loading facility in their framework.
1) There are already TONS of image loading facilities out there which makes it very redundant.
2) If they used another library (which, more or less will be), more dependencies = more compliation problems
…2b) If they happen to use another library which is source only,
…For the case of stb_image, it does load png, jpeg and bmp but do you know that it doesn’t support interlaced png and progressive jpeg? eventually, people will request support for it…
…In any case, they’ll have to support more code and some people may wonder/complain why they’re not using the “official” implementations.
3) there will always be something lacking. Soon people may not just request for an image loading facility but also an image AND texture loading facility.
4) Evenually, there will be requests left and right on supporting image format y.
I do agree with removing image loading from the next version of GLFW, even though the TGA loading functions were extremely convenient. The bad news for me was that I had never found a _small_ library for doing image loading that had a license I liked, so thanks to jda for pointing me to stb_image…that is an awesome bit of code!
<Shameless Plug>
I’ve taken stb_image and extended it a bit to handle TGA and DDS loading. I also put some helper functions for loading images directly to OpenGL textures, compressing to DXT1/5 on the fly (very fast, decent quality), inverting the image, pre-multiplying alpha, etc). The resulting library is a nifty little C library I’m calling the “Simple OpenGL Image Library”. All source code for SOIL is in the public domain. Here’s the address: http://www.lonesock.net/soil.html
</Shameless Plug>