『RPGツクールMZ』のウィンドウ内容を調べてみた
前回の『『RPGツクールMZ』のウィンドウ枠を調べてみた』に引き続き『RPGツクールMZ』 Window 周りの処理を調べていこうと思います。
例によって『RPGツクールMZ』非公式JavaScriptリファレンスのページに適宜リンクしていきます。
_clientArea に関するコードを読もう
今回は文字とか画像とか表示する範囲、クライアントエリアを見ていこうと思います。
ざっとこんな構成ですね。
-
_clientAreaクライアントエリア-
_contentsSprite内容-
contents(_contentsSprite.bitmap)
-
-
_cursorSpriteコマンド選択カーソル-
_cursorSprite.children( Sprite × 9 ) カーソル枠を構成する9スライスのパーツ
-
-
_contentsBackSprite内容の背景-
contentsBack(_contentsBackSprite.bitmap)
-
-
_cursorSpriteは概ね前回調べた_frameSprite(ウィンドウ枠)と仕組みは同じで、9スライスしたパーツを並べて引き延ばすというやつです。
contentsBack(_contentsBackSprite) は選択肢やステータスなどの区切りになる背景で、ゲームのインタフェースの方向性によっては、結構邪魔くさい感じになるんだけど、ツクール本体機能でOFFにすることはできません。
contentsBack は区切りの範囲ごとに作られるのではなく、この一枚の中にウィンドウの区切り背景が全部描かれてます。
という感じで、残った部分は次の通り。
-
_clientAreaクライアントエリア-
_contentsSprite内容-
contents(_contentsSprite.bitmap)
-
-
今回は _clientArea を中心に見ていこうと思います。
レイアウト関連プロパティについて
_clientArea は Spriteクラス。
ウィンドウ端から paddingプロパティ分だけ離れた場所に _clientArea が配置されます。
padding の規定値は12なんですが、Window_Baseクラスで改めて初期化されています。
Window_Base.prototype.updatePadding = function() {
this.padding = $gameSystem.windowPadding();
};
なんだか[データベース]で設定した値が入ってきそうな雰囲気ですが、そんな設定項目はなく、結局また同じ固定の12が返ってくるだけで、なんとも腰砕けです。
[データベース]-[システム2]-[高度の設定]の項目スッカスカなんで、この辺も入れようとしたんだけど、なんらかの事情で入れられなかったものと思われます。
WebというかHTMLというかCSSの世界でも、margin や padding という用語が使われているので、「あーアレね」などと思ってしまいそうですが、アレではありません。
以下、CSSを知らない人には、そもそもどーでもいい情報が含まれます。
| CSSボックスモデル | RPGツクールMZのWindow | |
|---|---|---|
margin |
領域端から枠線まで | 領域端から背景まで |
border |
線の幅 | なし |
padding |
線から内容まで | 領域端から内容まで |
width |
内容の幅 | 全体の幅 |
height |
内容の高さ | 全体の高さ |
innerWidth |
windowの描画領域の幅 | 内容の幅 |
innerHeight |
windowの描画領域の高さ | 内容の高さ |
innerWidthはボックスモデルとは関係なく(ブラウザの)window全体の幅だったりして、同じ名前をしてるだけに、なんとも面倒臭い。
ツクールがCSSに合わせてやる義理はないんですが、同じ名前なのに微妙に意味が違うんで混乱しちゃいます。
そもそもブラウザの window ってオブジェクトと、Windowクラスが被ってるのからして「やめてくれー」って感じです。
とまれ、『RPGツクールMZ』の Windowクラスのプロパティと表示されるウィンドウの対応図です。
CSSの方について詳細はボックスモデル-MDNなどをご覧ください。
『RPGツクールMZ』がHTML上で動いているので「CSSでしょ、知ってるー」とか思ってると痛い目見ます。
というか現在絶賛痛い目見てます。
印刷業界とWeb業界で用語の意味が微妙に違ってるような感じでしょうか。
Web業界とツクール界隈も微妙に違っているのです。
さてともかく簡単に言えば、_clientArea に直接関係あるのは、padding,innerWidth, innerHeight であって、margin は気にしなくていいということです。
ちなみに矩形範囲がいっぺんに取れる innerRect という Rectangleクラスのプロパティもあります。
前回調べた通り、9スライスの角部分は24pxなので、padding の内側まで枠が描けて内容の部分と重なるんですよね。
画像の配置とは関係なく contents のサイズは取られているのです。
以前 padding が24ピクセルだと思ってた時期があったんですよね。
「おかしい…枠の幅が24なのに全体のサイズがどうしてもずれてしまう」みたいに。
画像サイズと別だったとは…盲点!
ウィンドウの配置は _updateClientArea() で行われてます。
そこで origin プロパティに合わせた位置変更など行われていますが、これは Window_Scrollable でしか使ってないみたい。
理解目標にしている Window_Message は Window_Scrollable を継承していないので、とりあえず気にしない。
さらに蛇足気味な情報だけど、innerWidth は _clientArea.width と同じ値が取れるんだけど、innerWidth は Window が直に持っているプロパティから計算して出されている値で、_clientArea.width を決めるのに使われる。
なので、実は
-
innerWidthはWindowが想定している大きさ。 -
_clientArea.widthは実際の大きさ。
という違いがあったりする。ほとんどの場合同じ値が返るんだけど、基本的には _ が付いてない innerWidth を使っていくのが無難かと思います。
表示関連処理について
_updateClientArea() では visible の制御もやってて、isOpen() と連動させてます。
this._clientArea.visible = this.isOpen();
要するに、ウィンドウが完全に開いていない場合は非表示にしているんですね。
開閉アニメーション中は表示しないことで、余計な処理を避けようということみたいです。
filtersプロパティには PIXI.filters.AlphaFilterデータが設定してあります。
リファレンスの英語を自動翻訳してちゃらっと読んだ感じでは、透明不透明を規定する簡単なフィルタとのことです。
またfilterAreaプロパティは _updateFilterArea()メソッドでクライアントエリア領域に合わせてます。
要は、クライアントエリアの領域外に描画されたやつは隠してねってことみたいで、これもWindow_Scrollable でないと関係して来なさそうです。
_contentsSprite のコードを読む
_clientArea に含まれて、contentsを持つのが_contentsSprite。名前の通り Spriteクラスです。
Window_Messageクラスのメッセージ表示部にとっては、_clientArea ではなく、この_contentsSprite が実質のクライアントエリアになります。表示位置も大きさもまったく一緒。
contentsOpacityプロパティが、_contentsSpriteの不透明度を設定するものです。
前回も書きましたが opacity の方では内容を表示する_contentsSprite に影響はありません。変なの。
contents のコードを読む
_contentsSprite に含まれる bitmap プロパティには Windowのプロパティとして contents が割り当てられています。
contents = _contentsSprite.bitmap ってことです。
それだけ頻繁に使われるということで、逆に言えば _ が付いてる _contentsSprite や _clientArea なんかは極力触らない方がいいと言えます。
contents はウィンドウの内容描画全般で使われるため、まじめに追っていくと大変なことになります。
Window_Baseにある文字表示・描画系のメソッドは全部 contents に対して行われます。
Scene_Message
かなりレイアウトについて分かってきました。
でもそもそも、どこで Window のサイズが決められているのかが謎ですね。
『RPGツクールMZ』では Window とその子孫クラスは、新規生成時(コンストラクタ)に Rectangleクラスのデータを渡すようになっています。
Rectangle は上でもちょっと出てきましたが、矩形範囲をいっぺんに指定できる {x:〇〇, y:〇〇, width:〇〇, height:〇〇} 的なオブジェクトです。
Window にこの Rectangle を渡して大きさ決めてるんですね。
だいたい Window を生成しているのは Scene_Baseの子孫クラスです。
現在の学習目標の Window_Message を生成するのは Scene_Messageクラスです。
まとめ
というところで、ちょうど時間となりましタァ♪
……ま、時間決めてるわけじゃないですけど。
この辺りを理解するには、文字表示のレイアウトに関する部分を調べないといけないんですが、ちょっとやそっとではまとめきれない雰囲気なので、今回はここまで!
Discussion