堕天使の煉獄

ＰＧつづき。

実際に組み始めるといろいろと失敗していたことに気づくｗ


失敗その1「形から入りすぎた」

unityを真似て、シーンクラス内では

updateとdrawメソッドとは別に
guiUpdateとguiDrawというのを
それぞれの前後に実行するのを基本動作としているのだけども。

順番的には

guiUpdate()
update()
draw()
guiDraw()

となっている。
最初にＧＵＩの処理（たとえば選択肢選択とか）を行い、
最後にＧＵＩを描画（必ずシーンの描画内容の上（最前面）に描画される）
というのが目的です。

んで、参考にしたunityの場合、ＧＵＩ描画用のメソッドでは
ＧＵＩ専用の描画命令しか使えません。

おそらくＧＵＩ関係のクラスのメンバとして継承されたメソッドなのでしょう。

が、DxLibでは、当然ながらそんな物ないので
drawとguiDrawのどっちにも全描画命令が書けるわけで。

はっきり言って、分けた理由は、シーン描画が終わった後に
その前面に描画されるという、描画順を分けるためだけにある様な物です。
（それはそれで意義はあるけど）

が、しかし、unityのイメージにとらわれてしまった所為か
なんか勝手にＧＵＩ用の物と、通常の物とを別けなきゃいけない、
と言うような思い込みを持ってしまったようで。

前回の日記の中の
DxLabel
というクラスは、tstringとpos(位置)とフォントハンドルと色（とエッジの色とか）
をまとめた、文字描画用のクラスなのですが。

じつはすでにDxStringという、全く同じ機能を持つクラスをすでに作っていたりします。
両者の違いは、GuiObjectから継承しているかどうかの違いぐらいです。

んで、先に述べたように、guiDrawの中では
別にGuiObjectしか描画出来ない訳ではなく、
普通にguiDrawの中ではDxStringも、それこそ普通にDrawGraphとかも
使えるわけです。

……分ける意味あったのかこれ？



失敗その２「節子、それ逆やっ」

今度はＱＴの真似をした部分。
半分は前述の、形から入っちゃって失敗した部分と重なるのですが、

たとえば画像一枚で画像サイズのサブウィンドウを表示するＧＵＩの場合。

DxGuiObject→DxWindow→DxGraphWindow

と多重継承で実現する設計だったのですが。

実際に使う場合には、たとえばダイアログボックスなんか作るときは
DxGraphWindow内にDxLayoutを持っているので
そこにDxGuiObjectであるDxButtonを登録して……
「はい」「いいえ」の二つのDxButtonGroupを使うべきですね。
DxButtonGroupを登録して。
するとDxLayoutによってDxGraphWindow内のドキュメント領域に
指定のLayout方法でボタンが配置されると。

みたいの考えてたのですが。

よくよく考えてみると、
ゲームのＧＵＩって、表示位置てだいたい固定なんですよね。
一度設定したら、位置が変わることなんてほとんど無い。

ＱＴなどの場合は、ウィンドウサイズも可変なので
ウィンドウ内に配置したオブジェクトの位置も
相対的に変化することが前提な訳です。

特殊な状況の場合でもなければ、
（例：ＲＰＧなんかでキャラの位置のそばに出る会話ウィンドウとか？）
動的にオブジェクトの位置やサイズを調整する必要なんて無いわけです。

さらに、やはり、多重継承のコストも気になるところ。
基本的に仮想関数の実行は高コストです。
メンバ関数も呼び出しコストがかかりますが、
仮想関数はおおよそ、その４倍程度のコストがかかるという計測結果もあります。

ゲームＰＧでは、
１フレーム内、60fpsなら約16ミリ秒内で処理を終了しなくてはなりません。

速度が最優先であるわけで、このコストは塵も積もれば……ということで
無視出来る物ではないです。

そして設計的に失敗だったのは
継承でなくて、コンポジットするべきだったなと。

オブジェクト指向な設計では割と良くあることなのですが
依存関係を逆にする方が良い、と気づくことが後からあったりするんですよね。

