堕天使の煉獄

相変わらずぐんにょり中な最近。
一度転ぶとなかなか起き上がれないにょう。

そんなかんじで久しぶりに体重量ってみたら、６月から？　で-2ｋｇ。

４月からで約10ｋｇ減～。

まあ、あんま運動してないで、普通に食べる量減らしてるだけなので
ここ最近は一月で-1ｋｇ減ペースというのは、まあ妥当ばペースじゃないでしょうか。

あと５ｋｇは落としたいかな。

もうすぐ夏休み期間も終わるので、九月からは
深夜のウォーキングも始めたいところ。

（夏休み期間は珍走団が出没するのでうざいのです……嗚呼田舎だなぁｗ）

なんかここ数年、酷い風邪で寝込む事が増えたので（一月ぐらい寝込んでたりした……）
早めに体力＆抵抗力をつけないとな、という事もあるのですけどね。


そんな最中、なにげ最近また頻繁に更新される様になった
田中久仁彦さんのブログをみて。

そういえば学生時代の終わりぐらいあたり？
なんかは、学校の教材としてあったスケッチブックの余りに
がりがり落書きとかしてたなぁ。

なんてことを思い出したり。

久しぶりに初心に返ってそういう感じのもいいかな－とかおもったり。

なんかスケッチブックとか、学校のノートとかって
いかにも「落書き」って感じなんですよね。

あの感覚を随分とわすれて久しいよなぁ。

ってことで、スケッチブックでも買ってこようとか思った今日この頃。


んでもスケッチブックって
下敷きが欲しくなるんですよね。

そのままだと、もともと筆圧強めなのもあってか
前の絵の線の溝が次のページにも残っちゃったりするのでｗ

んまあ、そもそも、スケッチブックのような柔らかい紙質で
0.3mmのシャーペンでぐりぐり書いてりゃそうなるわな（ぉ

なにげに当時も、スケッチブックでは0.5mmのシャーペンに変えてた気もするし。

ほんとは芯もHBとかじゃなくて柔らかいＢとかのにした方が
ベターなんでしょうけども。

文房具まとめてある引き出しみたら、その頃に買ったＢの芯がまだ残ってるしｗ

とおもったら、百均で買ったっぽい？
0.5mmの2Ｂの芯（未開封）が出てきた。

……なんかコレ買ったときもなーんか
久しぶりにスケッチブックでも～とか考えてたような
気がするのをおもいだした……ｗｗ

そんときは結局スケッチブック自体買わなかったので
流れたっぽいですね。


んで、下敷きなのですが。

スケッチブックって微妙にサイズが大きいじゃないですか。
そんでもって紙が柔らかいので、紙のサイズより小さい下敷きだと
下敷きの縁で紙に折り目がついたり、そこをシャーペンで突き抜いたり
段差ができるのでそこがこすれて汚れがつきやすかったりと。

なかなかちょうどいいサイズの下敷きがないと困ったりするんですよね。

大昔に使ってたスケッチブックは
裏表紙が見開きサイズになってて
折りたたむことで下敷きになるっていうタイプだったのですが。
このタイプは、上記のような問題が起こらず、いい案配なのですけども。
ぐぐってみると、最近では１社だけ？　そういうタイプのスケッチブックが
現存するようです。

んでも、その以前につかったことのある奴もそうだったのですが
方眼のマス目が入った下敷きなんですよね。

なんか、それは要らないんだよなー。

と、あちらが立てば、こちらが立たずな感じだったりして。


あとは、スケッチブックはサイズがちょっと大きめなので
Ａ４のスキャナじゃ全部収まらなかったりとか、
写真もぁ。携帯のしかもってないし

と、なんか描いても、日記のネタにうｐするときに
紙面上の描く位置とかによっては面倒なことになりそうで。

んでもスケッチブックはあんま画面の構成とか考えずに
思うがままに書き殴るのが醍醐味なところもあるしなぁ。

とかなんとか、いろいろと万事がスムーズにいかないことばかりで
またぐんにょりしちゃいそう～（ぉ

