#

##

### How to fix M.C.M.-compiled stage SFFs

Most stages compiled with M.C.M. don't work with BGPalFX properly. In particular, any M.C.M.-compiled SFF file that does not use the same palette for all of its sprites will have this problem.
(It is also possible to create stages with this problem using Sprmaker or other SFF compilers, but such SFFs are much less common.)
One way to fix this problem is to use SFFExtract with "-d -i -1 -o stagename.txt stagename.sff" to decompile the SFF, and then use Elecbyte's Sprmaker to recompile it. (And when you pipe the text file into Sprmaker, don't forget to use Sprmaker's -f, -p, and (if it's safe) -c command line switches to optimize the SFF.)
Alternatively, if you have a hex editor*, there is another, slightly simpler way to fix the problem. Simply open the stage's SFF in your hex editor, and change byte 32 (the one highlighted in the screenshot) from 01 to 00 (it's the byte that specifies whether the palette type is shared or individual). That's all.
However, in the long run, it may be wiser to use the first solution, as there are a couple other minor flaws in SFFs made with M.C.M. Bytes 16-19 are supposed to specify the number of groups in the SFF, but MCM often sets them to zero. And bytes 28-31 are supposed to indicate the size of the subheaders, but MCM incorrectly sets them to 00 02 00 00 (512) instead of 20 00 00 00 (32). As far as I know, these two errors do not have any effects. But there remains the possibility that they could cause problems with future Mugen tools, or possibly even with future versions of Mugen itself.
Furthermore, recompiling with Sprmaker can often yield a smaller, more optimized SFF than the original M.C.M.-compiled version.
Note that all the instructions on this page are only for dealing with stages, not characters.
Also note that this won't fix BGPalFX problems caused by non-8-bit images in the SFF. To fix that problem, you'll need to convert the images to palettized 8-bit format. This may require splitting up the image and modifying the stage's code, if any image includes more than 255 unique colors and you don't want any color loss.
*Such as AXE or HxD, for Windows systems. AXE is what's shown in the screenshot, but I'd recommend getting HxD instead, if this is all you need it for.
If you're using a GNU/Linux system, then GHex or KHexEdit should suffice, though I can't recommend either very highly at present.

Top Page