# The Mugen Fighters Guild Forum

## Help => Tips, Tricks, Tutorials => Topic started by: Winane on July 04, 2004, 12:39:50 AM

Title: Making character SFFs universally compatible
Post by: Winane on July 04, 2004, 12:39:50 AM

[size=1]Decided this is probably worth having a topic in the Tips and Tutorials forum, so I copy/pasted this from a post I made a while ago in the Help forum:[/size]
Here's how to make character SFFs optimized and compatible with both DOS and Linux Mugen:
If sprite 0,0 exists anywhere in the SFF, then it's best to put:
9000,0 first
9000,1 second
other sprites third
(In this case, it doesn't seem to matter whether 9000,0 or 9000,1 comes first, if both have individual palette.
But 9000,0 requires an individual palette, while 9000,1 does not. So you may as well always put 9000,0 first.)
If sprite 0,0 does not exist in the SFF, then it's best to put:
9000,0 first
(9000,1 can come second only if its palette is shared)
normal sprites with shared palettes second
9000,1 (if it's got an individual palette) and any other individual palette sprites last
And in both cases, remember that all normal sprites other than the portraits should be set to use shared palettes (well, unless you want to take advantage of the way Linux handles the palettes to overcome the 255 color limit, at the expense of DOS Mugen compatibility...).
And of course, Sprmaker's -c and -f switches are also still your friends. :) (Well, unless you've got more than 32767 sprites in your SFF, in which case -f may not be your friend.)
Anyway, it seems that the presence of sprite 0,0 makes Linux Mugen give all shared-palette sprites the same palette (normally the one specified by the current ACT file--haven't yet tested what happens when there is no ACT file), while its absence makes Linux Mugen give shared-palette sprites the same palette as the previous sprite. So, if sprite 0,0 is present, I assume it's best to put both portraits at the beginning of the SFF in order to speed up Mugen's loading time, so it doesn't have to search all the way to the end of each SFF to find what it needs for the select screen.
It's also important to note that M.C.M. does not reveal what order the sprites in the SFF are in, nor does it let you specify what order to put them in, so I think it cannot be used to implement the guidelines I've provided here. MEE does, on the other hand, but with it you have to worry about some major bugs in SFF2PCX (such as being likely to screw up the small portrait's palette), since MEE works as a front-end to that program. You can make your SFF with programs other than Sprmaker if you want, but when you're done, I think you'll need to use Sffextract and Sprmaker and a text editor to then put the sprites in the proper order (unless you know how to circumvent MEE/SFF2PCX's bugs, which I don't really feel like explaining in this post :P ).
Let me know if this needs any clarification, correction, or additional information.
Edit: This post isn't entirely accurate and complete. Please read Reply #4, Reply #8, Reply #13, and Reply #17 below. I'll tidy things up here later.

Title: Re:Making SFFs universally compatible
Post by: Winane on July 04, 2004, 12:42:02 AM

[size=1]Guess this might be worth reposting too, in case anyone has the same question:[/size]
Quote from: Loona on May 22, 2004, 06:45:13 PM
Quote from: Guild Master on May 20, 2004, 08:24:14 AM
But 9000,0 requires an individual palette, while 9000,1 does not.
Wasn't it the other way around, considering 9000,0 is the small portrait?...
9000,0 looks screwed up on the select screen in Linux if you don't give it an individual palette, so it needs one. (In game, however, sprite 9000,0 will always receive the palette from the currently selected ACT file; or if there is no ACT file, then it will always receive the palette of the first sprite in the SFF. This is in contrast to how most sprites are treated, which I've described above.)
9000,1 may be given an individual palette, but it will display correctly on the select screen if it uses a shared palette (in which case it will always be given the palette of the first sprite regardless, rather than the palette of the previous sprite edit: unless it comes before 9000,0). It's not necessary to give it a shared palette, but if you've got enough extra room in your main palette, you may as well save 768 bytes in the SFF by giving it one. (Edit: In game, it's treated the same way as any other sprite. So, sprite 9000,0 is presumably the only sprite that receives special treatment (not counting sprite 0,0's effect on the entire rest of the SFF in-game).)
This info corrected below.