ＰＧつづき。

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


失敗その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();

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



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

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

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

やっぱり頭の中だけで考えるもの限界～
ってことで、とりあえずＧＵＩ周りで作るべきクラスを
とりあえず羅列してみるテスト。


基本方針:
マウスオンリーでしか操作出来ないものは避けるべし。
ゲームパッドorキーボードでの操作が最低限可能なものとして考える。
なので、常にフォーカスのある単一のコントロールに対してのみ
操作を受け付ける形にするべき。


DxGui　　　　　// モーダルなＧＵＩとモードレスなＧＵＩを登録して実行＆描画
　　　　　　　// シーンクラスはこのクラスをメンバに持つ
　　　　　　　// モーダルなＧＵＩはスタック構造で最上部のコントロールのみ操作可能
　　　　　　// 例：ＲＰＧとかの戦闘シーンでのコマンド選択　ＡＤＶの選択肢　etc...
　　　　　　// モードレスなＧＵＩは描画専用で、操作に対するイベント処理は行わない
　　　　　　// 例：ＨＰ表示とか
　　　　　　// モードレスなＧＵＩはプライオリティを指定して登録する。

DxGuiResource　　　// GUIで使う共用リソースを保持

DxGuiObject　　　　// GUIのrect情報とイベント発行機能を持つ基本クラス
　　　　　　　　　// ここにない独自のコントロールもDxGuiObjectから派生させれば
　　　　　　　　　// DxGuiに登録可能になる

DxWindow　　　　　　　// ウィンドウ
DxRectWindow　　　　　// 画像を使わないウィンドウ　基本描画メソッドのみで描画
DxGraphWindow　　　　　// 単一画像使用 サイズ固定ウィンドウ
DxVariableGraphWindow　// 複数画像使用 サイズ可変ウィンドウ 枠画像と背景画像用意
　　　　　　　　　　　// クライアント領域（ウィンドウサイズ）と、
　　　　　　　　　　　// ドキュメント領域（ウィンドウ内の利用領域）を持つ
　　　　　　　　　　　// ドキュメント領域に、レイアウトやGuiObjectを登録して使う
　　　　　　　　　　　// 特殊なウィンドウ（タイトルバーのようなものを追加等）
　　　　　　　　　　　// は派生クラスで対応？

DxTabControl　　　　// タブ切り替え可能なコントロール

DxLayout　　　　　　// 登録したguiの表示位置をレイアウトする
DxHorizontalLayout
DxVerticalLayout
DxGridLayout

DxSpacer　　　　　　// レイアウト用の空白（何もしない）コントロール
DxHorizontalSpacer　// rect情報だけ持つ感じ？
DxVerticalSpacer

DxButtonGroup　　　// ボタングループ(メニュー選択や選択肢などでも使う)
DxButton　　　　　// ボタン
DxTextButton　　　// 文字のみのボタン
DxGraphButton　　　// 画像ボタン

DxTextEdit　　　　// KeyInputStringあたりのラッパ

DxLabel　　　　　// tstring + pos + fontHandle + color + DrawStringの複合クラス
DxText　　　　　// Labelにもっと複雑な表示機能　htmlタグ拡張　ハイパーリンク的なのとか追加したの
　　　　　　　　// LabelもTextも単一行のみ扱う。

DxLabelBox　　　// DxLabelの複数行版 あらかじめ行数を指定して利用
DxTextBox　　　　// DxTextの複数行版 禁則処理なども行う
　　　　　　　　// 行数指定を超えた分の文字は無視される？（未定）
　　　　　　　　// 行数指定無しは次のDxTextScrollAreaを使う

DxScrollArea　　　　// スクロール表示
DxGraphScrollArea　// 画像用
DxTextScrollArea　　// テキスト用

DxListView　　　　// リストビュー　DxScrollAreaとの違いは、行単位でボタンとして機能なところ？
DxTableView　　　// テーブルビュー

DxProgressBar　　// プログレスバー

