LR2スキンの仕様書に載ってない注意事項

フルセットを作ってて気付いた注意点や応用技をまとめてみました。
去年一昨年の秋ごろからチマチマ書き綴っていたら何やら凄い長さになってたので暇な時にでもじっくりどうぞ。

LR2スキンの基本的な部分は理解出来ている人向けに書いてあります。
最低限LR2スキンcsvの基礎が理解出来ていないと、おそらく読んでも意味がありません。
便宜上、定義本来の使い方と異なる用途に使うものは応用定義としました。
特に難解な応用定義には◆マークを付けてあります。

また、本文でもいくつか挙げていますがLR2ではスキンの状況やオプションによって微妙に特性が異なるので、
あまり過信し過ぎないように注意して下さい。試してみたら全然違う動作に～、という可能性も少なくないです。

以下、おそらくこのブログ始まって以来最長の記事。

仕様関連

■dst_option.txtに載っていないDSTオプション
■仕様書に書いてあるが使えない定義
■timeとtimer
■ブレンドパラメータとブレンドタイプ
■div_x・div_yパラメータ
■エフェクタボタンのピッチ
■NUMBER定義のketaパラメータ
■スキンで参照可能なフォント数
■LR2フォント調整時の注意
■拡大縮小とfilter値
■IF分岐とオプションスロット分岐
■IF命令とSETOPTION命令を使ったOR分岐とNOT分岐
■SETOPTION命令の特性
■ボタン定義の重ね順
■indexを用いた特殊定義
■サウンドセット以外の音声参照
■コースモードでは使えない機能
■DP FLIPとSP TO DP

不具合関連

■op330番台のIF分岐
■NUMBER定義のalign2（中央寄せ）特有の注意点
■op3の注意点
■リザルトスキンにおけるAUTO SCRATCHオプション分岐
■スキンカスタマイズ上限数と#CUSTOMOPTION
■コースリザルトスキンの切り替え
■HIDDENとSUDDEN
■RANDOMオプションとバトル
■フルコン落ち時のクリア判定の分岐特性

応用定義

■キーコンフィグとスキンセレクトとスキン種別
■LR2でのDSTオプション遷移
◆二重timer定義と3列コンボ
■ボタン定義のボタン以外の用途
■テキスト連動パーツ
■NUMBER定義のketaとalignの組み合わせによる特殊参照
◆テキスト定義を用いたバーグラフ
◆NUMBER定義を用いたバーグラフ
■複数個でセットになっている子csvをランダムで参照する（二重INCLUDE）
■CUSTOMFILE命令による画像と子csvの同期分岐
■バトルボタンの画像定義分岐
◆リザルトでのプレイスキンとの連携によるクリアマーク更新分岐
◆既フルコン時のMAXCOMBO差分検出によるフルコン分岐

その他

■LR2スキンにおけるファイルの読み込みタイミング
■スキン種別と落ちやすさ
■DST定義とfps
■画像パーツ解像度と描画面積
■スキンパーツとメモリ負荷
■スキン定義の応用技まとめ

仕様関連

■dst_option.txtに載っていないDSTオプション（skin_history.txtより抜粋）

選曲
46 難易度フィルタが有効
47 難易度フィルタが無効

リザルト
335 プレイランクが更新された
352 1PWIN 2PLOSE
353 1PLOSE 2PWIN
354 DRAW


■仕様書に書いてあるが使えない定義
LR2の仕様書には（未）となっている機能がいくつかありますが、
（未）になっていなくても実装されていない/機能しないものがあります。
（主にオンライン関連とリザルト関連とコースリザ関連）
元々がシーンやその時のオプション・宣言されている命令によって動いたり動かなかったりするため、
こちらでの検証が不十分な可能性もあるので具体例を挙げるのは止めておきますが、
とりあえず仕様書や噂、この解説も含めてあまり過信しないように注意しましょう。

ちなみに仕様書に書かれている「選曲用」などの区分けは「そのシーンで使う可能性が高い」程度のもので、
必ずしも他のスキン種別では使えないという意味ではありません。ものによってはホントに他では使えませんが。


■timeとtimer
スキン関連ドキュメントの説明文の中で唯一意味不明なのがtimer定義ですが、実はとても重要なパラメータです。
書かれているのはtimeの説明文で、実際にはデフォ選曲スキンに書いてある「timeはtimer値に依存」が正解です。

内部的にはtimerで指定した条件を満たした瞬間がそのパーツにとってのtime0となり、
そこからの動作内容をtimeやloopで指定します。
ほとんどのスキン定義はtimer0 スキン動作開始時 を使うため「スキン内でのタイミング指定はtimeで行う」と
考えがちですが実際にはtimer定義あってのtime値になります。
同じtime0のパーツでもtimerの値が違うと動作開始タイミングが異なるので気を付けましょう。

なお、timer140 リズムタイマー のみtime1000=1拍（time4000=1小節）となっており、
小節毎にリセットされるので注意。（loop値は0以外を使っても意味無いです）

※タイマーで動作し始めたパーツのアニメーションを後から停止させることは出来ません。


■ブレンドパラメータとブレンドタイプ
参照画像/動画の透明度はブレンドパラメータ（a値）で256段階の調節が可能ですが、
ブレンドタイプ（blend値）を0以外にしないと適用されません。地味ですが大事。


■div_x・div_yパラメータ
大体はスキン見れば想像付くとは思いますが一応補足。
div_xとdiv_yによる分割アニメーションの並び順は横方向優先です。
分かりやすくNUMBER定義で図にしてみましたが、NUMBER定義に限らずLR2では必ずこうなります。

30分割はcycle値で指定された時間（単位：ms）で3色点滅する10分割NUMBER定義です。

24分割辺りだと約数が多いのでスペースを有効に使えますが、11分割は縦・横いずれかで
1列に並べるしか方法が無いので、どんなに頑張ってもそこそこのサイズになります。
なお、NUMBER定義は10or11or24のいずれかの整数倍、BUTTON定義は各ボタンタイプ毎の分割数厳守。
多かったり足りなかったりすると正常に動作しません。
ちなみにボタン定義はNUMBER定義のように規定数の整数倍に分割してもアニメーション出来ないので、
アニメーションさせるには複数のボタン定義をtimeでガッチリ区切って無理矢理表示を切り替えるしかありません。
（ClassicスキンのLR2files/Theme/Classic/FX/FX-TYPE-1/TYPE-1.csv参照）