Title: Re:Making character SFFs universally compatible
Post by: Q -- petit Q on July 04, 2004, 04:53:25 AM

Quote from: Winane on July 04, 2004, 12:39:50 AM
Let me know if this needs any clarification, correction, or additional information.
Yes, additional information: what is the best and easy tool to use to do this when using windows XP?

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 04, 2004, 05:17:17 AM

Well, I don't have Windows XP, so I don't know whether and how well each program works on it.
Personally, I just use Sprmaker and a text editor for compiling my own SFFs. But for people who really want a GUI for whatever reason, well, it's up to you what you use to make the SFF. Just make sure that you don't give any two sprites the same group and image numbers (which is really quite pointless to do, since only the first one will ever appear in Mugen), so that the current not-yet-complete version of Sffextract doesn't screw anything up when you use it to sort the final SFF, and you should be fine.
Or did I misinterpret your question? The pronoun "this" in your post was kinda vague.

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 24, 2004, 02:34:14 AM

I just now did some more testing, and found that my understanding of how the palette stuff works on the select screen wasn't quite right. (Guess I shouldn't have stopped experimenting once I found a reliable solution.) So, this is the way it actually works in the newer versions of Mugen:
9000,0 and 9000,1 are actually treated equally, and all other images are completely irrelevant.
If both 9000,0 and 9000,1 are given individual palettes, then both will display properly on the select screen, of course.
If the first one in the SFF is set to use a shared palette, then it will be given a garbage palette.
If the second one in the SFF is set to use a shared palette, then it will be given the same palette as the other one (regardless of whether the first one's palette was individual or filled in with garbage).
So if neither is given an individual palette, then neither will display correctly.
The garbage palette is merely the 768 bytes immediately following the PCX data in the first of the two images. [size=1](Note for those interested in the technical stuff: By "PCX data", in this case I mean the stuff concluding with the requisite 0x0C (decimal 12) byte, i.e. the data preceding the palette in the 8-bit PCX format, regardless of whether the palette has been removed by the SFF compiler or not.)[/size]
If the subheader of the first image indicates its palette is shared, but its palette data wasn't actually removed, then it will display fine, since the next 768 bytes are actually its palette. [size=1](So, I guess I shouldn't have called it a garbage palette, since in this particular case it's not. :P )[/size]
But if the subheader of the second image indicates its palette is shared, but its palette data wasn't actually removed, then it will still receive the palette data of the first image despite the presence of its own palette.
This new understanding has absolutely no effect on the image order I recommended in my first post, though. Just thought some people might be curious. :)
By the way, in case anyone missed the announcement in the Releases forum, Sffextract as of version 0.8 is finally safe to use to fix SFFs with these guidelines (just so long as you use it properly, of course). :D

Title: Re:Making character SFFs universally compatible
Post by: OrochiKOF97 on July 24, 2004, 07:22:46 AM

Quote
If both 9000,0 and 9000,1 are given individual palettes, then both will display properly on the select screen, of course.
If the first one in the SFF is set to use a shared palette, then it will be given a garbage palette.
My 9000,0 sprites use a shared palette and they display properly in MUGEN. ???

Title: Re:Making character SFFs universally compatible
Post by: Alexandra on July 24, 2004, 08:46:20 AM

me too

Title: Read more carefully the posts :D
Post by: Sepp on July 24, 2004, 12:12:30 PM

Quote from: Winane on July 24, 2004, 02:34:14 AM
If the subheader of the first image indicates its palette is shared, but its palette data wasn't actually removed, then it will display fine, since the next 768 bytes are actually its palette.
But, yes, it made me wonder at first, too.
Because I also have 9000,0 first and no problems.

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 24, 2004, 02:38:31 PM

Yep, what Sepp said. :)
Besides, Clark's 9000,0 and 9000,1 sprites are both set to use their own individual palette. :P
There might be some confusion with terminology here. When I say an image is set to use a shared palette, I'm not referring to whether any other sprites are going to use its palette data. I just mean that it's set to use the palette data from some other sprite, instead of its own palette data. There's a byte in the subheader for each image that indicates this (whether to use a shared palette or its own individual palette).
And normally, when you tell it to use a shared palette, most SFF compilers will remove its palette data to save space. But it is possible to set the subheader to indicate shared palette without actually removing the palette data at the end of the PCX file.