さらには、継承よりもコンポジットで実現した方が
実行コストも軽減されるとか。

上のDxGraphWindowを例にとると

DxGuiObjectには、

オブジェクトの位置とサイズ情報（rect）
それから有効かどうかのenableフラグ
update、drawなどの基本メソッドなど(virtual)
guiオブジェクトに共通するメンバを持っている。


DxWindowには
ウィンドウ関係のオブジェクトに共通する基本部分。
ウィンドウの内側の、クライアント領域のrectもしくはそのマージン設定
ウィンドウ内に登録されるGuiObjectを格納するコンテナ。

DxGraphWindowは、表示に使う画像だけ持つ。

と、DxGraphWindowは共通部分をそれぞれ継承しているわけです。

しかし、オブジェクトの位置とサイズ情報というのは
DxGuiObjectのメンバとして、DxRectというrect関係を扱うクラスを持っています。

位置やサイズの変更はsetRect()ではなく
rect().setRectで行われるわけです。

（↑DxGuiObjectにsetRect()メソッドを持たずに
DxRect& rect(){retuen m_rect;}
というメソッドをもっていて、変更の処理自体はDxRectオブジェクトに委託）

……DxGraphWindowにDxRectをコンポジットしたらええんとちゃうのんか？

ということになりますよね。

もっと言えば。

ダイアログボックスを作ると考えたとき

DxGraphWindowでウィンドウを描画
DxStringで文字を描画
（たとえば「ゲームを終了します。よろしいですか？」みたいなの）
DxButtonGroupでボタンを描画

という処理が必要になりますが
DxGraphWindowの中に
DxStringとDxButtonGroupを登録する方法って
スマートなのだろうか？　と。

普通に
DxGraphWindow.draw();
DxString.draw();
DxButtonGrou.draw();

とシーンクラスのguiDraw()メソッド内に書いちゃったほうが
表示順もわかりやすいし。
あとは
str.relativePos(window.pos());
とかやると、相対座標座標になるとかいうのあれば便利かな。

もしくはDialogクラスとか作って
メンバに
DxGraphWindow
DxString
DxButtonGrou

を持つとか。

つまるところ、トップダウンで設計したのが裏目に出た感じに。
ボトムアップ的な手法で
一番最少なＧＵＩ部品を作り

それらを部品としてコンポジットした
ＧＵＩオブジェクトを構築する……という方のが良かったようです。

最初からＱＴとかのお手本があったために
トップダウンでも問題ないと思ったのですけども、ドツボでしたｗ

そこで最初の話に戻るのですが
シーンクラス内のguiDraw()メソッドでは
単にシーンのdraw()の後に呼ばれる
というだけの物です。

たとえばguiDraw()内に

DxGraphWindow.draw();
DxString.draw();
DxButtonGrou.draw();

と描いた場合、guiDraw()メソッド自体が
ダイアログボックスとして機能しているといえます。

べつにＧＵＩアプリ作ってるわけでもないので
この位のシンプルさの方がよいのでは……という結論に。

あとはＧＵＩ部品の組み合わせで複雑な物も作ろうと思えば作れる訳ですし。
何より、継承による仮想関数のコストも掛からない。

やはり最初の方針は失敗だったなぁと。

ぎゃふん～。



失敗その３「やっぱ速くないとね」

最後は、ちょっとしたポカ。

ＧＵＩオブジェクトにDxBlendという
描画モードを扱うクラスを追加していたのですが。

コンストラクタは
DxBlend(Mode::Alpha, 128);
という感じで、描画モードとパラメータを設定する感じで。
各ＧＵＩオブジェクトのdrawメソッドの最初と最後に設定して

blend.setBlendMode();
str.draw();
blend.restoreBlendMode();

みたいな感じで、ＧＵＩオブジェクト毎にブレンドモードを設定出来るみたいな。

そこで。

……SetDrawBlendMode使うと、unityで言うところの
ドローコールが増えるというデメリットがあるの忘れてた……。