また、ボタンtype11 現在の鍵盤数フィルタ(全体) 等は使用している難易度フィルタや鍵盤数フィルタで
実際に動作するボタン数が変わってくるので動作確認時には注意が必要です。

ついでに3色点滅についても触れておきますが、
赤青緑の3色点滅パーツは白を混ぜ込んで気持ち明るめにしておいた方が目に優しいです。



■エフェクタボタンのピッチ
ボタンの分割数絡みで一点だけ注意事項。
type20からのFX名はbutton.txtではピッチを含めた9種類が書かれていますが、
現行のLR2ではピッチはここには含まれません。別枠でtype32と33に分離されています。
※ただし9分割でもピッチを飛ばしてオフに戻るので特に問題はありません。


■NUMBER定義のketaパラメータ
number.txtでは「ketaは+-文字を含めた桁数です」と書かれていますが、
実際にはketaで指定するのは+-符号を含まない桁数です。


■スキンで参照可能なフォント数
1つのスキンで参照できるLR2フォントの数は10個までです。
環境によっては11個以上定義したスキンを使うと即落ちするらしいので注意。
フォント定義が10個越えることはあまり無いとは思いますが分岐ミスでの重複読み込みなどには気を付けましょう。


■LR2フォント調整時の注意
lr2fontファイルはスキンcsvや画像・動画等と扱いが異なるようで、LR2起動中に変更しても適用されません。
（スキンを一瞬でも読み込ませるとlr2fontファイルがLR2body.exeにロックされます）
このためスキンオプションで切り替える場合でもLR2の再起動が必要です。
※lr2fontファイルから参照される画像ファイルはロックされませんが、
　 dxa圧縮している場合はパッケージごとロックされるためLR2起動中は展開出来なくなります。

スキンの頻繁な変更でLR2が落ちやすくなるのはこれのせい、というのが.REDの私見です。
誤って別なスキンを読み込まない様にThemeフォルダの中は常用するスキン以外置かない、というのが
異常終了回避の有効な方法の1つだと思います。


■拡大縮小とfilter値
主にエフェクト系の話ですが、徐々に拡大（縮小）する透過（あるいは加算）パーツにfilterを使ってしまうと
アニメーション中にSRCの境界線が見えてしまう事があります。

このため拡縮パーツをぼかしたい場合は本体側のfilterではなく、SRC画像側をあらかじめぼかす必要があります。
（LR2のfilterは基本的にはBGA用です。また、仕様書によると処理が重いらしいので多用は避けましょう）
※画質を追求すると最終的には可逆圧縮動画かdivアニメーションになります。


■IF分岐とオプションスロット分岐
便宜上オプションスロットと表現しましたがこれはDST定義のop1～op3で指定する条件分岐の事です。
これらは一見すると同じものですが実際には参照する機能によって使い分けが必要です。

・IF分岐
スキンの動作開始時にのみ、一回だけ分岐を行います。
このためスキン動作中に変動する値に対しては効果がありません。
（プレイスキンでのランク表示や選曲スキンでの難易度など）
ログ取ると良く分かるんですがIF+INCLUDEの子csv条件分岐だと
条件から外れた場合は子csvの読み込み自体スキップされるので、
下手に定義削ってcsvの軽量化を図るよりも子csvに分岐させまくった方が、
機能を維持したまま安定化できます。（ただしフォルダ内が煩雑化するのでファイル管理が面倒です）

・オプションスロット分岐
スキンの動作中に条件が切り替わると、その都度ON/OFFが切り替わります。
選曲スキンのパーツ類はほとんどこっちで組まないと意味無いです。
ただし、当然ながらDST定義でしか使用できないため、読み込む画像やフォントの変更といった
スキンの根幹の動作に絡む部分には利用できません。
条件の真偽に関わらず定義はスタンバイ状態になるため、
スキン全体の読み込み速度は理論上僅かに遅くなります。（未確認）

スキンの構成にもよりますが通常スキンオプションはIF分岐で組まれるため、
動作中のスキンのスキンオプションを変更してもスキンの再読み込みを行わないと反映されません。
（RB選曲のスキンカスタマイズパネルに選曲スキン用のオプションが無いのはこの為です）
また、読み込みそのものをスキップする仕様を考えると優先順位はおそらくIF分岐→スロット分岐になります。


■IF命令とSETOPTION命令を使ったOR分岐とNOT分岐
どちらも99個しか使えないスキン固有のDSTオプションのうち1個を使うので必須かと言うとやや微妙。
ただ、条件が2個程度であれば分岐させる必要はありませんが、これが10個20個になると作った方が確実です。

OR分岐
条件Aと条件BのどちらかがONならop900がON

#IF,条件A
#SETOPTION,900,1
#ENDIF

#IF,条件B
#SETOPTION,900,1
#ENDIF


NOT分岐
条件A以外ならop900がON

#IF,条件A
#ELSE
#SETOPTION,900,1
#ENDIF

NOT分岐は特にDSTオプションでONのみしか用意されていなくて、
かつIFで複数定義をごっそり分岐させたい時にあると便利です。


■SETOPTION命令の特性
SETOPTION定義は特定のDST値をONにするだけでなく、OFFにすることも可能ですが
同一csv内でONとOFFを宣言した場合は後に記述した方が適用されます。（ちなみにFLIPRESULT命令なども同様）
また、当然と言えば当然ですがSETOPTIONでON/OFFを制御できるのは900番台のオプションだけです。

ただし、通常オプションも全てSETOPTIONで900番台にリンクさせてからスキンを組んでいけば
通常オプション用の機能も強制的にONに出来るようになります。


