This topic is 2305 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hey GameDev, I have a couple of questions for you guys:

So I've done a little research on the topic and looked into some various solutions regarding texture loading. Here are my preliminary results:

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 ;)

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.

Writing my own loaders is an attractive idea, but I haven't been able to find a good source to learn from. If you guys have any good resources for that I would love to chase that down. Time isn't an issue, just whether or not it's a feasible endeavor to take on myself.

What are your guys' opinions? I understand this question has been asked many times, but it's always nice to hear new view points.

##### Share on other sites
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

##### Share on other sites
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.

##### Share on other sites
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

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

##### Share on other sites
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...

##### Share on other sites
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/

##### Share on other sites

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.)

##### Share on other sites
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.

##### Share on other sites
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!

##### Share on other sites

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 ); 

##### Share on other sites

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?

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).

##### Share on other sites

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).