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.
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
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
Author
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
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.
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...
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/
What's the problem with Devil's licence, out of interest? (IIRC it uses LGPL.)
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 ;)
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.
Author
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!
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!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