■ボタン定義の重ね順
ボタン定義を複数個重ねた場合、マウスでクリックするとcsv内で先に記述したボタンから順に押されます。
（重ねたボタンがクリック不可設定であれば先に記述されているボタンもクリック出来なくなるので
　誤クリック防止に使えます ※利用できるのはそのシーンで動作可能なボタンに限られます）
複合ボタン定義はRED BLET KEYCONFIGで使われています。
詳しくはRED_BELT/KeyConfig/keyconfig.csv内を「//TEST PLAY PANELボタン本体」で検索して下さい。

※テストプレイボタン動作詳細
　 テストプレイモードに入る際には必ずキーコンフィグ選択を「OFF」にしておかないと
　 テストプレイでボタンを押した時に片っ端から割り当てられてしまいますが、
　 ワンクリックで「OFF」に持っていく方法が無いので1P1鍵→鍵盤変更ボタンplusonly=2（逆順）の
　 順番でボタンを重ね、更にテストプレイパネル起動ボタンを重ねてます。


■indexを用いた特殊定義
LR2スキン定義の中には、そのスキン種別でしか参照できない特殊定義があります。
（選曲バーやグルーブゲージ、スコアチャートなど）
これらは往々にしてindex値でその動作を指定しますが、
原則として同じ定義に同じindexの組み合わせは同一スキン内に2つ以上配置出来ません。
このため、op1～3による動的分岐は設定しても効果がありません。（IF分岐のみ可能）
無理矢理定義しても後に記述した定義の方しか動作しません。


■サウンドセット以外の音声参照
音声トラック付きの動画を読み込ませれば音出るかと思って試しましたが無理でした。
この事からLR2で参照される動画データの音声部分は再生されないという事も分かります。（BGAも同様です）


■コースモードでは使えない機能
コースモードではSTAGEFILEやBACKBMP等のbms側で用意されている画像や、
判定ランクやソフラン有無などの譜面データが参照出来ません。（BGAは可）
参照出来るのはせいぜい難易度種別（NORMAL/HYPERなど）ぐらいですが
これもコースステージ毎にキッチリ分岐させないと何故か正常に表示されません。
※動作オプション解析によりDX3やDX+ほど長々と分岐させなくても動くっぽいことが判明してます。


■DP FLIPとSP TO DP
仕様か不具合かでちょっと迷いましたが仕様に分類しておきます。
DP FLIPオプションはRANDOM/MIRROR等と同じように本体側で制御されている機能であり、
プレイスキン側で専用の定義を作る必要はありません。
で、先日初めて聞いたんですがSP TO DPオプション使用時はDP FLIPが使えません。
おそらくSP TO DPも本体側で制御されている機能だからだと思われます。
※DX+次期バージョンではDPスキンのレーンを無理矢理反転させる「SP TO DP FLIP（仮）」オプションを実装予定。

不具合関連

■op330番台のIF分岐
op330 スコアが更新された から始まるリザルト用のオプションですが、
これらのオプションはプレイ・リザルトスキンに#FLIPRESULT命令が含まれているとIF分岐では正常に動作しません。
ただしDSTオプションスロット（op1～op3）では何故か動きます。
優秀なスキン屋さんであれば「DISABLEFLIP使えばいいじゃん」と思うかもしれませんが
残念ながらこの不具合はDISABLEFLIP命令を使っても回避出来ません。

厳密には「ミスカウント0の場合のみ正常に動作可能」だったり、
いくつかのオプションは問題無く動いたりと色々特性があるんですが使用する場合は一応注意。


■NUMBER定義のalign2（中央寄せ）特有の注意点
DST_NUMBERのw値が奇数の場合、裏0無しのalign=2で奇数桁（1桁や3桁）を表示すると画像がバグります。
10分割NUMBER定義で中央寄せを使う場合は注意。


■op3の注意点
主に選曲スキンで使用されるop3 カーソルがコース に関する注意点です。
このオプション、通常は問題ありませんがIRランキング閲覧中には強制的にオフになります。
また、コースモードはランキング閲覧中のみ内部的に曲扱いになるらしく、op2も自動的にオンになります。
op290 コースモード は正常に動作するため、コースモードのop指定には290（あるいは!290）を使いましょう。

曲とコースでキッチリ分岐させるにはop2 AND op-290 と op290 で分岐させる必要があります。


■リザルトスキンにおけるAUTO SCRATCHオプション分岐
「option142 AUTO SCRATCH (自動皿抜きでクリアすれば消えます) 」はリザルト演出後、
選曲画面に戻らないとONになりません。
このためRBリザではop55 AUTOSCRATCH 1P ON とop90 クリア のAND条件で代用しています。
※改めて確認したら普通に動いてました。「場合によっては動かないかも？」くらいの認識で。
ちなみに自動皿抜きでクリアしても消えないのは結構有名なお話。
この定義部分を作った時期を考えると前述のFLIPRESULT命令が絡んでいる可能性も少なくないですが試してません。


■スキンカスタマイズ上限数と#CUSTOMOPTION
スキンカスタマイズの上限数は40個までですが、21個目以降では#CUSTOMOPTIONは動作しません。
このため#CUSTOMOPTION命令は20個以内に抑えて先に記述し、
21個目以降は#CUSTOMFILE命令のみにする必要があります。
ただし、CUSTOMFILEで子csvを選択する方法を使うと40個まで可能です。※後述
また、カスタマイズオプション数が21個を超えるとDX+同様、カスタマイズ関連のバグが発生します。


■コースリザルトスキンの切り替え
スキン製作とは直接関係ありませんが、LR2の設定ファイルには
最後に使用したコースリザルトスキンを保存する箇所が存在しません。
このため、LR2上で切り替えたコースリザルトスキンはLR2を再起動すると元に戻ってしまうことがあります。
正確には「パスが一番若いコースリザのlr2skinファイル」が優先的に選択されるため、
デフォスキンにhtコースリザを追加した場合は問題無く動きますが、RBコースリザだとデフォスキンに戻ります。

パスが若ければ良いだけなのでlr2skinファイルの配置だけ変更すれば解決出来ますが、
（基本的にlr2skinファイルからの相対参照は張られないため、
　lr2skinファイル自体はLR2filesフォルダ以下であれば何処に置いてもスキンは正常に動作します）
readmeに一筆書く位の優しさが必要です。


