Adding PNG support, new free decoder found!

nobody wrote on Thursday, July 05, 2007:

Hello!

Since PNG is so widely used, why not support it in glfw?
I know there are libraries that users can include themselves, but check this:
http://members.gamedev.net/lode/projects/LodePNG/

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.

oh, and the image data needs to be switched first.
While I don’t understand it myself, I found code for that also, using this loader. Its simple stuff:
http://www.koders.com/c%2B%2B/fid156394DDF1E6206749BAC2524EDCE1C1F1889D54.aspx

Just some help. =)

/Rickard Sandgren

elmindreda wrote on Thursday, July 05, 2007:

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.

nobody wrote on Friday, July 06, 2007:

Ah, oh well. =]

Btw, care to spill what milestones is planned for 3.0? =)
/Rickard

kohaistyle wrote on Friday, July 06, 2007:

What ??? remove the TGA loading facility ???
How come ? it’s just a simple, nice and useful feature. WHat can justify dropping it out ?

elmindreda wrote on Friday, July 06, 2007:

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.

elmindreda wrote on Friday, July 06, 2007:

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.

nobody wrote on Wednesday, July 11, 2007:

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?

melekor wrote on Wednesday, July 11, 2007:

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?

nobody wrote on Wednesday, July 25, 2007:

Why not just use a separate library for imageloading?

I highly recommend stb_image, found at http://mollyrocket.com/forums/viewtopic.php?t=315
It’s very lightweight and supports jpeg, png and bmp, and the code is public domain.

/jda

snt2k wrote on Sunday, August 19, 2007:

I think you’re missing the point here…

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.

Anyway, just my 2 cents.

snt2k wrote on Sunday, August 19, 2007:

I think you’re missing the point here…

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.

Anyway, just my 2 cents.

elmindreda wrote on Sunday, August 19, 2007:

Yes, those are pretty much the reasons its going away. Thank you for summarising.

lonesock wrote on Tuesday, August 21, 2007:

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>

Jonathan

elmindreda wrote on Saturday, September 01, 2007:

That’s excellent ^^ Will definitely have a look at that. A nice alternative to point to would be very valuable indeed.