SOIL VS FREEIMAGE?

[Ashenwraith]

I have to add support for a new/preexisting image format (no I can't convert it with another program).

Should I use SOIL or FREEIMAGE?

Free image has one of the formats I need in it, but it also has pallete support (which could be useful).

SOIL is small and already in SFML, but it's rarely updated. This might be a problem with newer dds formats as well(?)

[Laurent]

What do you need exactly? Which format are you interested in?

If you use SOIL, you will not get anything that SFML doesn't provide already.

[Ashenwraith]

Right, I'm talking about extending the existing code.

Either way I'm going to have to write code.

There's some new formats I need to read.

[Laurent]

But why are you talking about SOIL if you need new formats?

What do you mean by "extending the existing code"?

[Ashenwraith]

I have some new image formats that are not covered by existing loaders--including freeimage (But freeimage does have a plug-in system and lots of other image support, that's why I was curious about your opinion of freeimage VS SOIL).

I don't necessarily mean 'extend classes', but instead of using fstreams/etc and building my own pixel array I should create the code for SOIL(and then SFML) to handle these files.


For example games are using sff to store their images/palletes:

http://delphi.pjh2.de/articles/graphic/sff_format.php

Code: [Select]


Bytes
00-11  signature [12]
12-15  1 verhi, 1 verlo, 1 verlo2, 1 verlo3 [04]
16-19  Number of groups [04]
20-24  Number of images [04]
24-27  File offset where first subfile is located [04]
28-31  Size of subheader in bytes [04]
32     Palette type (1=SPRPALTYPE_SHARED or 0=SPRPALTYPE_INDIV) [01]
33-35  Blank; set to zero [03]
36-511 Blank; can be used for comments [476]

SUBFILEHEADER (32 bytes)
-------
Bytes
00-03 File offset where next subfile in the "linked list" is [04]
      located.  Null if last subfile

04-07 Subfile length (not including header) [04]
      Length is 0 if it is a linked sprite
08-09 Image axis X coordinate [02]
10-11 Image axis Y coordinate [02]
12-13 Group number [02]
14-15 Image number (in the group) [02]
16-17 Index of previous copy of sprite (linked sprites only) [02]
      This is the actual
18    True if palette is same as previous image [01]
19-31 Blank; can be used for comments [14]
32-   PCX graphic data. If palette data is available, it is the last
      768 bytes.

Right now I'm just trying to read in the content, not sure if I should do something hackish like internally convert each image to a PNG in SOIL or something like that.

[Laurent]

If the format contains multiple images, it won't be compatible with the existing libraries, because you need an extra parameter in addition to the filename.

Anyway, I'm not sure if modifying SOIL would be a good idea. You should just write your own decoding function that returns an array of pixels, and use Image::LoadFromPixels.

Later there will be plugins in SFML, so that this kind of stuff will be integrated better.