Title: Re:Making character SFFs universally compatible
Post by: OrochiKOF97 on July 24, 2004, 03:12:43 PM

No, Clark's 9000,0 has a shared palette, and I understood what you posted above.

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 24, 2004, 04:01:40 PM

Um, nope, in the clark03.sff file from your Clark v0.91a, 9000,0 is set to keep its own palette:
Quote
; ElecbyteSpr 0.1.0.1
; 150 groups
; 1098 images
;
; Options
#
; Palette
1
; Shared palette
2
; End of options
;
; Output file
clark03\clark03.sff
; Individual palette
#
1
1
clark03\90000000.pcx
9000
0
0
0
clark03\00000000.pcx
0
0
35
106
etc...
By the way, here's a little more info about how Sprmaker works:
If you specify global shared palette, then the first image's subheader in the SFF will always be set to individual palette, even if you specifically tell it to set the first image to use a shared palette.
But if you don't specify global shared palette, and you do set the first image to use a shared palette, then the first image's subheader will be set to shared. It will retain its palette anyway, though, so it won't affect anything in Mugen.
(Side note: It looks like I recently broke processing of the latter type of SFFs in Sffextract. Already fixed it, so it'll be in the next update, which I guess will be released as soon as Dark Saviour resurrects himself. I've only noticed a few SFFs affected by it though (e.g. Splode's Hiryu & Deuce+Kitsune's Geese, if I remember correctly).)
Other than that, as far as I know, CharSffDtoW is the only SFF compiler that ever sets the subheader to shared but without removing the palette data.
[size=1]Edit: Decided not to wait for Dark Saviour. Fixed Sffextract now released.[/size]

Title: Re:Making character SFFs universally compatible
Post by: OrochiKOF97 on July 24, 2004, 05:58:51 PM

