さて。
最近、うちのページへのアクセスが、Googleなんかの検索結果からってのが多いみたいでして。
なかでも、「Win版」「色化け」なんてキーワードが結構多いみたいなのです。
なので、今回のお題です。

本題に入る前に、まずはここでの言葉の定義をしておきますね。

「Win版」	：	elecbyte1によるHack版mugenに、老兵氏のパッチをあてたものを指します。
「色化け」	：	Win版にてDOS版mugen用キャラを使用した際に、パレット情報が壊れた様な無茶苦茶な 色合いで表示される現象を指します。

というところで、前置きが長くなりましたが、本題に入りましょう。

その１.　色化け現象は何故起きるのか？

一口に「色化け」といっても、その症状はキャラによって様々です。
ある時は、キャラ自体がまるっきりパレット情報が壊れたように滅茶苦茶な色合いで表示されていたり
ある時は、２Ｐカラーを選択したはずが、静止中を除いて何か動作を行った瞬間に１Ｐカラーで表示されたり、
またある時は、一見正しく表示されていても、特定の動作を行うと滅茶苦茶な色合いで表示されたりと、
多岐に渡る模様です。

では、何故色化けが起こるのでしょうか？
以下は、色々試してみた結果から導き出された推論です。

mugen本体の処理を考えた場合に、まだベータ版であるが故に、ＳＦＦの処理に柔軟性がないのだと考えられます。
そのため、ＤＯＳ版にくらべ、よりシビアにＳＦＦを構成してやる必要があると思われます。
どういう事かと言いますと。

例えば、次のようなデータ構成を持ったＳＦＦがあるとします。
なお、下図はＳＦＦファイル内の物理的なファイル格納状態を表しており、行頭をデータの先頭として とらえて下さい。
また、「グループ」欄は画像データのグループ番号及びアイテム番号を表し、「パレット」は画像データ登録時に共通パレットを 使用する様に指定しているか否かを表します。

グループ	0,0	0,1	0,2	0,3	0,4	0,5	0,6	9000,1	10,0	10,1	10,2	10,3	10,4	10,5	10,6	‥‥‥‥
パレット	共通	共通	共通	共通	共通	共通	共通	独自	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥

Win版の動きを見ている限り、どうもこの様な「ＳＦＦの途中に独自パレットが含まれている 」場合に、独自パレット画像より後に登録されている画像（上図の例ではグループ番号１０番以降の画像データ）を処理 する際に、正しいパレット情報を再取得出来ていない様に見受けられます。
結果、そのような画像を表示しようとした場合に色化けが発生していると考えられます。

その２.　じゃあ、どうするよ？

さて、察しの良い御仁なら既にお気づきでしょうが、要は「ＳＦＦの途中に独自パレットを 含まない」様にしてやれば良い模様です。
先の例で言えば、

グループ	0,0	0,1	0,2	0,3	0,4	0,5	0,6	9000,1	10,0	10,1	10,2	10,3	10,4	10,5	10,6	‥‥‥‥
パレット	共通	共通	共通	共通	共通	共通	共通	独自	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥

これが、

グループ	0,0	0,1	0,2	0,3	0,4	0,5	0,6	10,0	10,1	10,2	10,3	10,4	10,5	10,6	‥‥‥‥	9000,1
パレット	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥	独自

こうなっておれば良いわけです。
共通パレット画像は全て先に登録しておき、独自パレット画像は最後に登録する訳です。
こうしておけば、Win版mugenでも正しい色合いで表示してくれることでしょう。

独自パレットの典型的な例として、9000,1（大ポートレート）をあげましたが、他にもエフェクトやヘルパー用に 独自パレット画像を使用している場合、もれなくＳＦＦの後ろに登録してやると良いでしょう。

あと、注意点です。
9000,0（キャラセレ時の顔画像）は、どうもmugen本体内での処理にて、特別扱いされていると見え、 キャラによっては問題になったりならなかったりします。
通常 9000,0 は、共通パレットを使用する設定にてＳＦＦに登録しますが、何故か 9000,0 が色化けする 場合があります。
その場合は、独自パレットを使用する設定にて、ＳＦＦの最後に登録すると障害を回避できる様です。

グループ	0,0	0,1	0,2	0,3	0,4	0,5	0,6	10,0	10,1	10,2	10,3	10,4	10,5	‥‥‥‥	9000,0	9000,1
パレット	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥	独自	独自

例えば、こんな感じですね。

その３.　補足、かな？

これまで述べてきた内容にて、ＳＦＦ内に格納された画像データの、物理的な格納順序が重要であることは、 ご理解いただけたと思います。
ＳＦＦファイルを操作する場合、ｍｃｍを使用されると思われますが、ここでご注意頂きたいのはｍｃｍのバージョンです。

ご存知の方もいらっしゃるでしょうが、最近のｍｃｍはＳＦＦファイルの内容を表示する際に、グループ番号順だかで並べ替えを 行っています。
ただ、これはあくまでもプログラムにてメモリ上に読み出したデータを並べ替えているだけであって、必ずしも物理的な 格納順ではありません。
しかも、ＳＦＦを上書き保存しても、物理順は元のまま（並べ替え前の状態）で保存されます。

グループ	0,0	0,1	0,2	0,3	0,4	0,5	0,6	10,0	10,1	10,2	10,3	10,4	10,5	‥‥‥‥	9000,0	9000,1
パレット	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥	独自	独自

mcm では上記の様に見えていても、物理的には

グループ	0,0	9000,0	0,1	0,2	9000,1	0,3	0,4	0,5	0,6	10,0	10,1	10,2	10,3	10,4	10,5	‥‥‥‥
パレット	共通	独自	共通	共通	独自	共通	共通	共通	共通	共通	共通	共通	共通	共通	共通	‥‥‥‥

こんな風に格納されていたりするわけです。
これでは画像の登録順を操作することができません。
ですので、ｍｃｍは少し古いものを使用する必要があります。
ａｉｒファイルの編集機能が追加される前のバージョンであれば、大丈夫でしょう。
因みに私は、Ver.1.3 を使用しています。
このバージョンでは、ＳＦＦは画像の物理登録順で表示されますし、その画像が共通パレットを使用しているか否かも表示 してくれますので、Win版の色化け原因となっている画像を特定するのにも役立ちます。
なにより、ＳＦＦの物理登録順を変更（削除→再登録による）できますしね。
後、大事なこととしては、作業前にＳＦＦのバックアップをとっておきましょうね。(笑)
まれに、ＳＦＦを修正したら壊れた、なんてこともありますので。

さてさて、こんなところでお役に立つ情報となったでしょうか。
Win版に縁のない人でも、この辺りを意識してキャラ作成しておくと、Win版ユーザにも喜ばれるのではないでしょうか。
いや勿論、DOS版とWin版では命令仕様が微妙に異なっていたりしますから、そのままって訳にもいかんのでしょうが。^-^;

と、いうところで、今回はこれにて。