Sign in to follow this  
Ussyless

Best way to store graphics/images

Recommended Posts

So, my question is, what's the best method of storing images/graphics for use with c++?
short of having easily editable images in formats such as .jpg, .png etc, whats the best way to store them for use in c++?
my thoughts are to use a custom format, but i dont know the first thing about image files

thanks

Share this post


Link to post
Share on other sites
Just out of curiosity, why don't you want to use standard image formats? If you go with a custom, you'll still need to write a tool to convert from a standard format to your own, which seems like a pointless complication to me. You could use a third-party lib like [url="http://openil.sourceforge.net/"]DevIL[/url] or [url="http://www.lonesock.net/soil.html"]SOIL[/url] to do the loading, and be done with it.

If you are dead set on rolling your own, you'll probably want to use a compression algorithm. Here, you have basically two choices: a lossy compression format such as what JPEG uses; the more you compress the image, the more data is lost beyond recovery, leading to the appearance of artifacts in the uncompressed image; or a lossless compression format such as what TARGA uses. Typical lossless schemes will use an [url="http://en.wikipedia.org/wiki/Run-length_encoding"]RLE (run-length encoding)[/url] approach. In RLE, if you have a row of similar-color pixels that is 35 pixels long, for example, instead of storing 140 bytes to represent that row of pixels, you can instead store the color (4 bytes) and the length of the block (1 byte, maybe two if you want to allow runs longer than 255 pixels).

RLE algorithms are fairly simple to write and offer fairly decent loss-less compression, so you could easily devise a format that uses an RLE scheme and a tool that would convert from one to the other.

Share this post


Link to post
Share on other sites
[quote name='Ussyless' timestamp='1313671684' post='4850732']
So, my question is, what's the best method of storing images/graphics for use with c++?
short of having easily editable images in formats such as .jpg, .png etc, whats the best way to store them for use in c++?
my thoughts are to use a custom format, but i dont know the first thing about image files

thanks
[/quote]
A custom image format is needless. In C++ there're several libraries to read certain formats. (uncompressed) TGA format is for example very simple and you could easily write your own loader for this format. PNG is an other good choise due to its freely available libraries over [url="http://www.libpng.org/pub/png/"]here[/url].

Share this post


Link to post
Share on other sites
I'd try implementing a TGA loader - it's quite a simple format with lossless compression via RLE (as JTippetts says). It'll give you a good grounding in the sort of things you'll need to consider if you decide to go with your own format.

Overall, though, I'd say you'll probably want to go with an existing format which offers a good balance between compressed size, image quality and loading time - good enough for your purposes. The benefits of using a common format are obvious.

Why would you write a custom format? Well I suppose you might want to store extra data along with the image (e.g. surface normal data, specular maps, etc.) which needs to be in a specific format for you to load and use efficiently - of course this adds extra complications, and extra work!

There's loads of good info about the Targa format (and a link to the actual spec) on the [url="http://en.wikipedia.org/wiki/Truevision_TGA"]wikipedia page[/url].

Share this post


Link to post
Share on other sites
I dont exactly mind using standard formats, my worry is just that, well, is it really good practice?

I guess, the end user shouldnt really want/need to edit your images

I guess i thought that most serious projects would have their own file formats, and there would be some good knowledge on making my own, but if that's not the case, i'll just use contemporary formats

Share this post


Link to post
Share on other sites
Yes, it is good practice. You want to ease the pathway between the artists and your game as much as possible by using standard formats (or at least well-supported ones; you can write custom exporters for the artists' software if you really need a custom format, but you ought to have a very good reason for needing the custom format because writing exporters can be a tricky process). Every conversion step from a standard format to a custom format opens up another injection point for possible bugs, extra work, and possible misunderstanding leading to wasted time, so unless you have a compelling reason to not use standard formats, it's best to not get too unconventional.
Many projects will use standard formats, but pack all of the data into some kind of data file. You can use third-party libraries like [url="http://icculus.org/physfs/"]PhysFS[/url], which will allow you to treat a ZIP archive as a filesystem; ie, you can pack your data into a ZIP rather than a more easily-accessible directory tree.

Some games might optimize their data into a format that is more quickly streamed from disk. You can write tools to crunch data (geometry, textures, etc...) into basically a large binary blob of data that you can just load from file and dump right into memory. For very large levels, this can speed load times, but the implementation of it can be tricky and if you're just starting out, you're not going to need that kind of optimization.

Now, some people want to use obscure formats solely for the purpose of protecting their valuable assets from "theft". This is a waste of time an resources. A portion of your players won't care about hacking out your assets, and the ones that do won't be stopped by a custom format, since the program code necessary to decode the format is right there where they can see it, inside the executable or DLLs. Just look at how easily Blizzard's MPQ format was spec'ed out and decoded by Diablo 2 modders. Introducing complication to the code-base and workflow solely for the purpose of obfuscation of assets simply is not practical.

Share this post


Link to post
Share on other sites
[quote name='Ussyless' timestamp='1313678211' post='4850786']
I dont exactly mind using standard formats, my worry is just that, well, is it really good practice?

I guess, the end user shouldnt really want/need to edit your images

I guess i thought that most serious projects would have their own file formats, and there would be some good knowledge on making my own, but if that's not the case, i'll just use contemporary formats
[/quote]

As a general rule of thumb, I would suggest using DDS instead of other solutions as it has several benefits:

1. All newer video cards directly support it (well Dx9c+) so you get the compression benefits both on disk and in video memory. You only have to decompress if the card in question doesn't support it.
2. Most of the time, if stored in something like PhysFS, they get some amount of additional compression on disk. Not nearly as high as JPG but reasonable.
3. If you ever need to do level of detail, DDS supports reversed mip chains so you can grab just the first part of the file to get the low rez images.
4. There are some really good free and/or open source libraries and tools to support them.
5. If you do run into a case where you have to decompress the texture it is extremely quick.

The only real downside is OpenGL will map the DDS textures upside down as I remember it. That's generally easilly fixed though so I wouldn't worry about it much.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this