DxSlider　　　　　// スライダ
DxHorizontalSlider
DxVerticalSlider


DxScrollBar　　　　　　// スクロールバー
DxHorizontalScrollBar　// 主に他のコントロールに複合的に利用されるコントロール
DxVerticalScrollBar




// ############　以下は棚上げ中もしくは使わないとおもわれ
TreeView　　　// たぶん使わない？　作るのも面倒くさそうなのでパスする方向でｗ

// 以下は操作がゲームパッドでは扱いづらそう。
// 操作がマウスオンリーになってしまうのは避けたい

RadioButton　　　// bool値で画像変わるだけのコントロールなかんじ？
CheckButton　　　// 使うような使わないような……

ComboBox　　　　// 実際のゲーム画面ではなくコンフィグ設定画面とかの特定画面の特定用途では
SpinBox　　　// マウスオンリーな操作でも許される気がするので
　　　　　　// あった方がいいかも？
　　　　　　// 特定用途では便利なコントロールではある。
　　　　　　// キーボードorゲームパッドでも、フォーカスを与えてから
　　　　　　// プルダウンメニュー表示など段階踏めば使えるかな。
　　　　　　// と言うことでとりあえず保留

Menu　　　　// コレも操作がゲームパッドでは扱いづらそう
　　　　　　// 画面の縦横比がまちまちな昨今ではフルスクリーンモードは使わないので
　　　　　　// どしてもメニュー使いたい場合は
　　　　　　// 普通にＯＳのＧＵＩ機能(DxLibから利用可能)を使った方がよさそう。


やっぱ書き出してみると整理しやすいな。
大まかに脳内でイメージしてたものが
ちゃんと形として見えてきたかも。

てかほとんど、QT createrのＧＵＩ作成画面の
埋め込みコントロール一覧をなぞって
取捨選択した感じなのだけどもｗ

それぞれのクラスの中身の設計は
だいたい出来てる感じなので

あとはひたすら組んでいくだけ。

とはいえ、実際に組んでみたら、
いろいろと問題も出てくるんでしょうけど。

まだまだその辺は、修行がたらんです。


昨日のＧＵＩのスタイル案は全面却下な方向で。
ＧＵＩリソース管理クラスに共用画像は全部持つことにして
ＧＵＩのスタイル（見た目）は派生クラスで分けて
がっつりハードコーディングな方向で。

やっぱ、スタイルを別にクラスとして外に持って
汎用的なスタイルを～ってのは無駄が多すぎるという結論に落ち着いたり。
スタイル自体も、よくよく考えてみれば
わりとコントロール毎の独自項目が多くて共通部分が少ない感じだし。


実際のコーディングで問題になりそうなのは
やっぱ入力装置にたいする反応の書き方でしょうか。
基本方針にもあるとおり、
マウスオンリーではない操作系にしたいので
（でも、マウスオンリーでも操作出来る形。
あくまでもユーザーに、ある単一のデバイスの利用を強要させない
というのが本来の目的。
ここの操作だけはマウスでしか出来ないよ。みたいなのがあると
そこだけゲームパッドから手をはなしてマウスに持ち替えなければならない。
みたいのを無くしたい）

コンフィグ画面のような場合、
複数のコントロールをならべていると
スタックでのフォーカス管理は無理があるような気もしている。
その場合はマウスオンリー操作モードのようなものを用意するべきかなぁ。
とか、その辺はまだ思案中。
リストでもって、「現在フォーカスを持っている」という
状態を示すメンバを持つってのは
毎回フォーカスを持っている物をチェックする必要があって
なんか無駄だし。

むうん。

すでにDxButton、DxButtonGroupなんかは
一度、昔のゲームＰＧ内で実装しているのですが
（んでも以前のはDxButtonのなかで
画像ボタンとテキストボタンをフラグで切り替えてて……
switch分岐とかがいぱーいな、スパゲティコードだったｗ）

そのころ組んでたときに思ってた問題点が
「入力デバイスの状態はシステム側で持っている感じにしないとだめだなー」
ていうのが、現在の入力関係クラスの設計にフィードバックされてる
感じになっていたりする。

