LR2スキンにおけるファイルの読み込みタイミングと動作タイミング

LR2スキンでの画像ファイルの読み込みタイミングには2通りのパターンがあります。
OS依存でも本体バージョン依存でもないため、現状では“PCによる”としか言えませんが
スキン動作開始時か定義動作開始時のどちらかになります。ちょっと面倒なことにスキン依存ではありません。

後者の場合は特にプレイスキンだと曲開始後に参照するパーツが増えるので、
どっちでも問題なく動くようにサイズの大きい画像を使用する場合は念のため DX3+cb6のようにパーツの事前読み込みを入れておきましょう。
（プレイスキンで最初の1ノーツ目がカクつく場合はこれが原因です）

つまりスキンをOA DX+ LINKに対応させるとそれなりにメモリを圧迫する場合がある、という事でもあります。
twitterでは「負荷変わらない」と豪語しましたが2通りあるって知ったの最近なんです。ごめんなさい。

スキン種別と落ちやすさ

体感では「理由がさっぱり分からない異常終了」を除けば、異常終了耐性はバックグラウンド処理が少ないほど高いです。
大体のスキンでは本体側が限界ギリギリな動作を行っているため、下手な操作を行ったり無茶なスキン構成にすると簡単に落ちますが
リザルト系のスキンは内部的にはプレイ結果の表示とLR2IRとの通信くらいしか行われないので、色々詰め込んでも意外と普通に動きます。

DST定義とfps

おそらくXP環境限定のお話。
LR2スキンでは膨大な量のパーツを同時に表示すると出力fpsが落ちます。酷い時は半減くらいまでいきます。DX+のタイトルエフェクトTYPE-6が代表的。
（1.5秒間で1050個、その後1.5秒で1050個の画像が動きます）

タイトルエフェクトは動作終了後にop分岐とloop=-1で動作を完全に停止させていますが、一度低下したfpsはそのスキンが動作している間は元には戻りません。
また、csvの行数的にはTYPE-3もほぼ同じ長さですがこちらはtime指定が複雑になっているだけで、定義数は350個となっており大幅なfps低下は発生しませんでした。
つまりcsvの行数とは無関係。
この結果から出力fpsは最大瞬間実動定義数に依存していることが分かります。

垂直同期を使用した際の挙動から出力fpsはLR2の最小キー入力インターバルであると考えられるため、
出力fpsの低下=キー入力タイミングのブレ=スコアの低下に繋がります。プレイスキンは極力軽量化しましょう。
※参考： LR2遅延対策入門 - Stairwayの一番下の考察

Win7は最大出力fpsこそXPに劣るもののXPと違ってfpsが安定しており、実動定義数が増えてもfpsの低下率がXPより遥かに少なく、
加えてスキン動作中に低下したfpsもパーツの動作が終わったら元に戻ります。

理論上はモニタのリフレッシュレート以上のfpsが出ていれば見た目に影響は無いはずですが、
負荷によって値が大きく変動するXPでは曲プレイ中に2600fpsくらい出ていてもノーツの落下がよくコマ落ちします。（2pssエンコ動画BGAだと特に顕著）

経験上、単純に最大fpsが高いよりもfpsの変動が少ない方がノーツの落下アニメーションも安定するため、
スキンの挙動に関して言えばWin7の方がLR2向きだと考えています。

画像パーツ解像度と描画面積

スキンの負荷は画像ファイルの実解像度に依存するものだと思ってましたが、実際には描画解像度と密接な関係にあるようです。
（同じ画像ファイルでもDST側でサイズを縮小すると負荷が減ります）
また、画面外にはみ出す部分は 描画が行われないらしく、fpsの低下には直接絡んではきません。
※上記の実動定義数の影響は多少受けます。

ついでに、8192x8192の画像を読み込ませた際、RB選曲は普通に動いていたのに対してDX+は即死したので
本体側の読み込み解像度限界がどこかにあると見ています。
フォント画像も関わっているはずなんで詳しくは調べていませんが、8192x8192を読み込ませてもRB選曲が落ちなかった事から
2048x2048x16枚くらいは耐えられると思われます。

スキンパーツとメモリ負荷

詳しいことは分かりませんがプログラムである以上、
スキンで使う全画像ファイルの合計解像度が増えればメモリの消費量もきっと上がるでしょう。ついでにfpsも落ちます。

デフォ選曲フォントには「サイズは256の倍数推奨」と書いてあるので、
スキン画像もある程度このフォーマットに乗っ取っていた方が安定するだろう、
と思ってたんですが実測fpsでは大差無かったのでうちのスキンはガン無視です。
16の倍数になってりゃ良いんじゃね？とかその程度です。
（全画像サイズを揃えるとかだと違うのかもしれませんが）

LR2に限らずPCゲームにおいては利用する画像のサイズは2のべき乗が望ましいと言われていますが、
これは読み込める画像ファイル解像度の最小単位が2のべき乗である事が関係しているそうで、
例えば257ｘ257の画像を参照する際には内部的に512ｘ512を取ってしまうためとかそんなんらしいです。（詳しくは知りません）

これに加えてtga/ddsといった“テクスチャに使用するためのフォーマット”を使うことでより軽量化できるのかもしれません。
LR2デフォスキンが異様に軽いのはこの辺が絡んでいると予想しています。

また、うちのスキンでは汎用性を重視して画像ファイルはすべてpng形式の最高圧縮を使っていますが、
無圧縮tgaをdxa圧縮した方が僅かに描写が早く、fpsも3%程上がりました。
（dxa圧縮すると無圧縮tgaでも色数によってはpng形式とほぼ同じサイズまで落とせます）

SSD起動のようにファイルの読み込み速度が無視出来るほど速い環境であれば、
描写速度はほぼGPU依存なので悪くはないんですが、修正時にいちいちdxa展開するのも考え物。
基本的にはフォント画像でのみ使うのが無難かもしれません。
（選曲画面のフォルダ展開速度がほんのり速いかも？程度なので、むしろフォント以外で使う理由が無い）

tgaとddsでの違いは全然分かりませんでしたが、VRAM使用量はバイト数単位でpng形式時と同じだったので、
画像フォーマットを変えてもどのみちLR2の異常終了は防げないだろうと考えています。

メモリリークはLR2本体側の不具合なのでメモリ増設しても回避出来るものではありませんが、
気にし過ぎたらいつまで経っても公開出来ないのである程度は割り切っちゃった方が製作は楽です。
落ちやすい操作さえ避ければそもそもそんなに落ちませんし、逆にどんな軽量スキン使ってても激重bms読み込んだら落ちます。