Less formats vs less dependencies ?

[Laurent]

Hi

I've found a tiny library for loading and saving some image formats, which I could directly integrate to the SFML source code. It would remove the dependency to DevIL and zlib, but not all the formats currently supported would still be there.

However, the supported formats would be the most common ones :
- BMP
- TGA
- JPG
- PNG
- DDS

I need to know what is the most important for you : being able to manipulate uncommon image formats, or having less external dependencies ?

Thanks

[Lord Delvin]

Voted yes:

I think it would be good to have less dependencies, but I also think, that, as you are using DevIL, you wont be able to add this dependencies' functionality in an accaptable amount of time, so I wont suggest to move away from devil.

If you have portable code to load and save these formats and to take screenshot, remove DevIL.
Have fun!

[dunce]

Why not use FreeImage instead of DevIl? Its license allows static linking. And it supports most common image file formats. I guess it will require libpng and libjpeg. Those libs' licenses allow static linking as well. Thus we can avoid using devil.dll that is lgpl-ed and requires dynamic linking.
BTW, sound lib dependency still remains. I mean OpenAl distribution pack.

[DrEvil]

I'm trying to get away from dependencies, as I have a somewhat unique project where I can't depend on an installer to install files to the path, and since no dependencies ever allow you to control what folder they load from I need to avoid them. I would very much like to see a version stripped of its external dependencies(dlls), even if that meant slightly reduced functionality.

[dabo]

If the only things we loose are some uncommon image formats, I'm all for it.

[PM]

Most projects only need one format anyway. For games, most of the times, it's TGA.

And if some project requires as many as possible formats - they can set up DevIL (or some other library) on their own, imho.

EDIT: Perhaps, you should allow some conditional compilation with preprocessor macros? That way, you could actually support more than one common image library (not at the same time, of course).

[acrin1]

I'd be fine with less file formats. I really only use PNG and BMP. The fewer DLLs or additional files that need to be shipped with an SFML application or game, the better.

[DrEvil]

Laurent, what library specifically were you thinking of using? I'm very interested.

[Laurent]

I'd like to use SOIL, without the OpenGL stuff. This code is itself based on the stb_image source code. Both of them are public domain.

I'm also interested in stb_vorbis (from the same author as stb_image), to get rid of libvorbis.

[DrEvil]

That sounds great.

[dabo]

Again, will we only loose support for some uncommon image formats? or will we also loose some image manipulating functions?

[Laurent]

No, just formats. I'll change only the load / save code.

[DrEvil]

Also get loading from memory too as part of it, nice. Can load from archives and such with it. I converted my local copy of SFML to use SOIL and it was very simple.

[CareBear]

TGA and/or PNG.
Both support alpha channels, are free, lossless and easy.
The last one supports better compression (zlib).

Nothing more, because at least one of them should fit any needs.
BMP and JPG are uninteresting because they don't have an alpha channel. Something about JPG, who wants textures with artifacts?

About dds... well... i can't say much about it, but it seems good.

[PM]

JPEG is a good format for saving screen-shots (for games that have this kind of functionality).