■HIDDENとSUDDEN
現状のDX+では正常に動作していませんがこれはスキンの構成に関係しています。
LR2でのHIDDEN・SUDDENオプションはノーツ定義の前に記述されている定義の数によって、
ノーツの出現・消滅位置が変動するという不具合がLR2サポート掲示板で報告されています。
（さくっと試した感じではcsv全体の定義総数も影響してるようでした）

つまり、DX+では実際にはオプションは有効になっているがエフェクト位置が画面外になってしまい、
HIDDENではノーツが表示されずSUDDENは効果が無いように見える、という状態。
割と誤解されがちですが.REDがHIDDEN・SUDDENを実装していないという事ではありません。
（そもそもこれらの機能はスキン側ではなく本体側で制御されているため、意図的に排除する事は不可能です）

ただ、DX+だとよりによって.REDが最も重視しているフレーム組み立てとタイトルエフェクトを
ごっそり吹っ飛ばさないと駄目なので永遠に未対応です。

ノーツ関連記述の前の定義数が少なすぎても出現・消滅位置が下に下がってしまうため、
レーンの真ん中に合わせるにはかなりシビアな定義個数の調整が要求されます。
この定義個数は#から始まるスキン定義の合計っぽいのでDSTだけ水増ししていけば多分正解に辿り着きます。
※定義総数が絡んでるせいでDX+では何やっても効果が無かったので細かい部分までチェックしてません。


■RANDOMオプションとバトル
割と有名な不具合ですがLR2ではバトル時に左右で別々の譜面オプション（RANDOMやMIRRORなど）を使うと
左右のトータルノーツが一致しなくなります。 ※降ってくるノーツの数は左右ともデフォ譜面と同じです。
（厳密にはトータルノーツからどちらかのラスト数ノーツが減り、その分が反対側に加算されます）
リザルトでも同様の表記になるため、内部的なトータルノーツが狂う形になりますが
フルコンタイマーは何故か元のトータルノーツで動作するため、
不具合発生時にはどちらかのフルコンエフェクトは動作しなくなります。
譜面によっては2P側が減ったり、稀に正常に動いたりしますが詳細は不明です。
オートプレイでも発生するので動作確認時は特に注意しましょう。


■フルコン落ち時のクリア判定の分岐特性
LR2ではフルコン時にゲージをごっそり減らしてクリア失敗すると「フルコン落ち」というバグが発生します。
以前twitterの方ではP-ATTACKについて言及しましたが、LR2BBSの不具合報告を漁ってみると
ノマゲでも同様のクリア判定になっているらしいので、おそらく同種のバグと考えて良いでしょう。

このバグ自体はスキン側では回避不能ですが、この時のオプションの分岐が定義によって異なります。
IF定義でop90 クリア op91 クリア失敗 の分岐を組むとクリア扱い（op90がON）になりますが、
オプションスロットでop90/91分岐させるとクリア失敗扱い（op91がON）になります。

※なお、これとは別枠でクリアマークは本体側の仕様として

・曲単体プレイ時にフルコン落ちした場合はフルコンクリアランプが点灯
・コースプレイ時にフルコン落ちした場合はFAILEDランプが点灯

となります。

以上の各特性を把握した上でこれらの挙動に合わせてcsv組もうと思えば組めないこともないですが、
とりあえずRBリザルトではOA DX+ LINKオプションの仕様上、
オプションスロット分岐ではクリアマーク更新表示が実現出来ないため対応できません。

応用定義

■キーコンフィグとスキンセレクトとスキン種別
キーコンフィグとスキンセレクトにはスキン固有の特殊定義が存在しないため
スキン種別に捉われずに全機能が参照可能なのでRB選曲のように「別なスキンに擬似的に実装」することが出来ます。

スキンプレビューも現行のLR2では特殊定義を使わなくなっているのでRB選曲でも実装は可能でしたが、
断念した理由は単純にスペースが足りなかったからです。
（スキンやスキンオプション切り替え時には必ずバックグラウンドでスキンプレビュー用パーツの
　再読み込みが行われるため、プレビューを非表示にしても負荷は変わりません）
また、キーコンフィグを積まなかったのは利用頻度が低く、万が一マウスやボタンが暴発すると面倒だからです。
今にして思えばスキンセレクトとキーコンフィグはまとめて1つにした方がCSっぽかったかなぁとか。

実用性は低いですがこういうのも可能ではあります。

※画像はイメージです。


■LR2でのDSTオプション遷移
本来は仕様のとこに書くべきなんですが、なかなか興味深かったので応用に。
LR2では通常、選曲→決定→プレイ→リザルト（→コースリザ）間では曲に関連するオプションは変化しません。
（現在のスキンでの曲オプション状態は次のスキンでも維持されます）
ここまでは当然なんですが先日組みあがったDSTオプションの動作解析システムで色々試していたところ、
リザルト→選曲間でも大部分のオプション値が引き継がれることが分かりました。
何パターンか試した感じだとop70～349までは大体引き継げるようです。
一部のオプションはLR2起動直後の選曲画面で既におかしな値を返すので
実装の際にはなるべく自前で動作DSTオプションを解析できる環境があった方が良いと思います。

取り敢えずうちで軽く試した結果だけ纏めておきます。この利用方法では以下の値の使用はなるべく避けましょう。

・op80番台はプレイスキン以外では正常に動作しません
・op100～145は今回の値かどうか判別できません
・op280番台はどのシーンでも必ずいずれかの値がONになります（大体は280か289）
・op333 トライアルが更新された はリザルト以外では正常に動作しません（ほとんど常時ON）

※動作オプションはスロット分岐とIF分岐で特性が微妙に異なります。（ここに挙げているものは全てIF分岐の測定結果）

これを使うと例えば「☆12以上の譜面を赤ゲージでAAAクリアした後の選曲画面背景」をピンポイントで変更出来ます。
選曲BGMには手が出せないので旧CSシリーズのアレにはあと一歩な感じも否めませんが夢は広がりますね。
もうちょい早く知りたかったです。

