⚔️

『RPGツクールMZ』のウィンドウ内容を調べてみた

6 min read

『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 を中心に見ていこうと思います。

レイアウト関連プロパティについて

_clientAreaSpriteクラス。

ウィンドウ端から paddingプロパティ分だけ離れた場所に _clientArea が配置されます。
paddeng の規定値は12なんですが、Window_Baseクラスで改めて初期化されています。

Window_Base.prototype.updatePadding = function() {
    this.padding = $gameSystem.windowPadding();
};

なんだか[データベース]で設定した値が入ってきそうな雰囲気ですが、そんな設定項目はなく、結局また同じ固定の12が帰ってくるだけで、なんとも腰砕けです。
[データベース]-[システム2]-[高度の設定]の項目スッカスカなんで、この辺も入れようとしたんだけど、なんらかの事情で入れられなかったものと思われます。

WebというかHTMLというかCSSの世界でも、marginpadding という用語が使われているので、「あーアレね」などと思ってしまいそうですが、アレではありません。

以下、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_MessageWindow_Scrollable を継承していないので、とりあえず気にしない。

さらに蛇足気味な情報だけど、innerWidth_clientArea.width と同じ値が取れるんだけど、innerWidthWindow が直に持っているプロパティから計算して出されている値で、_clientArea.width を決めるのに使われる。
なので、実は

  • innerWidthWindow が想定している大きさ。
  • _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クラスです。

まとめ

というところで、ちょうど時間となりましタァ♪
……ま、時間決めてるわけじゃないですけど。

この辺りを理解するには、文字表示のレイアウトに関する部分を調べないといけないんですが、ちょっとやそっとではまとめきれない雰囲気なので、今回はここまで!

次回: 『RPGツクールMZ』のウィンドウ文字表示を調べてみた

Discussion

ログインするとコメントできます