ＧＵＩクラスから、
たとえば矢印キーの上下が押されているかをチェックとか
直接はできないので（キーコンフィグに対応できない）
（マウスは直接問い合わせても問題なしですが。
もともとシステム依存だし、キーコンフィグも必要がない
せいぜいあるとすれば、左右のボタンの位置を変えれるぐらい？）

そこでシステム側で仮想のコントローラを用意する。
その仮想コントローラは各入力デバイス内でキーコンフィグされた後の
入力情報を単一のインターフェースに落とし込むのが最大の目的で

そうすることでＧＵＩクラスから
システム側の機能である仮想コントローラに問い合わせることで
キーコンフィグ後の入力情報の問い合わせが出来ると言う感じ。

これをしないと、ＧＵＩ操作にはキーコンフィグされた操作が利用できない。
もしやろうとするとＧＵＩクラス内にキー入力の問い合わせのコードを
ハードコーディングで埋め込むことが出来ず、その部分は外から設定できる様に
しなければならなくなるため。

そんな感じで、その外部の設定を
入力クラスに最初から委託しているの前提な設計、
という感じになっている。

で、もう入力関係クラスはすでに実装済みなので
あとは実際の運用で上手く動くかなーといったところ。


しかしＭＭＯみたいな画面をかんがえると
コントロールに直接ショートカットキーを与えるみたいな機能も
必要か。

仮想コントローラの入力チェックできるボタン数は固定なので
その数を超えるような大量のショートカットは
直接キーボード入力の入力情報をチェックする必要があるだろうし。

んまあその場合は、そのゲーム特有の拡張ってことで
ショートカットキーのキーコンフィグなんかは
自前で組んで、ライブラリでサポートする部分ではないかな。

んーその場合は、
「ショートカットキーを登録出来る」
「マウスのクリック監視」
「フォーカスを持たない」
という機能を持つ個別のＧＵＩオブジェクトとして定義するべきかな。


むう。
いろんなケースを考え出すと、
やっぱ複数の入力デバイスに対するＧＵＩ操作のあたりは
ネックになりそうな予感……。

今日もにこにこＰＧ

ＤＸライブラリのラッパークラスでのＧＵＩ機能なんかを
ちまちまと。

ある程度の設計の見通しは立っていた物の
やっぱ実際に組み始めると、いろいろと問題が。

ゲーム内で利用するウィンドウ、たとえば

メッセージボックス
会話表示ウィンドウ
ステータス表示
ショップなどの買い物メニュー

ｅｔｃ

ゲームのジャンルにもよるのですが、いろいろとある。

そのウィンドウの設計について、ちと悩む。

ゲーム内で、これらのウィンドウって
だいたい同じスタイル（見た目）のものを使うのが普通ですよね。

たとえば、ＳＦＣ時代のＦＦとかだと、デフォでは青の背景に白枠。
ＦＦ８とかだと、灰色に周囲は影付き、見たいな。

んでもそれって基本的にリソースが限られている時代のもので
だいたいこういうウィンドウは

四隅の角の画像（実際は１つで、回転したりして使い回す。）
縦と横の枠画像。（最小単位（たとえば8ｐｘとか）を並べて枠線を表示する）
単色か、大きめの画像、もしくはラップラウンドな背景画像

だいたいこんな感じの画像を用意して
なるべく少ない画像リソースで
可変サイズのウィンドウなんかは作られてたりする。

んでも、ゲームの場合、ゲームのジャンルとかにもよるのだけど
どこでどの位置にどんなサイズでウィンドウが表示されているか
だいたい固定だったりする。

そんでもって、ＰＣゲームの場合は
可変サイズでもないなら、ウィンドウを一枚の画像で用意しちゃった方が
手っ取り早かったりする。
それほどテクスチャ用のビデオメモリ容量とか気にする必要も無いわけだし。
（初代ＰＳなんかはビデオは２Mbしか無かったりする）
可変サイズウィンドウ用と、サイズ固定用の二種類用意する感じで。