なお、コースリザルトからの引き継ぎは出来ないっぽいですが、
スキンセレクトのリザルトプレビューからは引き継げたので動作確認はここから行ったほうが早いと思います。
（スキンプレビューでクリアリザルトプレビューを表示するにはスキンセレクト動作開始直後のプレイスキンプレビューを
　曲進行バーが停止するまで見届ける必要があります。これより前に別なスキンに切り替えるとFAILED扱いになります。
　この方法で表示されるリザルト画面は必然的にスコア/ゲージ共に100%でのフルコンクリアになります。
　ちなみにオートプレイ時のリザルト画面はこの方法でしか見れません。）


◆二重timer定義と3列コンボ
動画になりますが元々はこちらのスキンの3列判定表示で使われている手法です。（多分）


またしても便宜上二重timerと書きましたが、これはキーオンタイマーとジャッジタイマーを同時に使用することで
「判定動作中に特定のキーの入力」を条件にパーツを表示する（と思われる）参照方法です。恐らく他に方法が無い。
つまり、SRCのtimer値にtimer46 1P ジャッジタイマー、DSTのtimer値にtimer100番台のキーオンタイマー。
簡単にしか試してませんがおそらく「同時に発生する場合があるtimerの組み合わせ」に限って使える特殊な参照法。

実は一番の肝は表示位置が変わるところではなく、常に1個しかコンボ表示が出ないところなんですが、
これについては後の動作解析により、上からレーンカバー被せてるんじゃ？という結論に至りました。

LP EXでの3列コンボ実装時にみすてぃ氏に軽く助言はしたものの、
実際の定義が.REDの予想よりも遥かに込み入っていたためちょっと自信無いんですが簡単に纏めますと

・op240番台と二重timerを用いた定義で判定文字とコンボ数値を参照する
・1～3鍵/7～9鍵タイマー動作時はそれぞれ反対側のコンボ表示にレーンカバーを被せる
・456鍵タイマー動作時はセンターコンボ表示優先

大体こんな感じだと思います。
一応レーン周りの立体構造図作ってみましたが複雑過ぎてあまり意味が…


3列判定表示は既にLP EXに実装されているので
詳しくはOA_LP_EX/standard/common_csv/3line_frame.csvと3line_judge.csvを参照。

構造上の欠陥としてコンボ表示の上にノーツが表示されたりコンボ表記が横に瞬間移動したりするんですが
.REDの考えていたLR2での9keyスキンの限界点を僅かに越えている奇跡の技。
この応用定義のオリジナルを作り上げた作者さんの名前が分からないのが悔やまれます。


■ボタン定義のボタン以外の用途
DX+ではHAZARD/P-ATTACK/G-ATTACK使用時の%表記点滅に利用したのでこれを参考に解説。
DSTオプションではノーマル/赤ゲージでしか分岐出来ないため、
例えば「HARD使用時のみ」といった条件を使うことが出来ません。
そこでゲージオプションボタンを画像パーツとして扱うことで擬似的に挙動を変更する方法をとっています。


フレームパーツ内に％表記ボックスをボタン用画像として複数個配置しておき、
これを上から重ねて点滅表示させることで％数字そのものが点滅しているように見せています。
（詳しくはDX+のAC7left.csv内を「G-ATTACK用グルーヴカバー」で検索）
基本的には「上から被せる」事しかできないので、条件を満たした場合に表示するor隠す、
といった限定的な使い方しか出来ないため、実装には何らかの工夫が必要ですが応用の幅は広いです。

これと同様の手法でグルーブゲージにエフェクトを掛けることも可能ですが、
ゲージの点滅は半透過点滅ではなく、明暗点滅なのでもう一捻りしないといけません。
また、ゲージ関連の分岐はLR2の仕様上リプレイとの整合性が取りにくいので気を付けましょう。
※プレイスキンのDSTによるノーマル/赤ゲージ分岐は、IF/オプションスロット分岐共に
　 その時に使用しているゲージオプション優先になります。（リプレイにはDSTオプションの変更権限が無い）


■テキスト連動パーツ
例としてRBコースリザルトの段位別リザルトの説明を。
段位によって背景画像を切り替える、と考えると難易度高いんですが
やってる事はlr2fontファイルで「段位漢数字のみを640x480の画像で表す」というもの。
lr2fontで漢数字の初～十と、皆伝用に「皆」の文字（以下、識別文字）だけ個別の画像を定義し、
それ以外の文字は全て1x480の画像を使い、#M定義（文字間隔）を-1にします。
※他の文字もちゃんと定義しておかないと挙動がおかしくなります。
これで一文字につき-1pxシフトするため全体の文字数に関わらず、
初～十と皆の文字画像を所定の位置に表示出来ます。

RBコースリザルトでは更に「発」の文字に640x480の透明画像を割り当てることで
発狂段位の場合のみ右に640pxシフトさせて発狂用と通常用で別々の画像を表示させています。
このため、一文字当たりの横幅は発狂用と通常用合わせて1280x480になっています。



発狂用と通常用で別な画像を表示させることが可能だと気付いたのがv1.00公開の5日前だったため、
RBコースリザでは色違いを表示する形を取りましたが、これは当然色違いじゃなくても大丈夫です。

注意点はマニュアルにも書きましたが、常に一文字しか表示できないこの方法では
必然的に左側の識別文字が優先になります。
例えば 「段位認定 十五段」の場合には十段用リザルトが表示されます。
また、公開後に何回か問い合わせが来ましたが段位数字の半角/全角英数表記には対応していません。
単純に面倒だったのも大きいですが「10段」表記の解決案が咄嗟に思い付かなかったので。

このフォーマットのlr2fontファイルは誰が作っても大体同じものになるので利用したい方はご連絡下さい。
ファイルの場所はLR2files/Theme/RED_BELT/font/Gradefont_SPBG.lr2font です。
また、このlr2fontファイルでは上位階層への相対参照も使っているので
ちょっと離れたフォルダのファイルを使いたい場合もご参考下さい。
スキン側のテキスト定義は
LR2files\Theme\RED_BELT\CourseResult\grade.csv内を「テキストを背景画像扱いに」で検索して下さい。