描画命令は一度に実行した方が速いのです。
DxLibも内部的に、タイミングや条件をもとに
draw命令をいくつか貯めておき、一括して描画することで高速化を図っています。

しかしSetDrawBlendModeは、
その貯めているのをそこで打ち切ってしまう効果があるのです。

なので
SetDrawBlendMode(DX_BLENDMODE_ALPHA, 128);
DrawRect(0,0,200,200,-1);
SetDrawBlendMode(DX_BLENDMODE_NOBLEND, 0);
SetDrawBlendMode(DX_BLENDMODE_ALPHA, 128);
DrawRect(0,0,200,200,-1);
SetDrawBlendMode(DX_BLENDMODE_NOBLEND, 0);
と書くよりも

SetDrawBlendMode(DX_BLENDMODE_ALPHA, 128);
DrawRect(0,0,200,200,-1);
DrawRect(0,0,200,200,-1);
SetDrawBlendMode(DX_BLENDMODE_NOBLEND, 0);

こう書いた方が速いというわけです。

なにげにunityでもＧＵＩの描画命令は
１ドローコール消費するコストが掛かるので低速。
と言うのがあるのですが、その理由はたぶんこの理由と同じ？

ＧＵＩオブジェクト毎に描画モード変更できるのは便利だけども
その分低速なのじゃなぁ……

さらに恐ろしいことに
DxLibの標準の描画系のラッパーで
ブレンド指定版とか作ってたりして（汗

全部無駄やんｗ

いや、使えないってことはないけど
あんまし濫用できる様なものではないし。

そもそもブレンドモードを変更する時
元に戻すのもあわせてSetDrawBlendModeで挟むのがなんかやだなぁ
と言うところがあったりするのですけども。

なにげにラムダ式でdrawメソッドを登録して～
みたいなのも作ったこともあったのですが……

汎用するにはラムダ式の書式はちょっと邪魔くさい……

毎度描画するたびに

blend([&](){ DrawRect(0,0,200,200,-1);}, DxBlend(Mode::Alpha, 128));

とか書くのもなぁ……と。
内部はテンプレート（とインライン？）で実装されるので
いっぱい使いまくった場合、ビルド時間伸びそうだしｗ

そんなこんなで、blend関係は
ここぞというところでしか使わない。
使うときはなるべくまとめて使う。

それなら普通に手書きでSetDrawBlendModeでええんでないの？

ということに。


んでもそういう観点からも
シーンクラスのguiDraw()メソッド内で

ＧＵＩパーツ毎に描画するというのは
たとえば半透明ウィンドウなダイアログボックスを考えたとき

void guiDraw(){
SetDrawBlendMode(DX_BLENDMODE_ALPHA, 128);
DxGraphWindow.draw();
SetDrawBlendMode(DX_BLENDMODE_NOBLEND, 0);

DxString.draw();
DxButtonGrou.draw();
}

と書ける方が
ある意味便利。

画面上に複数のサブウィンドウがあるときは
SetDrawBlendMode囲まれた部分にサブウィンドウのdraw()をまとめる
という事が出来るし。

これがダイアログボックスクラスとしてまとめられて
その中でblend設定を内包していると
そういうことが出来なくなってしまう。

ＧＵＩパーツはあんまし
ひとまとめにクラスでまとめるより
部品毎にguiDraw()に直接書いた方がよい。

というのが速度的にもベターな感じっぽい。

もしくは

dialog.drawWindow(DxBlend(Mode::Alpha, 128));
dialog.drawString();
dialog.drawButton();

とかいう感じで描画メソッドを細かく分けるとか？



といった感じで、描画速度のコストも考えると
いろいろとまた設計の見直しが必要っぽい。
普通のＧＵＩアプリと違って
フレーム単位で処理を終了させなければならない
ゲームＰＧとの差異の部分でいろいろと見誤ってた部分がいぱーい。

んでもまあ、最少単位の部品から作っていくというのは
今のところ既定路線になったので、とりあえずそっちを進めていこうかと。

これ、今月中に終わるかなぁ……。