当初は、ウィンドウスタイルを定義するクラスを用意して
スタイルオブジェクトを生成し、そこで画像なんかのリソースもそこで持つ。
スタイルオブジェクトはstaticなスタイル管理クラス内にＩＤとセットでリストにもつ。

んで、ウィンドウクラスなどからスタイルＩＤを指定して参照する。

みたいなのを考えてたのですが

ウィンドウ以外、たとえばボタンクラスなんかも
このスタイル指定方式を利用し、
またスタイル内での画像リソースの選択方法も
外部スクリプト（スタイルシートっぽいの）を読みこんで～
スタイルファイルを切り替えれば別のスタイルのＧＵＩに簡単に切り替えられるとか
スタイルオブジェクトを複数リストでもって
ＩＤで切り替えることで、複数のスタイルのＧＵＩをいくつも表示出来る～
とかまで考えていた物の……。

別にＧＵＩアプリケーションを作るわけでもないのだし。

さらには、ゲームのＧＵＩって
複数のスタイルを使うことも稀なんじゃないかなー。

と思ったところで、無駄が多すぎるかな－と言う気もしてきてたりで。

汎用性を求めたところで
あとでコードのメンテが面倒になるだけだったり
汎用性は実行速度と引き替えっていう部分もあったりするので。
（継承のコストや条件分岐命令が必然的に増えるので）

もっとシンプルな設計にするべきかなぁ。

スタイルはゲーム全体で一種類の統一したものオンリー。
スタイルクラスには、すべてのＧＵＩオブジェクトで利用する
リソース全部を持つ
（ウィンドウ背景画像とかボタン用画像とか、スクロールバーの画像とか）

てのほうがシンプルだよなぁ。
とか。


スタイルをあらかじめ（ゲームループに入る前）先に生成しておき
各種ＧＵＩオブジェクトは生成時にスタイルＩＤを指定する感じ。
（実際はスタイルオブジェクトはスマポにはいってるので
そのコピーを受け渡す感じになる）

単発スタイルの場合はＧＵＩオブジェクトのコンストラクタに
スタイルオブジェクトを直接ぶち込む。
（その単発スタイルの寿命はＧＵＩオブジェクトと同じになる）

みたいな感じのがベターかな。
スタイルの切り替え機能とかあんま使わないとは思うけど。
（たとえばFFとかウィンドウの背景色などコンフィグで変えれるけど
利用している人は全体の何割ぐらいだろうか……）


んでも頭のなかでぼんやり考えてたのを
こうやって文字に書くと、いろいろと整理出来るものですね。

だんだん見えてきた気がするぽ。

田中久仁彦さんのブログみにいったらば。

近々でるらしい？
ゼノサーガのコスモスのフィギュアのパッケージイラストが。

ゼノサーガって、なんかコナミの元スクエア組からの乗っ取り工作とか
嫌がらせだとか、ものすごく内情がドロドロとして
1はまだマシ、以降、キャラデザ変更、

そして、「邪神モッコス」降臨。

とか、酷い感じなシリーズになって、がっかりな感じでしたね。

結局、1しかプレイしたこと無いです。
2，3をまとめて２Ｄの（ＰＳＰ版だったかＤＳだったか）
のとかいうのもやってみたけど

結局のところ、ゼノギアスには遠く及んでいなかった印象も。

ゼノギアスの雰囲気まねて作った
それっぽい用語ちりばめただけの中身スカスカって感じで
ゼノギアスはそれらの用語がうまく作中に意味ある形で溶け込んでいたのに
ゼノサーガはすべて上滑りな感じがして、なんか微妙な感じだったなぁ。

ゼノギアスのそういう部分が受けたので、またやろうとして
なんか失敗した模倣作みたいな感じの印象だったり。

しかし、田中久仁彦さんの画集で
ゼノギアス、ゼノサーガ関連の画数が驚くほど少なかったのはびっくり。
しかもほぼ全部見たことあるのばかりだし。
権利の関係なのかなんなのか、サイズも小さいし。