※関連定義近辺のコメントにある右寄せ云々は開発段階のもので現行フォーマットではalign0（左寄せ）で大丈夫です。
※公開してしばらく経つまで気付きませんでしたが、LR2公式段位には通常皆伝が存在しませんので
　この方法だと公式段位で皆伝リザルトが表示されるのは「発狂皆伝」のみです。滅多に見てもらえないので注意。
※半角/全角/大文字/小文字が面倒だったので実装しませんでしたが「overjoy」のいずれかの文字を使うことで
　 overjoy用リザルトも可能っちゃ可能です。ゴリラの上を表現するイラストが思い付かなかったので止めましたが。
※RBリザルトのIRメッセージでも参照する識別文字は異なりますが同じ手法を使っています。


■NUMBER定義のketaとalignの組み合わせによる特殊参照
alignはketa数の中で右寄せ(=0)か左寄せ(=1)か中央(=2)を指定しますが、
表示桁数が足りない場合にはalignによって表示される値が異なります。

例 本来1234と表示される項目に対してketa=2を使用した場合

・align=0の時は12のみ表示
・align=1の時は34のみ表示
・align=2の時は12のみ表示

これによりNUMBER定義keta=1で数値の先頭/終端桁のみを参照することが出来るため、
本来DSTオプションでは分岐出来ないパターンで分岐させることが可能です。
（馬鹿でかい数字画像を使って画面外の座標を指定すれば先頭/終端桁以外も参照可能 *後述）

例 ミスカウントが0の時に「ノーミス」と表示する場合
　 align0keta1でミスカウントを参照し、数字画像の0部分にのみ「ノーミス」と打ち込んでおく
→ミスカウント10や20の場合は1や2になるため画像は表示されず、0の場合のみ画像が表示される

RBリザの全一表示やボーダークリアなど、リザルトを中心に応用が利きます。
先頭/終端桁以外を参照するにはちょっと負荷が高すぎるのでリザルト以外での参照には注意が必要です。
なお、以前RBリザでこの参照方法絡みの不具合が発生した際、「分割方向で特性が変わる」と推測していましたが
後の追跡調査により単にalignの指定ミスだったと判明しました。その節ではお騒がせして申し訳ないです。


◆テキスト定義を用いたバーグラフ
詳しくはht51 -Deep Forest- v2選曲スキン参照。ht51v2_select.csv内を「発狂バー用」で検索して下さい。
この手法の肝は文章にすると「テキスト定義を用いた数値データの桁数別参照」。
基本概念はfivemaniaのダンサーに近いんですが、この方法には黒カバーが不要という利点があります。
EX LEVEL以外の数値はNUMBER定義で参照できるため基本的にはEX LEVEL専用の手法ですが、
このalignの使い方は他の様々な定義に応用出来るので覚えておいて損はないです。

RB選曲でもEX LEVEL表示機能で「EX LEVEL=0の場合のみ"0"を表示しない」という動作が必要になったんですが
EX LEVELはテキスト定義でしか呼べないので、桁数ごとに異なる画像を参照するために同じ手法を使ってます。

こっちの方が図にし易かったのでRB選曲の例で解説。（ここでの図解は厳密にはテキスト定義のNUMBER定義扱い）
黒の太字がEX LEVELで緑・赤・青はそれぞれ別のテキスト定義を表しています。
各定義のalignと役割は図参照。なお、図ではそれぞれのy位置をずらしていますが実際には同じ高さに表示します。



・EX LEVELが一桁の時（図の上、EX LEVEL=5）
赤定義と緑定義はそれぞれ左と右に寄せているため一桁の場合は画面外に表示されます。（つまり表示されない）
青定義のみ中寄せで画面内に表示され、発狂レベル5となります。

・EX LEVELが二桁の時（図の下、EX LEVEL=25）
赤定義と緑定義の1桁目と2桁目が画面内に現れて、同時に青定義は画面からはみ出します。
この時の表示は発狂レベル25になります。

青定義の「0」を透明にしておくと「発狂レベル0の時だけレベル数字自体を表示しない」定義になります。
ht51ではこの次の解説にある「NUMBER定義のバーグラフ参照」と併用し、
TEXT定義→NUMBER扱い→BARGRAPH扱い とする事でほぼ完璧な発狂レベルバーを実装しています。
ここの解説風に言えば応用定義を2つ組み合わせている形になります。moge-laaさんマジ天才。
（ただ画像をじっくり見ると分かるんですが、EX LEVEL3桁時に表示がおかしくなります）

注意点としては青定義が2桁時にしっかり画面外に出るように横幅を調整するところくらいでしょうか。
定義自体の難解さも超一級品ですが、この安定度は応用定義の中でもトップレベルです。
この方法を使えば理論上、テキスト定義で参照できる全ての数字でグラフが組めます。
最大値が決まっている場合であればおそらく擬似的なスライダーも表現出来るはずです。
「NUMBER定義のketaとalignの特殊参照」以上の負荷が掛かるのと結構な数のフォント定義を消費するので
実装する場合は設計段階で組み込んでおかないと後からの追加は結構メンドイです。


◆NUMBER定義を用いたバーグラフ
おおよそ上記と同じ作りでNUMBER定義型のグラフやスライダーも実装可能です。
こちらも一桁目と二桁目で別々の画像を参照するところが肝。
.REDは今のところグルーブゲージを参照する以外に面白い応用方法が思い付かないのでとりあえずそれを例に。

一桁目と二桁目を別々なNUMBER定義で参照し、これらを重ねて定義します。
二桁目はht51 -Deep Forest- v2/Select/hakkyo_bar/hakkyo_bar_dai.png の下半分のように
一桁目表示部分だけ穴を空けた特殊なゲージ画像が必要なので注意。

alignによっては11分割NUMBER定義（裏0あり）じゃないと表示位置がズレます。
また、実際には画面内に重複しないように上記テキスト定義同様、横幅を大きめに取る必要があります。

三桁になった時（100%時）は00%時と同じ画像になってしまうので、
op240 1P 100% を使って100%状態のゲージも上から重ねておきます。

