SFML community forums
General => General discussions => Topic started by: Laurent on October 27, 2007, 05:35:58 pm
-
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 :)
-
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!
-
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.
-
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.
-
If the only things we loose are some uncommon image formats, I'm all for it.
-
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).
-
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.
-
Laurent, what library specifically were you thinking of using? I'm very interested.
-
I'd like to use SOIL (http://www.lonesock.net/soil.html), without the OpenGL stuff. This code is itself based on the stb_image (http://www.nothings.org/stb_image.c) 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.
-
That sounds great.
-
Again, will we only loose support for some uncommon image formats? or will we also loose some image manipulating functions?
-
No, just formats. I'll change only the load / save code.
-
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.
-
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.
-
JPEG is a good format for saving screen-shots (for games that have this kind of functionality).
-
Mh, i dislike games which only produce jpeg screenshots. Because often the red becomes very blurry.
-
I'm not arguing about the quality. But I'm currently working on one game (it was started WAY before SFML first release, so it doesn't use it) and it's a network game and people often want to post screen-shots (their achievements) on the forum. JPEG are the perfect formats for that.
You have to keep in mind, that some of your game fans might not be IT professionals, so to speak. They might not know how to manually convert picture formats and/or shrink images. So a user-friendly way of doing things is to create screen-shots of the appropriate size and format for the web.
One might argue, that PNG is just as good for the web as is JPEG. However, some older Internet browsers have crappy support for PNG, and unfortunately, we have to keep that in mind.
-
SOIL supports plenty of the major formats, so I hope it gets to replace devil in SFML. Because I am impatient I went ahead and replaced devil with it in my local copy of the code and it was very simple. Now I'm free of external dependencies(I'm not using the sound libraries atm).
-
PNG is realy the only format im using so im all for a change :)
-
did you know that you can get similiar, and sometimes better compression if you use tga files and compress them using b2zip library?
i store all my textures in tga and put them in a bz2 compressed archive.
bzip2 is completely ansi-c and can be easily compiled and statically linked. i even managed to throw all bzip2 c files into one singe c-file, so i only need to add that single c-file to my project.
about openAL. you can make a static linkable version of that one, too. you will loose native hardware acceleration, though. but if you are fine with openAL generic software and hardware modes, you can just link it statically (with some minor modifications to the source code)
about less image formats: strong vote for NO EXTERNAL DEPENDENCIES!!! if possible.
and memory loading is an absolute must have! i load all stuff from a compressed archive, and do not want to be forced to first write stuff to harddisk to be able to load it. everything in SFML should be also loadable from a memory location. very important!!
i have looked into the stb_image.c source - it allows loading from memory. but it has an ugly c interface. so combining stb_image with SFML sounds like the perfect idea!! cant wait to see a new SFML released!
p.s. really nice project. i love the simplicity of the network stuff. its so nice that i now finally think i will try out to add networking to my little game.
-
Finally I got rid of all dll dependencies except OpenAl distribution pack. LGPL-ed libs that required dynamic linking have gone. I use static linking for everything including VC8 runtime libraries. From now on I can distribute just an exe file and game assets.
-
From now on I can distribute just an exe file and game assets.
You could make a package, hardcode it and then load it from memory :twisted: