軽量化まとめ【MUGENの便覧】

軽量化まとめ

ファイルサイズ

sff

余計なスプライトを登録しない
スプライトの不要な余白を切り取る
出来るだけスプライトのパレット共有化（また、独自パレットが多いとownpal=1のモノが極端に処理が重くなる）

例：SAE

バックアップをとっておくこと推奨

不要な余白削除

スプライトリストで範囲選択
→右クリック
→拡張
→余白削除

パレット共有化

スプライトリストで範囲選択
→右クリック
→拡張
→パレットの統一

なお、綺麗に仕上げたい場合はSAEの機能ではなく、製作支援ツール紹介>パレット共有にあるGraphicsGale、Unify-Bitmapなどを使う事をオススメする。
Unify-Bitmapはファイルの形式がBMP限定であることに注意。

snd

音質が気にならない程度に「モノラル化」（mugenでステレオである意味はあまり無い）や「サンプリングを低下」させることで軽量化
SAEやSoundEngineFreeで可能

例：SAE

バックアップを取る
→SNDタブで音声ファイル全部選択（Shiftキー）した状態（重いデータのみを選択するのもあり）で右クリック
→ダウンサンプリング（旧版：音質変換）
→自分が気にならない程度に出来るだけ下げる

ページのトップへ戻る

処理

cfg設定

↓を参考に設定してください。

mugen.cfg [途中の中途 ]
手軽に重くする方法[製作日記]
mugen.cfgの設定と重さ[虹格な海底宝物庫]

補足：FirstRunは新MUGNEなら1にしていると起動時に初回起動だという確認画面が出ます。

sff

出来るだけパレット共有化（独自パレットが多いとownpal=1のモノが極端に処理が重くなる）

cns

警告メッセージを無くす（Ctrl+Dで左上に表示される文字列です。対戦中の全てのキャラのものが表示されます）
ヘルパーのownpalを共通化
常時Playsndを減らす
StopSndでchannel=-1に出来るだけしない
explodとhelperの出し入れを抑える
常駐ヘルパーを減らす
ループを減らす

ページのトップへ戻る

triggerによる処理落ち

注意点：実験結果です。
そのためPCによって値は変わりますので値は参考にはなりませんが、傾向は参考になると思います。
また、通常のtriggerの数なら関係ないと思われます。
注意点は以上です。ちなみに、検証した理由としてはトリガーでの:=による変数代入を多用する場合、なるべく軽くするにはどうすればいいか気になったためです。
まず、
[state ]
type=null
trigger1=2
というステートを常時監視ステートで複数並べ、実行させた場合のFPSを調べました。

ステコン数	トリガー	FPS
400000	trigger1=2	13.4
300000	trigger1=2	29.2～31.6
270000	trigger1=2	41.2～50.5
250000	trigger1=2	52.9～60
200000	trigger1=2	60

次に１つのステートでtrigger1=2を複数並べた際のFPSを調べました。
例 [state ]
type=null
trigger1=2
trigger1=2
・
・
・
trigger1=2

trigger数	トリガー	FPS
270000	trigger1=2	フリーズ
100000	trigger1=2	フリーズ
50000	trigger1=2	フリーズ
30000	trigger1=2	1.1
20000	trigger1=2	3.4
15000	trigger1=2	11.5～5.2
10000	trigger1=2	13.1～5.4
7000	trigger1=2	32
6700	trigger1=2	45
6500	trigger1=2	55
6000	trigger1=2	60
5000	trigger1=2	60

ステコンの場合と同数並べた場合フリーズしてしまい、大幅に減らさないと動作しませんでした。
そして上の結果より60FPSを確実に出せなかった中で最も軽かった6700個を基準として、trigger1=～のトリガー（～部分）を変えたものを並べFPSを調べました。

trigger数	トリガー	FPS
6700	trigger1=1+1	45
6700	trigger1=4/2	45～40
6700	trigger1=ifelse(1+1=99,2,2)	35
6700	trigger1=2&&2&&2&&2&&2&&・・・&&2&&2&&2（199文字）	18
6700	trigger1=2\|\|2\|\|2\|\|2\|\|2\|\|・・・\|\|2\|\|2\|\|2（199文字）	18
6700	trigger1=1+1&&1+1&&1+1&&・・・&&1+1&&1+1（167文字）	18
6700	trigger1=1+1\|\|1+1\|\|1+1\|\|・・・\|\|1+1\|\|1+1\|\|1+1（167文字）	18
7000	同上	14
10000	同上	4.4
約10000000（約112MB）	trigger1=0	60

（256文字書いていないのは、それ以上書くとエラー落ちしたため。）

&&や||を使った場合、少し重くなりましたが、同数をtriggerを並べた場合ほどは重くなりませんでした。
最後に
[state ]
type=null
trigger1=1or0
trigger2=2
・
・
・
trigger2=2
とtrigger2=2を6700個並べFPSを調べました。
trigger1=1の時は60FPSを保ち、trigger1=0の時は45FPSほどになりました。
やはりtriggerxが満たされれば、それ以降は読み込まれないので、上になるべく満たされにくい条件を持ってきたほうが良いようです。

以上をまとめると、
・一つのステートで複数行のトリガーを処理するより、複数のステートで一つのトリガーを処理するほうが軽い。
・可能なら、トリガーを複数の行にするより&&や||などで1行にまとめた方が軽い。
・よく言われているように、triggerx=0であればそれ以降のtriggerxは読み込まれないため重さに関わらない。
となりました。
内部的な話も含めてこちらで詳しく調査されています。trigger参照の重さ[制作日記]

ページのトップへ戻る