Choices for Texture Loading

People will tell you not to reinvent wheels, but writing your own can be an enriching experience.
But it depends on what types of files you want to support and how dedicated you are at maintaining your code, because you will constantly find a version of a file that you can’t load.

My engine loads .PNG, .BMP, .TGA, .GIF, and .LSI (proprietary), and all of these loaders were written from scratch by studying the image formats via online documents.
So start small, study online format descriptions, and go from there.
Start with .BMP and .TGA. Award yourself extra credit for making loaders for the rare formats such as indexed.

You can write loaders for both of these in a day. Then move on to GIF, and then PNG. JPEG is not far from PNG (I simply haven’t had the time to make a loader yet).


L. Spiro

Haha well after just opening up the PNG spec documentation, I have a lot of respect for you. But I think I'll foolishly trek down the path of writing that code, thank you.

On this I very much side with L. Spiro.

Writing a loader yourself will be a very good experience. PNG / JPG loaders are not as hard as you might think. Most (sane) people will tell you to use the jpeglib for loading compressed JPG and libpng / zlib for loading PNGs.

The TGA format is a very good format to start with. Try and write a loader for non-compressed TGA and RLE compression. You should be able to have that running after a few hours starting from scratch.

If you need help - Just ask

IMHO, the only image format that an engine needs to support is DDS.
The engine's data pipeline however, should support suitable interchange formats.

Put frankly, there is only one "format" worth dealing with in a game or 'engine' and that is DDS with either DXTn/BC compressed data or uncompressed data. If you don't like the DDS header format for whatever reason then you could wrap the compressed data in your own header.

You'll more than likely want to be using compressed textures on the graphics card anyway and going from JPG to DXTn is just lossy to lossy and not worth it.

PNG is effectively a zipped image file so you don't want DXTn/BC compressed data for whatever reason just use a zip compressor/decompressor (such as zlib) to compress the file to remove the 'load from hard drive' bandwidth option.

BMP is worth less, TGA is decent as a source image but not something you really want to consume in game and GIF has never been a 'game' format.

Also, all the various image formats have varying ideas on what is 'bottom-left' of the image, so in order to get consistant results you'd need to rotate them anyway otherwise your model textured with a raw bitmap is going to look all kinds of broken when you realise you want to DXTn/BC the texture and the origin changes; nothing makes artists your friend quicker than telling them their UVs are now all wrong...

A friend of mine is doing an open-source project for simple image loading, you can take look at the project including its source here: http://code.google.com/p/tinyimageloader/

DevIL seems to be the most versatile and powerful, but the licence seems to have some caveats regarding distribution and usage. Also it's never fun having someone else write your code and just expect it to work ;)

What's the problem with Devil's licence, out of interest? (IIRC it uses LGPL.)

I second (or, I guess I should say, I third) the DDS support. If you want/need to write your own DDS loader, that's fine, but for your offline tools that you use to build the DDS assets from other formats, you should probably just use whatever third party library is easiest. Seriously, if your goal is to make games, why would you want to waste time writing a bunch of boilerplate code that has already been written countless times over? If you have some kind of fascination with formats, maybe it's okay, but really... once you understand the basic differences between lossless/lossy compression, pick up a few things about run-length encoding, and what have you, there just is really no point in the exercise.

Haha a lot of replies in here now!

I absolutely agree that the most important image format is DDS, I've used it before and have seen the magic it does for memory. But texture formats are something that I'm not too familiar with, and I would like to define some sort of asset pipeline that can go to an engine format, even if that's a thin layer over DDS, simply because you never know if I may need to change it in the future or some other limitation. Maybe a little paranoid, but I'm aiming for flexibility. That was a random tangent. But moral of the story is that I have time to work on these mundane tasks, and the education will only benefit me.

And thanks 0x3A, but now I'm starting down this path, it's hard to turn around ;)

And mdwh, that is the problem. Now I'm okay with being wrong about this, so don't hesitate to correct me, but the president of the company I work for now warned me against adding any LGPL code to my engine, due to the fact that I may have to release my source code, which is an impossibility if I'm working on something with confidential code, like Xbox, PS3, Wii, or anything like that, and that is absolutely where I would like to head one day.

Thanks for all of the replies!

SOIL seems to be simple and easy to set up, but there seems to little to no documentation or tutorials for it, but if someone has an excellent resource for that, I might look into it.

There aren't any tutorials precisely because it is that simple. The documentation is in the header file, there are only about 5 functions you need to use, and they are all pretty self-explanatory... Hell, I think the one-line example from the SOIL home-page says 90% of what you need to know:

/* load an image file directly as a new OpenGL texture */
GLuint tex_2d = SOIL_load_OGL_texture
(
"img.png",
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAG_MIPMAPS | SOIL_FLAG_INVERT_Y | SOIL_FLAG_NTSC_SAFE_RGB | SOIL_FLAG_COMPRESS_TO_DXT
);


And mdwh, that is the problem. Now I'm okay with being wrong about this, so don't hesitate to correct me, but the president of the company I work for now warned me against adding any LGPL code to my engine, due to the fact that I may have to release my source code, which is an impossibility if I'm working on something with confidential code, like Xbox, PS3, Wii, or anything like that, and that is absolutely where I would like to head one day.

I think your president may be mixing up the LGPL with the GPL; I wonder has he actually even read the text of either license?

Summary here: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

The main difference between the GPL and the LGPL is that the latter allows the work to be linked with (in the case of a library, 'used by') a non-(L)GPLed program, regardless of whether it is free software or proprietary software. The non-(L)GPLed program can then be distributed under any terms...[/quote]

Many software licenses which are initially percieved as "free" are actually quite a bit more permissive than the standard GPL when you look closer at them; even Microsoft used libjpeg in earlier versions of Internet Explorer (and acknowledged the fact on it's splash screen or Help/About screen - can't remember which).

I think your president may be mixing up the LGPL with the GPL; I wonder has he actually even read the text of either license?

It's not that unusual for workplaces to ban the LGPL as well as the GPL.

In particular, the LGPL specifies that the end user must be able to re-link against a newer version of the library, which is impossible on most consoles/embedded platforms, since they don't have any such concept of dynamic linking (nor generally the level of user access that would be required to replace the library in question).