そこそこ重くなりますが粒の数を任意の数に変更出来る点に加えて、GROOVEGAUGE定義と違って
ゲージ右端のアニメーションを無効化する事が可能なのでちょっと面白いゲージにはなります。
ただし、NUMBER定義で参照されるグルーブ数値は2%刻みなのでこの方法でも最大50粒が限界です。
見た目だけなら100粒でもいけますがどのみち2%ずつしか動きません。

また、定義と画像サイズが増えてしまいますが、
ゲージ一桁目をop230番台のグルーブゲージ量別分岐でガッチリ分ければ
オリジナルのゲージアニメーションを実装することも可能です。
この場合は10％刻みで個別のcycleやtimerを設定出来るので
BPM連動やDJランク連動、ゲージ量連動などの変則的なアニメーションパターンが組めます。
ちなみにClassicのゲージアニメーションは次期バージョンからBPM連動になる事が確定しています。
試作品が素敵過ぎた。

※2%上がるとゲージ1粒分右にシフトする数字画像が必要です。

色々試しましたが本体側の仕様上分割定義は横方向優先であるため、
最終的には横分割NUMBER定義にしないと危険なサイズになるので最初に縦分割で形だけ整えてから


横分割に並べ替えて


縦にズラッとコピーしまくってからアニメーションパターンを組む、という手法が一番楽でした。


※見れば大体分かるかと思いますが、LR2純正のゲージ定義と比べて結構なサイズの画像が必要です。
　 （試作品は1000x2000くらい使ってます）
※緑ゲージ・赤ゲージに加えて緑→赤ゲージ（ゲージ80%前後）を作らないといけません。
※50粒以外だと粒数計算がスゲー面倒です。（上記に加えて4・5粒混在パターンが必要になります）

なお、ゲージ関連の分岐はLR2の仕様上リプレイとの整合性が取りにくいので気を付けましょう。
※プレイスキンのDSTによるノーマル/赤ゲージ分岐は、IF/オプションスロット分岐共に
　 その時に使用しているゲージオプション優先になります。（リプレイにはDSTオプションの変更権限が無い）


■複数個でセットになっている子csvをランダムで参照する（二重INCLUDE）
過去記事参照


■CUSTOMFILE命令による画像と子csvの同期分岐
以前試した時は失敗した気がしたんですがLPforWide（現LP EX）での設定を見て正解が分かりました。
CUSTOMFILEでの対象をフォルダにしておき、そのフォルダ内にIMAGE命令を記述した子csvと画像を入れることで、
スキンオプション側でフォルダが固定されると画像と子csvが一緒に切り替わる、という流れ。
差分製作時に子csv必須なので汎用性がやや落ちる（差分製作難易度が高くなる）のがネックですが、
それをカバー出来るくらいの拡張性があります。（フレームごとに専用の組立モーションを使ったりとか）
また、CUSTOMFILEで参照する子csvの切り替えが可能という事は、CUSTOMOPTION命令じゃなくても良くなるので
オプション分岐項目を20個以上実装できるという事でもあります。

CUSTOMFILEからの子csv指定も久々に試したら普通に動いたので、
後々選択肢を追加する場合がある機能はこれの方が良さげ。
900番台のオプションを消費しない・子csv作ってフォルダに入れるだけ、というのは魅力的です。
が、v2.8系で採用しなかったのはプリセットのようにSETOPTIONからの一括固定が出来ない為です。


■バトルボタンの画像定義分岐
バトルボタンではSP/DP/9keysによってボタンの機能が異なるため、
バトルオプション用ボタンの項目名はテキスト定義で動的にボタン文字を切り替えるのが一般的ですが、
やや強引ではありますが以下の方法で個別のボタン画像を表示させることが出来ます。

DOUBLE BATTLE・GHOST BATTLE・SP TO DPがONの時は元データ種別がSP・DP共にONになるため、
これを逆手にとって各鍵盤種別ごとにがっちり分岐させます。

op160 and op!162 元データが7keys かつ 元データが14keysではない or
op161 and op!163 元データが5keys かつ 元データが10keysではない
→ SP用バトルオプション（BATTLE～）

op!160 and op162 元データが14keys かつ 元データが7keysではない or
op!161 and op163 元データが10keys かつ 元データが5keysではない
→ DP用バトルオプション（COUPLE～）

op160 and op162 元データが7keys かつ 元データが14keys or
op161 and op163 元データが5keys かつ 元データが10keys
→ DOUBLE BATTLE or GHOST BATTLE or SP TO DP → SP用バトルオプション（BATTLE～）

op164 元データが9keys
→ 9keys用バトルオプション（～9 TO 7～）

リザルトスキンではこの分岐だと何故かGHOST BATTLEが上手く表示されませんでした。
オプションスロットでの分岐では3条件までしか設定できないため、1つの定義につき4条件が必要なこの方法では
アルファブレンドや加算などの透過が含まれる参照方法の場合だと全分岐パターン（7定義）必要です。

RB選曲とリザルトで使っていますが確かリザルトの方が分かりやすいはずなので
RED_BELT/Result/result.lr2skinを「//ボタン画像(バトル7keys)」で検索。

なお、選曲スキン以外では元データの鍵盤種別は変化しないため、
#IF命令を使ったOR分岐でも行けるかもしれません。（未確認）


◆リザルトでのプレイスキンとの連携によるクリアマーク更新分岐
プレイスキン側でop100番台によるプレイ前のクリアマーク画像の分岐読み込みを行い、
その画像をCONTINUE命令で引き継ぎリザルトスキン側で再度op100番台の分岐を掛けて更新を割り出します。
コースモードでも同様の機能を実装するにはリザルト後に再びプレイスキンに戻る場合を考慮して
プレイスキン側もCONTINUE命令を使わなければならないので
分岐読み込みは決定スキンの段階で行う必要があります。（RB SKIN LINKオプション）

	決定スキン	プレイスキン	リザルトスキン	コースリザルト
単曲プレイ時	―	分岐読み込み	分岐表示	―
コースプレイ時	分岐読み込み	CONTINUE	CONTINUE	分岐表示