そんなかんじで、田中久仁彦さんのちゃんとしたコスモスの絵って
まだこれで２枚目とか３枚目とかなんじゃないかな……。

ゼノギアスと言えばリコｗ
ttp://livedoor.4.blogimg.jp/jin115/imgs/f/a/fa9d2f8b-s.jpg

画集にもその姿は確認されずｗ

画集「龍骨」は本棚に入るサイズじゃないので
確認のためだけにまた引っ張り出すのめんどうなのでアレなのですが
ゼノサーガの方も、ジギーの絵は無かったような。


なにげにブログに、そのコスモスの絵の制作過程がのっているのだけども
らくがきで、ほかのゼノサーガキャラが書かれてたりして。

公式絵はあんなに少ないのに
表に出てないらくがきの枚数は相当あったりするんだろうなぁ。
（らくがきふくめると寡作なのか多作なのかよくわからんｗ）

なにげにゼノギアスの頃とか、
スクウェア社内に、ほとんど毎回らくがき絵付きのＦＡＸが
届いていたみたいなことが設定資料集だかに書かれてたし。

そういうのあつめたらくがき画集とか出して欲しいなぁ。

氏のらくがき絵とかすごい好きなので。

鬱病なニートが、そろそろ何とかしないと……と
意を決して履歴書も書いてさあ、と言うところで

「がんばれよ」
「職安いけよ」

とか言われちゃったりして。

んで、なんか今行くと、
言われたから行ったみたいだし、

「ほら、やればできるじゃないか」
とか、俺が面倒見てやった空気とか出された日にゃ……

とか被害妄想膨らむだけでもう

むひぃぃぃぃ！！

と、お布団の中でエビぞったりでんぐりかえったりして
何もする気が起きなくなる。

そうだっ！　死のう！！

そんな気分な最近ｗ


なんかね。
タイミング的に自分で動き出そうとしてたところで
機先をつぶされちゃった感じでぐんにょり。

なにげに田中久仁彦さんのブログの更新も再開してて

おいらも落書きっぽいのから始めてみようかなーとか
思ってたところだったんですけどね。

昔は毎日、落書きとかしてたのになぁ（遠い目）


そんな感じで
島田荘司・著　「占星術殺人事件」読了。

そのうち読もうリストの中にあった島田荘司。
森博嗣のS&Mシリーズも大分読み進んだので
ちょっとちがうのも間に挟んでみようかなということで
借りてみました。

ミステリーファンの間では
この御手洗潔シリーズの第一作目よりも
二作目の「斜め屋敷の犯罪」の方が評価が高いらしい。

実際、随分昔から「斜め屋敷の犯罪」っていうタイトルだけは
目にしたことあるし。

なにげに「占星術殺人事件」の巻末の書評？　で
当時（1981年頃）のミステリー研究会のようなところでの
今年のミステリー作品の順位付けみたいなので
１位をとったと紹介されていたのだけども
２位が笠井潔の「サマーアポカリプス」だったりして。

そうか、あのぐらいの時代の作品なのか。
とか。

森博嗣のS&Mシリーズも
あれも最初の方は同じ年代ぐらいでしょうか。

最近なんだか、古典と呼んでよいような物ばかり
手にしているような気がするぽ。

で、「占星術殺人事件」の方なのですが

探偵訳の御手洗と、助手的な石岡という主要登場人物が出てくるのですが
いまいち御手洗という人物の人物像がよくわからず
語り口が二人とも似ているため、
どっちがどっちの台詞をしゃべってるのか混乱するところが
ちょいちょいあったりとデビュー作だけあってか、
所々文章や表現が稚拙に感じる部分もあったりした物の。

核心のミステリー部分に関しては
久しぶりに気持ちよく、はっとさせられた感じで
面白かったです。