Quote
; ElecbyteSpr 0.1.0.1
; 148 groups
; 1098 images
;
; Options
#
; Palette
1
; Shared palette
2
; End of options
;
; Output file
clark03\clark03.sff
clark03\0900000000.pcx
9000
0
0
0
clark03\0000000000.pcx
0
0
35
106
clark03\0000000001.pcx
0
1
35
106
clark03\0000000002.pcx
0
2
35
106
You hacked the SFF file, you removed 2 groups and added that just to make fun of me >:( >:( >:( it seems that the 0.91a doesn't have the very latest version of the sff file, that's why I was insisting on the fact that clark did not have his small portrait treated as an individual palette. Anyway those explanations on SFF compilation through this thread were useful to me.

Title: Re:Making character SFFs universally compatible
Post by: SDS Overfiend on July 25, 2004, 01:11:58 PM

Quote
me too
how did you have trouble with xiang fei kos?
was the portrait last or something?

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 26, 2004, 03:02:53 AM

I'm afraid your questions aren't quite comprehensible, Homer. ???
Anyway, here's a quick write-up of what's basically the algorithm I use to fix DOS character SFFs to be optimized and universally compatible, using Sffextract 0.9:
(Yes, I know there are easier ways, but if you want it done properly, safely, reliably, and optimally, then this is currently the only way to go.)
-Run Sffextract with:
sffextract -d -i -o charname.txt charname.sff
-If you encounter any invalid linking errors:
*Start over, but this time add the -f switch.
-If you encounter either of these warnings:
"Warning: Invalid number of groups specified in header."
"Warning: Nonstandard subheader size specified in header."
*Then just ignore them. =P They won't cause any harm.
-If the console window doesn't report any other errors, warnings, or notices, then:
*Open up charname.txt.
*If the third uncommented line says "1" (preceded by a line that says "; Individual palette"), then:
_Start over, but this time add the -1 switch. (Note: This step assumes that the character's SFF was designed for use in DOS Mugen. But if the SFF were designed to take advantage of post-DOS Mugen's ability to break the 255 color limit, then you probably wouldn't be fixing it anyway. =P )
*Find image 9000,0 (search for "0900000000", if you haven't used -8 or -x). Move it to the beginning of the SFF file.
*Check whether image 0,0 exists (search for "0000000000", if you haven't used -8 or -x).
*Find image 9000,1 (search for "0900000001", if you haven't used -8 or -x).
*If image 0,0 exists, then:
_Move image 9000,1 (including #/1/1, if they precede it) to come right after image 9000,0.
*Else, if image 0,0 doesn't exist, then:
_Check whether image 9000,1 is preceded by #/1/1.
~If so, then move image 9000,1 (including #/1/1) to the very end of the file.
~If not, then move image 9000,1 to come right after image 9000,0.
*Do a search for the word "Individual".
*For any images preceded by the comment "Individual palette" (and #/1/1):
_Open up the PCX file.
_If it looks like an alternate portrait or something else that might really ought to have its own palette, compare its palette to the palette of the first sprite in the SFF. If the palettes are incompatible, then move the image (including #/1/1) to the very end of the file.
_Otherwise, if it looks like a normal sprite that you'd see in-game, and you're sure the SFF wasn't designed for use in post-DOS Mugen, then delete the #/1/1 preceding it in the text file.
*Run sprmaker -c -f -p < charname.txt
-If you encounter any "Image kept own palette despite subheader" notices, then:
*Treat those images as I instructed for "Individual palette" images, but add #/1/1 if you determine that they should keep their palette.
-If you encounter any "Image is not in 256-color PCX format" notices, then:
*Give up. It's not worth fixing, unless you really, really like the crappily made character you're dealing with. =P :)
*If you refuse to give up, then convert the problematic images to be 8-bit palettized, using nearest color matching when applying the character's default ACT file. Or something like that.
-If you encounter any "Extra image saved as: " notices, then:
*Ignore it if you want. The recompiled SFF will appear in Mugen the same way it did before.
*But if you want a properly made SFF file, then investigate those images:
_If any duplicately numbered images are identical to the first image with that group+image number, and they all have the same axes, then simply delete the duplicates from the text file (but keep the first instance of the image, of course).
_Else, if they're not identical, try to determine which one really belongs with that group+image number. (This requires some basic understanding of how all this SFF, AIR, and whatnot stuff works.) Make reference to Elecbyte's spr.txt and spr.gif if the images in question are required sprites. Otherwise, take a look at the character's AIR file. Then, either remove or renumber the images that don't belong, as appropriate, and make any necessary changes to the AIR file if applicable.
-If you encounter any other errors or warnings, then:
*Deal with them as appropriate. =P
-If you encounter too many notices, warnings, and error messages to fit in the console window, then:
*Either start over using the -w option. For example:
sffextract -d -i -o charname.txt -w stderr.txt charname.sff
*Or simply always use the -w option, so you never have to start over. Just be sure to always remember to check the contents of the diagnostic messages file.
So, like Faye/Chloe/Kos-Mos/Athena said, it's all very simple. ^_^
If anyone would be so kind as to put all that into a more readable and understandable form, I'd be most appreciative. ^^ And of course, please let me know if anything here needs amending.

Title: Re:Making character SFFs universally compatible
Post by: Alexandra on July 26, 2004, 03:50:53 AM

yes it's simple, isn't it ?

Title: Re:Making character SFFs universally compatible
Post by: SDS Overfiend on July 27, 2004, 09:51:49 PM

Quote
I'm afraid your questions aren't quite comprehensible, Homer.
i meant to say that if 9000,0 is not first while 0,0 existedthen it will come out mess up right?

Title: Re:Making character SFFs universally compatible
Post by: Winane on July 28, 2004, 10:54:43 PM

Umm, as explained on the first page of this thread, image 0,0 generally has no effect on image 9000,0 (well, unless the character has no ACT files and image 0,0 is the first in the SFF, in which case image 0,0 determines image 9000,0's palette in-game). And image 9000,0 generally has no effect on image 0,0, either.

Title: Re: Making character SFFs universally compatible
Post by: Winane on August 27, 2004, 07:36:36 PM

Jeez, all this time and no one discovered how horribly wrong my explanation was? ??? ^^
The stuff I wrote about how the portraits are dealt with on the select screen is true, but my theory of in-game palette treatment was not.
First of all, as I said, there's a byte in the subheader for each image in an SFF file that indicates whether the image should use a shared palette or its own individual palette. According to Elecbyte, this byte is set to "True if palette is same as previous image," but that's not exactly correct. I don't feel quite inclined to rewrite this all in layman's terms, but here's a brief explanation of how it all really works, copy/pasted from our revised formats.txt:
This byte is ignored (assumed to be 0) in Mugen if the image is the first
image in the SFF file. Otherwise:
If this byte is set to 0 and the SFF belongs to a stage or other
non-character, or to a character while on the select screen, then
the image will retain its own palette.
If this byte is set to 1 and the SFF belongs to a character while on the
select screen in DOS Mugen, then the image will use the palette data of the
first sprite in the SFF file.
If the image is part of a character SFF in-game (that is, during a match or
win screen) in DOS Mugen, then it will receive the palette of the currently
selected ACT file, or else the palette of the first image in the SFF if the
character has no ACT files, regardless of what this byte is set to.
If this byte is set to 1 and the SFF belongs to a stage or other
non-character, then the image will use the palette data of the
previous sprite in the SFF file.
The interpretation of this byte in character SFFs in Linux Mugen is a little
more complicated. Generally, images in character SFFs in-game in Linux
Mugen retain their own palette if this byte is set to 0, or receive the
palette of the previous image if this byte is set to 1. But if the image is
numbered as 0,0 or as 9000,0 (given that it's the first image 0,0 or the
first image 9000,0 in the file; any subsequent identically-numbered images
are ignored), then the image will receive the palette of the currently
selected ACT file, or else the palette of the first image in the SFF file if
the character has no ACT files, regardless of what this byte is set to. And
then that palette is also applied to any other images that would have
otherwise shared the same palette as one of those two images (that is, any
subsequent images marked as using a shared palette, up to but not including
the next image marked as having an individual palette; and, if the image 0,0
or 9000,0 is marked as using a shared palette, then also any previous images
up to and including the nearest prior image marked as having an individual
palette.)
Furthermore, the palette selection method for sprites 9000,0 and 9000,1 is
completely different on the select screen in Linux Mugen. The first of
these two images will use its own palette regardless of what this byte is
set to (meaning that it will use the next 768 bytes in the SFF file if its
palette has been removed, which needless to say won't look very good).
The second of these two images to occur in the SFF file will use its own
palette if this byte is set to 0, but will use the palette of the other
image if this byte is set to 1.
This doesn't really have much effect on the guidelines I wrote for fixing SFFs, however. The directions remain the same, though I guess I should add this little addendum:
If the character has any ACT files, and image 9000-1 has its own separate palette, then it may actually be slightly more optimal to put it at the very beginning of the SFF. In the case where image 0,0 doesn't exist, it should slightly improve select screen loading time. And in the case where image 0,0 does exist, it may (or may not) reduce the number of palettes for Mugen to process in-game by one, depending on how exactly Elecbyte coded it.
But neither of those should matter very much at all, and it'll screw up the display of the character in-game if there are no ACT files. Furthermore, if you're ever going to use Sffextract on the file at any point in the future, you'd need to use the -1 switch when extracting. (Or to avoid that need, you could just remove the #/1/2 at the beginning of the text file before recompiling with -p, if you've made certain that all other images already have the same palette.)
Note, however, that neither portrait may be a linked sprite, and so putting both at the beginning eliminates the need to worry about that at all.

Title: Re: Making character SFFs universally compatible
Post by: Winane on September 19, 2004, 03:50:09 PM

Ya know, it just occurred to me:
If the large portrait (9000,1) has its own unique palette, it may still be best to put it at the very end (or the very beginning, as explained in my last post) of the file, even if image 0,0 does exist. That way, you'd be able to use it in-game in post-DOS Mugen without having its palette get screwed up. That could be useful in your own character for use as a super portrait or whatever else you want, so long as the mismatch between the currently selected palette and the portrait's palette isn't too much of a problem (e.g. if the portrait has red hair and purple clothes, while the ACT file uses green hair and blue clothes, that'd look kinda weird; but if both have the same hair and skin color, and the clothes aren't visible in the portrait, then it'd look fine). And perhaps possibly more importantly, someone else might eventually decide to make a character that features a move wherein it puts your character in a custom state, and then proceeds to desecrate your large portrait, or something like that.
Of course, if you still want the small portrait first (thus ensuring proper character display even when no ACT files are present), and still don't want to put the large portrait at the very end (to avoid longer select screen loading time), you could use CharSffDtoW's strategy of putting the small portrait first, the large portrait second, and 0,0 third, and giving all three individual palettes (rather than removing 0,0's palette, as I'd probably previously specified somewhere in this thread). Only tradeoff there is that you'll have an extra 768-byte palette in the SFF file.

Title: Re: Making character SFFs universally compatible
Post by: BlackJack on April 23, 2005, 12:51:59 PM

Quote from: Horseradish Booty on July 26, 2004, 03:02:53 AM
If anyone would be so kind as to put all that into a more readable and understandable form, I'd be most appreciative. ^^

- Run Sffextract with:

sffextract -d -i -o charname.txt charname.sff

- If you encounter any invalid linking errors:

- Start over, but this time add the -f switch.

- If you encounter either of these warnings:

"Warning: Invalid number of groups specified in header."
"Warning: Nonstandard subheader size specified in header."

- Then just ignore them. =P They won't cause any harm.

- If the console window doesn't report any other errors, warnings, or notices, then:

- Open up charname.txt.
- If the third uncommented line says "1" (preceded by a line that says "; Individual palette"), then:

- Start over, but this time add the -1 switch. (Note: This step assumes that the character's SFF was designed for use in DOS Mugen. But if the SFF were designed to take advantage of post-DOS Mugen's ability to break the 255 color limit, then you probably wouldn't be fixing it anyway. =P )

- Find image 9000,0 (search for "0900000000", if you haven't used -8 or -x). Move it to the beginning of the SFF file.
- Check whether image 0,0 exists (search for "0000000000", if you haven't used -8 or -x).
- Find image 9000,1 (search for "0900000001", if you haven't used -8 or -x).
- If image 0,0 exists, then:

- Move image 9000,1 (including #/1/1, if they precede it) to come right after image 9000,0.

- Else, if image 0,0 doesn't exist, then:

- Check whether image 9000,1 is preceded by #/1/1.

- If so, then move image 9000,1 (including #/1/1) to the very end of the file.
- If not, then move image 9000,1 to come right after image 9000,0.

[/list]

- Do a search for the word "Individual".
- For any images preceded by the comment "Individual palette" (and #/1/1):

- Open up the PCX file.
- If it looks like an alternate portrait or something else that might really ought to have its own palette, compare its palette to the palette of the first sprite in the SFF. If the palettes are incompatible, then move the image (including #/1/1) to the very end of the file.
- Otherwise, if it looks like a normal sprite that you'd see in-game, and you're sure the SFF wasn't designed for use in post-DOS Mugen, then delete the #/1/1 preceding it in the text file.

- Run sprmaker -c -f -p < charname.txt

- If you encounter any "Image kept own palette despite subheader" notices, then:

- Treat those images as I instructed for "Individual palette" images, but add #/1/1 if you determine that they should keep their palette.

- If you encounter any "Image is not in 256-color PCX format" notices, then:

- Give up. It's not worth fixing, unless you really, really like the crappily made character you're dealing with. =P
- If you refuse to give up, then convert the problematic images to be 8-bit palettized, using nearest color matching when applying the character's default ACT file. Or something like that.

- If you encounter any "Extra image saved as: " notices, then:

- Ignore it if you want. The recompiled SFF will appear in Mugen the same way it did before.
- But if you want a properly made SFF file, then investigate those images:

- If any duplicately numbered images are identical to the first image with that group+image number, and they all have the same axes, then simply delete the duplicates from the text file (but keep the first instance of the image, of course).
- Else, if they're not identical, try to determine which one really belongs with that group+image number. (This requires some basic understanding of how all this SFF, AIR, and whatnot stuff works.) Make reference to Elecbyte's spr.txt and spr.gif if the images in question are required sprites. Otherwise, take a look at the character's AIR file. Then, either remove or renumber the images that don't belong, as appropriate, and make any necessary changes to the AIR file if applicable.

[/list]

- If you encounter any other errors or warnings, then:

- Deal with them as appropriate. =P

- If you encounter too many notices, warnings, and error messages to fit in the console window, then:

- Either start over using the -w option. For example:

sffextract -d -i -o charname.txt -w stderr.txt charname.sff

- Or simply always use the -w option, so you never have to start over. Just be sure to always remember to check the contents of the diagnostic messages file.

[/list]

Too bad there are only 3 symbols, I'd have liked one more. :(

Title: Re: Making character SFFs universally compatible
Post by: Kula Diamond on April 27, 2005, 03:20:13 PM

All of this is giving me a headache. What's that #1/1 thingy?

Title: Re: Making character SFFs universally compatible
Post by: BlackJack on April 27, 2005, 03:59:37 PM

#/1 means "palette type".
#/1/1 means "individual palette".
IINM.

Title: Re: Making character SFFs universally compatible
Post by: Tekkaman Blade on May 17, 2005, 05:28:07 AM

Following your procedure, should 0,0 be placed after 9000,2 if it exists? Or should 9000,2 ;which sometimes has it's own palette; be placed at the end, or at least after 0,0?
PS this is great! Went into conversion fever and passed several chars thru the 'mill'. This method is far better than those progs such as the conversor.
Oh and 'updating' my chars sffs seems to have made the character selection to move faster, in addition to ingame fluidity...

Title: Re: Making character SFFs universally compatible
Post by: Byakko on May 17, 2005, 05:36:49 AM

Quote
If it looks like an alternate portrait or something else that might really ought to have its own palette, compare its palette to the palette of the first sprite in the SFF. If the palettes are incompatible, then move the image (including #/1/1) to the very end of the file.
The important part isn't the number of the sprite but if the palette is shared or not, for optimization sake. If the SFF file (which is the largest in a character) is smaller, you should technically/theorically get it to be loaded fast. Do that for each chars and you might see a small difference.

Title: Re: Making character SFFs universally compatible
Post by: BlackJack on May 17, 2005, 05:40:45 AM

Quote from: blud7 on May 17, 2005, 05:28:07 AM
Oh and 'updating' my chars sffs seems to have made the character selection to move faster, in addition to ingame fluidity...
Quote
If the SFF file (which is the largest in a character) is smaller, you should technically/theorically get it to be loaded fast. Do that for each chars and you might see a small difference.
:idea: In fact, chars are loaded faster because Mugen doesn't have to browse very long through the SFF to find the portraits (in order to make them appear on the select screen).

Title: Re: Making character SFFs universally compatible
Post by: Byakko on May 17, 2005, 06:17:50 AM

Seriously ? Just for that, it's just browsing to find 1 sprite and forget the rest afterward ? o_O *flies to put the portraits at the beginning of the SFF on all WIPs* [size=1]*wait... hardly any of my WIPs have their portraits yet*[/size]

Title: Re: Making character SFFs universally compatible
Post by: BlackJack on July 05, 2005, 05:46:11 PM

Quote from: Byakko on May 17, 2005, 06:17:50 AM
Seriously ? Just for that, it's just browsing to find 1 sprite and forget the rest afterward ? o_O
To load the select screen, Mugen only browses the SFF of every character to load up the little and big portraits. The SFF is fully loaded only when you're about to use the character (read: during the VS screen).
Quote
*flies to put the portraits at the beginning of the SFF on all WIPs* [size=1]*wait... hardly any of my WIPs have their portraits yet*[/size]
I believe (though I haven't checked) that, in case your character has no portrait, Mugen seeks through the whole file (guess what that means ;) ).

Title: Re: Making character SFFs universally compatible
Post by: Madness on August 02, 2005, 04:55:55 PM

someone should *really* do a frontend for that kind of stuff.
or maybe a uberl33t batch file.

Title: Re: Making character SFFs universally compatible
Post by: Nobun on September 06, 2005, 04:25:38 PM

It seems to me that you make a simply thing harder than real.
Why 9000,0 if shared and not the first is showed badly?
Simply becouse of the fact that on select screen Mugen cannot find palette information (stored at the end part of block code for individual-palette) and so Mugen use the palette of screenpack.
Why a shared 9000,0 can be showed without problem on select screen if setted as the first image?
Becouse the first shared image of shared sff (differently than other shared images) stores the last-768 bytes-palette information.
second thing: it is better to put the big portrait with individual palette as the last image (and not as the second one as said before).
Code:

    #
    1
    2
    IMAGENAME.PCX
    9000
    0
    0
    0
    ......
    ;last image
    #
    1
    1
    IMAGENAME.PCX
    9000
    1
    0
    0

Title: Re: Making character SFFs universally compatible
Post by: SlayerGatsu on September 07, 2005, 12:07:21 AM

I might as well Add, that Dos mugen WILL NEVER have any problems at all in
Reading a "PERFECT" sff file.
FOR an sff file to be "perfect" you MUST follow the numbers, OR ELSE, why would have elecbyte MADE group numbers?
MOREOVER, IF you plan to insert Unshared images in an sff THEY have to be LAST. (possibly AFTER 9000,1 )
and No other Indexed images should be place after them.
why?
well it's easy, the palettes of the sprites set in the "middle" will "crack"
you will see and get messed up images when you try to reopen the sff file (unless you extract with sff2pcx (or something better ^^)
so the First image (as logic says) NEEDS to be 0,0
THE PROBLEM that many of you are concerned about it's constant... SORT out the sff with Mee
(
I will soon try and make a better thing ONLY for
a. extract (pcx and text)
b. SORT (the text blocks)
c. Remount the sff
in a VB script Exe where you drop the sff.
The images of group # 9000 will be set to #,1,2 automatically and you will be "advertised" if any images are placed after that So that you can edit the text. (maybe the prog will also open the text at the right point :o and allow to edit before continuing)
Please Ideas (are already many) but are fully welcome, let's try to get me to make something actually useful ::)

Title: Re: Making character SFFs universally compatible
Post by: XGargoyle on September 07, 2005, 10:40:22 AM

all my characters are compiled with Sprmaker and follow Elecbyte's guidelines about sprite order (9000,0; 9000,1; 0,0...) and I have never had any issue in DOS, linux or Windows versions.
So, the problem is not the sprite order per se but which tool are you using to create the SFF.
Sprmaker never gives any problem.
MEE don't have these issues, as it's actually a frontend for sprmaker.
MCM stores palette information for unshared pictures in a different way, and that's where problems appear. This problem can persist if you have a SFF created by MCM from scratch but you use other tools later.

Title: Re: Making character SFFs universally compatible
Post by: SlayerGatsu on September 07, 2005, 07:44:24 PM

for a fast thing you can align the pics in mcm, then extract all the coordinates, and by the correct pics you can Re make the sff with sprite maker, So it shall always be perfect
(And what I believe the utility will do.... THUS the picks will be extracted as they are and IF they are corrupted then they are corrupted..... :()
Btw, Winmugens Kfm has the images sorted by number --;

Title: Re: Making character SFFs universally compatible
Post by: Tekkaman Blade on September 09, 2005, 09:03:36 AM

There is one problem with your method of putting all the individual palettes last (except for portrait etc). Thing is, some creators (e.g. Toma) put individual palettes so that the pcxs after it would carry that palette, up until another individual palette. So what happens in your method is that the first pcx is the right colour, but the rest are spoilt At least this has been my experience so far.
This would also question XGargoyle's statement that sprite order per se is not important (aside from the obvious)

Title: Probably not worth bumping...
Post by: Messatsu on February 22, 2007, 03:41:30 PM

Quote
It's also important to note that M.C.M. does not reveal what order the sprites in the SFF are in, nor does it let you specify what order to put them in, so I think it cannot be used to implement the guidelines I've provided here.
While the order is not revealed, MCM's order in which the sprites are added is known. It'll tack on new sprites on the end of the sff. I've made an SFF to your specifications and when sprites are out of order, it's still possible to reorder them through sffextract and recompiling the sff. I used to either leave the portrait off on my master copy or delete the portrait and readd it to finalize it. Using the change sprite option will place the new sprite in the same position in the sff as the one it is replacing.
Powered by SMF 1.1.10 | SMF © 2006-2009, Simple Machines LLC