分岐読み込みはOA_DX+/setting/result_parts.csv、
画像ファイルはRED_BELT/Result/Clear_Markフォルダ内参照。
分岐表示はRED_BELT/Result/UPDATE/ACtype1P.csvか
Course.csvを「//クリアマーク更新」で検索して下さい。

なお、ASSISTクリア（op142）がONの時はEASYクリアも同時にONになっているので、
ASSISTも表示したい場合はIF op142→ ELSEIF op102の順に分岐させないとASSIST画像を取得出来ません。
※ASSISTクリアはASSIST抜きでクリアしても消えないので
　 ASSIST→EASYの更新マークは実質更新無し扱いになります。

初フルコン時はこれで対処可能ですが2回目以降のフルコン時にはプレイスキン・リザルトスキン共に
フルコンボ扱いになるため、厳密に今回フルコンしたかどうかは判別できません。
このため、もう一手間が必要になります。↓に続く。


◆既フルコン時のMAXCOMBO差分検出によるフルコン分岐
RBリザのlr2skinファイルにも書いてある通り、この方法を思い付くまでに2ヶ月掛かりましたが、
原理としてはフルコン済みの譜面でもう一度フルコンを出すとMAXCOMBOの差分値は必ず0になり、
フルコンを逃すと-1より小さくなる、という至って単純な理屈です。

op105を使ってフルコン済みの場合に専用の数字画像を読み込ませます。（上記とは別の画像）
この時のNUMBER定義はketa1align0で+側の0は念のため+-0時のみの表示にし
（+10や+20はそれぞれ+1、+2に）、
数字の「0」部分をフルコン用画像に、残りの数字全てを通常クリア用画像にします。
（実際にはNUMBER定義24分割時の+-0の表示は+0優先なのでketa/align未調整でも-0は空白で大丈夫）

既フルコン時のみの動作のため、MAXCOMBO差分値で+1以上の値が出ることは本来有り得ませんが、
EXTRAモード時は自己べのMAXCOMBOよりもトータルノーツが増えるため、
既フルコン譜面であってもコンボ数によっては+側の値が参照されてしまうので+側も作る必要があります。
このためEXTRAモード時の「今回フルコンボ」をリザルト側で検出する方法は多分存在しません。
（クリアマークは別枠で保存されますがDSTオプションでは検出出来ません）

ちょっと分かりにくいかもですが、OA DX+ LINKの心臓部です。
物自体は24分割NUMBER定義なんですが、表示させたいパーツサイズによってはかなりのサイズになります。
ちなみにPM Result見て気付きましたが、フルコン済みの場合のop105はプレイ・リザルトともにONになるため、
この方法で使う画像パーツはリザルト側で直接読み込ませても挙動は変わりません。（プレイスキンとの連携不要）
もうちょい早く気付いていればリンクON時に非対応スキン使っても問題無いように組めたんですが。

画像はRED_BELT/Result/Clear_Mark/FULLCOMBO2.PNG、
定義はRED_BELT/Result/result.lr2skin内を「//STAGE FULLCOMBO(初回用)」で検索。

その他

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

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

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


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


■DST定義とfps
おそらくXP環境限定のお話。
LR2スキンでは膨大な量のパーツを同時に表示すると出力fpsが落ちます。酷い時は半減くらいまでいきます。
DX+のタイトルエフェクトTYPE-6が代表的。（1.5秒間で10500個、その後1.5秒で10500個の画像が動きます）
タイトルエフェクトは動作終了後にop分岐とloop=-1で動作を完全に停止させていますが、
一度低下したfpsはそのスキンが動作している間は元には戻りません。
また、csvの行数的にはTYPE-3もほぼ同じ長さですがこちらはtime指定が複雑になっているだけで、
定義数は350個となっており大幅なfps低下は発生しませんでした。つまりcsvの行数とは無関係。
この結果から出力fpsは最大瞬間実動定義数に依存していることが分かります。

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

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のべき乗が望ましいと言われていますが、
これは主にプログラム上でのテクスチャの扱いに関係しているそうです。
これに加えてtga/ddsといった“テクスチャに使用するためのフォーマット”を使うことで
より軽量化できるのかもしれません。LR2デフォスキンが異様に軽いのはこの辺が絡んでいると予想しています。

また、うちのスキンでは汎用性を重視して画像ファイルはすべてpng形式の最高圧縮を使っていますが、
無圧縮tgaをdxa圧縮した方が僅かに描写が早く、fpsも3%程上がりました。
（dxa圧縮すると無圧縮tgaでも色数によってはpng形式とほぼ同じサイズまで落とせます）
SSD起動のようにファイルの読み込み速度が無視出来るほど速い環境であれば、
描写速度はほぼGPU依存なので悪くはないんですが、修正時にいちいちdxa展開するのも考え物。
基本的にはフォント画像でのみ使うのが無難かもしれません。
（選曲画面のフォルダ展開速度がほんのり速いかも？程度なので、むしろフォント以外で使う理由が無い）
tgaとddsでの違いは全然分かりませんでしたが、VRAM使用量はバイト数単位でpng形式時と同じだったので、
画像フォーマットを変えてもどのみちLR2の異常終了は防げないだろうと考えています。

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


■スキン定義の応用技まとめ
応用手法に共通して言えることは「dst_option.txtだけ読んでても作れない」という点。
.REDもフルセット組むまではdst_option以外のテキスト碌に読んでませんでしたが、
やはり一歩突っ込んだ機能を組むためにはとりあえず全スキン関連ドキュメントを熟読し、
LR2の機能や仕様を把握した上で、更に「目的の動作を"LR2上で"実現するための閃き」が必要なんだと思います。
以前も書いた気がしますが
「現行のLR2スキンに存在しない機能」と「LR2で実現出来ない機能」は必ずしもイコールではありません。

個人的にはデザインや機能をひっくるめて、どんな形であれ「未だかつて見たことが無い」という要素こそが
スキンにとって一番大事な機能だと思っていますが、
LR2スキン製作に関しては仮に実装まで行けても重すぎて実用レベルに到達しなかったり、
実装しても本体側のバグで動作しなかったりと若干の運要素も絡むのである程度は覚悟しておきましょう。