I have developped (with Winane's help) a tool useful for extracting images and sprite informations from a SFF file.
Have a look at my website http://nigaiden.skreel.org/ if you wish to give it a try.

And of course any bug reports, suggestions, or other feedback are welcome. If you have time, please test the program on any suspicious SFF files you have and let us know if the program doesn't handle them properly.

Very usefull tool ; I use it a lot 8)

Thanks

I'm working on a tutorial to fix palette-related problems with Linux Mugen using sffextract.

I'll put it on my website, and I'll announce it here when it's ready.

I edited your program it a bit to add a new option (-X) that enables the user to have hex type output for the file names, since mugen's group and sprite no are short ints, that way the file names cover the full range of posible values for those, fixing a bug i hated abbout sff2pcx.
I include the rar file with the edited stuff comented , i also note that i did not compile it, because i do not use gcc but bcc, and i have not goten around to adapt it to C++Builder, which is the ide i use.

Thanks for adding that. Other than a misplaced semicolon, it seems to work fine.

But to avoid confusion due to the hex file names, perhaps we should also add the option to simply use five decimal digits each for the group number and image number. For the DOS/Windows version, there would then exist the possibility of exceeding the number of unique file names storable in DOS's 8.3 name format (hence the need to retain the hex option), but I think the chances of that ever happening are slim.

(In case anyone is wondering, both SFFExtract 0.3 and SFF2PCX automatically make the file name longer if necessary to accommodate 5-digit group or image numbers. But a problem arises when one sprite has its group and sprite numbers set to something like 2456 and 13789 respectively, and another sprite is set to 24561, 3789. In this case, both sprites will be written to 245613789.pcx, and the 2nd sprite will overwrite the 1st.)

Now, does anyone know what Windows does when it runs out of name~##.ext alternate names when it's dealing with long file names? Does it switch to a different 8.3 naming convention (e.g. replacing the tilda with a different obscure character), or does it just cause an error? And, might there be a limit on the number of files in a folder that would be exceeded before running out of alternate 8.3 names anyway? I'm not sure where to look that up.

[quote]But a problem arises when one sprite has its group and sprite numbers set to something like 2456 and 13789 respectively, and another sprite is set to 24561, 3789. In this case, both sprites will be written to 245613789.pcx, and the 2nd sprite will overwrite the 1st.)[/quote]
Can you get it to write a character inbetween the group and sprite numbers to avoid this?

(Meh, that was a bad time to discover my laptop's battery is in its death throes.)

Hm, that's a thought. But, for organizational/sorting purposes, I think it would be better to keep the number of digits at a fixed width. And doing so would make a separator character unnecessary.
Right now, I'm thinking 10-digit decimal names should be the default. Hex should be an option, in case the default exceeds any DOS limitations. And perhaps 8-digit decimal should also be retained as an option, in case the default causes any problems, and the user doesn't want to deal with hex and knows that none of the numbers exceed 9999. Agreed?

Agreed.

Could people test this?:
http://www.shinmugen.net/winane/sffextract-0.4.zip
http://www.shinmugen.net/winane/sffextract-0.4-src.zip

And here's a little test SFF file I made of the type I described above:
http://www.shinmugen.net/winane/camm2d.zip

In particular, I can't remember how well the MS-DOS versions that came with Windows 95 and 98 dealt with long file names. So if anyone has either of those (especially 95, har), please test out the default 10.3 output name mode, and also the 8.3 decimal mode with camm2d.sff.

(The correct 10.3 output with camm2d.sff should be:
0000000000.pcx
0000000001.pcx
0000000002.pcx
0000000003.pcx
0234511678.pcx
1357924680.pcx
2345101678.pcx

And the 8.3 decimal output should turn out like this, if the behavior is the same as on WindowsME:
00000000.pcx
00000001.pcx
00000002.pcx
00000003.pcx
1357924680.pcx
234511678.pcx
)

I've uploaded a new sffextract with Winane and [E]'s updates.

Available on the same URL as before:

http://nigaiden.skreel.org/index.php

New version (0.41) with a bug fixed. sffextract would blank "file.sff" with the following command line : "sffextract -o file.sff".

Just want to let everyone know that Nigaiden recently posted a major update to sffextract. As far as I know, there's only one minor bug left. Nigaiden is currently detached from the internet, but if anyone finds any more bugs or desperately needs any new features in the meantime, please post here and I'll try to get it fixed.

I just discovered that some SFFs have the first image incorrectly set to use the previous image's palette.
I've fixed sffextract to deal with this. I've uploaded the source and Win32 binary to my site, for until Nigaiden returns. (Sorry, no Linux binary until then.)


<-Link.

[quote author=Winane link=board=4;threadid=1562;start=0#msg18892 date=1064474738]
I just discovered that some SFFs have the first image incorrectly set to use the previous image's palette.[/quote]

Since there is no "previous image" before the "first image", how can this be possible?

Is it this rare case when there are, for examples, 2 images with the same number?