なんか最近書かれたミステリーって
いろいろとアイデアが出尽くされてしまったのか
読者を「騙そう」「欺いてやろう」という、悪意のような物が垣間見えて
なんだかすっきりと気持ちよく「騙された－！」って感じになる物が
全然ない気がしたりして。

その点、まだ正統派の古典的な物になると
小賢しさというか、小ずるさというか。
そういうのがなく、純粋な謎が楽しめる感じがして、
心地よいと感じるのかも知れないです。

ミステリーに求めるのは、
かっこよく言えば、「知的に騙されたい」わけで。
そうなるとまだ純粋だった頃？　の古典に走るのも致し方ない事なのでしょうか。


で、正直「占星術殺人事件」の前半部分は
上記のちょっと稚拙に感じる部分と、御手洗という探偵役の人物像が
全然よくわからず、このシリーズ微妙かなあ？
とか思ってたのですが、ラストまで読むと評価は全然変わった物になりました。

と言うわけで、御手洗潔シリーズも読み進めてみようかとおもったり。
ミステリー的には今作よりも評価の高いといわれている
「斜め屋敷の犯罪」がますます楽しみになったり。

んでも、巻末の記事で、
最近のミステリーなどで「あの○○を超えた！」とか
そういうあおり文句をつけると、過度に期待しすぎて
実際に読んでみると、もともと佳作なのに期待が大きすぎた分
過小評価されてしまう。

だから、人に勧めるときは

「犯人もわりとすんなり解ったし、まあまあおもしろかったよ」

みたいな感じで勧める。

とか書かれていてワラタｗ

なので、「斜め屋敷の犯罪」はあんまし期待しない様にして
読んでみようと思いますｗ


んでも最近ではむしろ、「○○を超えた」とか「○○よりすごい」
とか書かれてると、そうまで書かないと売れそうもない
よっぽどつまんない作品なんだろうなーとか思っちゃうのですが。

濫用の所為で、効果が逆転しちゃってる感じですね……。

相変わらずＰＧ三昧。

以前つくったゲーム用のライブラリをｃ++11で組み直しているのですが
その際に、わりといい加減に、とりあえず動けばいいや的な実装のところを
きちんと組み直してたりもするのですが

ちゃんときっちり組もうとおもうと、大変だなぁとか。

つい先日は、フレームレート周りの実装なんかを作り直してたり。

今までのは単純に60ｆｐｓ固定でウェイトかけてるだけだったのですが

割と最近では、安価なモニタや、モバイル系とか
省電力設計とかでリフレッシュレートが30hzの物も最近は多いとか。
んで３Ｄテレビ？　なんかは120hzが普通だとかで。

なので60ｈｚを想定して、60fps固定にしちゃうと
そういうモニタでプレイするとゲームスピードが変わってしまうわけで。

その辺の対応とかもちまちまと。

この辺の解法は大まかには二つあって
時間単位の移動量を算出して、フレームレートに依存しないゲームスピードにする方法と
描画をフレームスキップして調整する方法の二つ。

後者の方がゲームスピードをフレーム数で管理できるので楽ちんだったりするので
そちらを採用しました。

前者のは座標系の精度を上げる必要があるし
フレームレートが落ち込んだときに移動量がどっと加算されるので
あたり判定のすり抜け問題とかもあるし、いろいろと一筋縄ではいかなそうだったので。


あとは、エミュとかでは普通にある
ゲームスピードを変更（倍速とか）機能も欲しいよなーと。

世の中の市販ゲームは、なんでこんなもっさり動作なのかといらつく物が多い。
ミンサガとかミンサガとか、そうミンサガとか。(ｲｸｿﾞｰ)

もはやいまさらミンサガは実機ではプレイ出来ないレベルｗ

もともとアクションゲームとか興味ないかんじなので
ＲＰＧみたいなものつくったとして、
フィールドタイプなんかだと、移動時間を時には高速化したい。
とか思うことは多々あると思うし。

ＡＤＶなんかでは既読メッセージスキップとかあるんだから
歩行スピードもアップ機能あってもいいよね。みたいな感じで。

むしろゲームスピード自体あげちゃおうよ的な。

