堕天使の煉獄

相変わらずＰＧ三昧。

以前つくったゲーム用のライブラリをｃ++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での実装はいい感じな気がしてきた。

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

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