軽量化まとめ
ファイルサイズ
sff
- 余計なスプライトを登録しない
- スプライトの不要な余白を切り取る
- 出来るだけスプライトのパレット共有化(また、独自パレットが多いとownpal=1のモノが極端に処理が重くなる)
例:SAE
バックアップをとっておくこと推奨
不要な余白削除
スプライトリストで範囲選択
→右クリック
→拡張
→余白削除
パレット共有化
スプライトリストで範囲選択
→右クリック
→拡張
→パレットの統一
なお、綺麗に仕上げたい場合はSAEの機能ではなく、
製作支援ツール紹介>パレット共有にあるGraphicsGale、Unify-Bitmapなどを使う事をオススメする。
Unify-Bitmapはファイルの形式がBMP限定であることに注意。
snd
-
音質が気にならない程度に「モノラル化」(mugenでステレオである意味はあまり無い)や「サンプリングを低下」させることで軽量化
SAEやSoundEngineFreeで可能
例:SAE
バックアップを取る
→SNDタブで音声ファイル全部選択(Shiftキー)した状態(重いデータのみを選択するのもあり)で右クリック
→ダウンサンプリング(旧版:音質変換)
→自分が気にならない程度に出来るだけ下げる
処理
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
|
次に1つのステートで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参照の重さ[制作日記]