最近のＰＣなら、内容にもよるけど
ウェイト切ったら500fpsとか普通に出るしね。

んで試しに実装してみたら、微妙にずれるｗ

240fpsにしたら237fpsとか110fpsにしたら107fpsとかｗ

フレーム数は整数なので小数部の計算でどうしても
ズレが出てしまうので、なかなかきっちりと指定レートには
なってくれないのがちょっと気持ち悪いｗ

あと、やっぱフレームスキップ方式だと
1フレームに+1加算

++x;
DrawRect(x, 0, 100, 100, color);

みたいなのでテスト表示見てると
たまに動きがカクッとしてしまうのは仕様がないのだろうなぁ。
小数部の誤差がたまってそういう感じになるのだろうけど。

んがまあ、ゲームスピードを一時的に上げたり下げたりというのは
出来たので良しとするか。


で最近は、今回の組み直しの際に、新たに付け加えようと思っていた部分の
ＧＵＩ機能を追加しようと言うところで、ちまちま設計を。

だいたいの構想は以前から練ってはいたのだけども。
ここでもQT触った経験が生きてきてるぽ。

とりあえず、GUIパーツはすべてwidgetクラスを基底として
widgetには自身のrect情報とかもってて
あとは派生でウィンドウとかボタンとか作り込んでいく感じでしょうか。

そういう感じで描画周りは、さほど難しくも無い感じぽ。

問題は駆動方式。

誰がＧＵＩオブジェクトを保持して
たとえばボタンを押されたとして、その「押された」という情報は
どこの誰が受け取るのかとか。

イベントドリブンっぽい感じにしようと思うと
イベントを受け取る管理クラスがあって
ボタンにはＩＤが振られていて
「押された」というイベントをイベントクラスに登録する。
んで、ボタン押下後のアクションを起こすオブジェクトは
イベント保持クラスに毎フレーム指定のボタンＩＤのボタンは
「押されてる？」と問い合わせる感じでしょうか。

しかし、そういう感じのって、ＩＤＥのＧＵＩデザイナなんかある環境だと
ボタンを画面に追加した時点でＩＤが自動で振られるし
ボタンにイベント追加とかすると
イベントに対応したメンバ関数やらが勝手に登録されて～

みたく自動化されてるから良い物の
その辺を全部手書きで追加していくのは骨です。

ＲＰＧツクール見たく、ＧＵＩな開発環境そのものを作っちゃう様な場合は
別なんでしょうけど。


んでｃ++11の仕様なんか眺めてると
std::functionってつかえね？　とか思ったり。

メンバ関数を関数ポインタ（てか関数オブジェクトという方が正確？）
として簡単に扱える感じなので

ボタンクラスのボタンが押された時に実行するところで
std::functionで与えられたメンバ関数を実行するようなのができるっぽい。

Button button(&gameScene::buttonOn);

とか登録したらば
button.update();
でボタン押下のチェックを毎フレーム行って

ボタン押されたらそのまま
gameSceneクラスのbuttonOnメソッドが実行される、みたいな。

なにげにこの仕組みって、QTのシグナルとスロットのヒモ付けに近い感じぽですね

connect( &button, SIGNAL(buttonOn()), &gameScene, SLOT(buttonOn()));

こんな感じのイメージ。

って、あれ？
なにげにQTのドキュメントみたら5.3ではまた書き方かわったっぽい？

Button button;
connect( &button, &Button::buttonOn), &gameScene, &GameScenebuttonOn));

なんかこんな書き方が出来る様になったっぽい。
QTもstd::functionつかってるぽ？
より直接的な書き方が出来る用になった感じでわかりやすい。


ふむう、コレを見る感じＧＵＩのイベント処理まわり
std::functionでの実装はいい感じな気がしてきた。

まあ、実際に実装してみたらいろいろと問題が出てくるんでしょうけどもｗ

んでもまあ、大まかに妄想的に設計を練るのは楽しいですね。
実際の実装は肉体労働でしんどいですがｗ