進捗状況(2011/12) - FPSを作ってみる@wiki

(2011/12/25)

進捗

Done

• テキスト描画に使用するフォントテクスチャのフォーマットをD3DFMT_A8R8G8B8からD3DFMT_A8へ変更
• 上記の変更に従い文字描画クラスの修正
• ユーザー情報テーブルのスイープ処理
• Poolプラント追加
• RadioBox, CheckBoxのバグ修正

（・GUI部品：スライダーの追加(not スクロールバー) <= まだ途中）
ざっとこんな所．

フォントテクスチャは暫定でA8R8G8B8にしていたものの，
実際はαチャンネルしか使ってなかったんで，だったらαだけのフォーマットがあるだろうと思い探したらやはりあった．
単純計算で4分の1のメモリ使用量となる．処理速度は殆ど変わらず．
ただR16G16やR16F(浮動小数点数フォーマット)等のフォーマットでは使用されないBlueやAlphaの数値は1.0固定だったのに対し
A8だと0になるようで，1.0を前提に組んでいたコードを手直しする必要があった．

もっと手の込んだ手法としてはフォントテクスチャとしてA4R4G4B4かA8R8G8B8をガッと確保し，
チャンネル毎に違うフォントを4枚分割り当てるなんてのも考えられなくはない．
そうすれば途中でテクスチャの切り替え無しに異なるフォントを一括描画可能だ．面倒だけど．

ユーザー情報テーブルのスイープというのは前に書いた通り，ユーザーの情報が詰まったJSONテーブルを一定の量だけとっておく処理である．
これについては説明の必要も無いかと思う．

RadioBoxとCheckBoxのバグについて．
LuaではJava等と同じくオブジェクトは参照渡しなのだが，ここで1つ疑問が生ずる．
すなわちオブジェクトの初期値や関数の引数をコピーすべきかどうか．(C++の場合は明示的なので問題ない)
何も考えず常にコピーするのも一考だが処理量が増える．かといって参照コピーでは後で引数を再利用する場合に問題である．
今までは「後でなんとか調整すればいいや」と放置していた訳で，早速ツケが回ってきた格好だ．
RadioBoxに初期値として渡す項目のテーブルを参照コピーとすると複数設置した場合にクリックしていない方のボックスが
反応してしまったりとか．

で，どうしたか．色々悩んだ挙げ句
引数をテーブル1つに纏めて渡す所で，メンバ名先頭に_(アンダーバー)を付けるとそのメンバ項目をコピーするようにした．
根本的な解決策ではないがとりあえずこれで行く．

思えば引数を再利用するケースはそんなに無さそうだし
引数の基本は参照コピー，必要に応じて呼び出し側が複製という形がよさそうか．

(2011/12/18)

xpressive

マニュアルを見る限りすぐにでも移行できそうだったのでboost::regexからboost::xpressiveにサクッと切り替え，
ついでにダイアログの正規表現処理をstatic regex版へ移行・・・
したのは良いが案の定コンパイル時間が目に見えて長くなった(3秒から20秒程度に）
コンパイル時に正規表現の解析をしてるから恐らく動作速度は有利なのだろう．
しかしダイアログリソースなんて頻繁にやるものではないからデメリットの方が大きい(そして戻すのも面倒くさい罠)．よって放置．

通常の正規表現より表現の幅が広いというのは，再帰的な構文解析ができるという意味だろうか．
計算式の解析をしたいという時には便利だろう．

ただ，これでわりかしstatic regex構文は覚えられたので
HTTPヘッダの解析を書き直せばそれなりの成果は得られると思う．
(JSONは正規表現使うまでもない)

さて．Twilveの方はというと．

• TwitterAPIを用いてツイートやその他諸処の情報を取得するクラスを「ソース」
• ツイートを流したり，溜めたりするクラスを「プラント」

と呼ぶ事にした
従ってTweetFlow(以後Flow)はプラントの一種である．
ちなみにFlowの他にもツイートが溜まり，ユーザーがクリックするまで消えないPoolというプラントも現在作成中である．主に自分への返信向け．

ソースを編集するウィンドウは前回のスクリーンショットのように，
使用するAPIを選んで付随するパラメタを入力するだけと非常に簡素な物．
パラメタは現状，検索キーワードのみに対応．

ソースを作成した後，まだGUIを用意してないが「プラント編集ウィンドウ」にてソースとの関連づけを行うと実際に
ツイートが流れてくる仕組み．重複も勿論可．
ソースには通常のPull型(こちらが要求する)とPush型(向こうから適時送られてくる)があり，
TwitterAPIにおいて前者は通常のAPI，後者はストリームAPIが該当する．
Push型はともかくPull型は何らかのタイミングでリクエストを送る必要がある．
とりあえず，Twitterには有名なAPI回数制限が存在するのでずっとコールし続けても引っかからない30秒間隔としておいた．
ソースが増えればもっと長くする等工夫が要るだろうが・・

これからの予定．

• GUI部品の細かいバグ修正

   リストボックスをクリックすると親ウィンドウのフォーカスが外れてしまう，Editの選択範囲の表示順位など．

• Poolの実装

   前述．

• Twitterユーザー情報のキャッシュ機構

   全部溜めるとあっという間にMB単位になってしまい，Luaで10MBも使うと全体的な動作が遅くなる．
   そこでLeast Recently UsedならぬLeast Recently Tweeted方式で使われない情報を捨てていく．

• GUI描画が何故か妙に重い問題の原因究明と修正

   D3D描画コール自体は1～2回だし，頂点バッファとインデックスバッファもこの前それぞれ1回に纏めたにも関わらず相変わらず重い．
   長文テキストなどそれなり頂点数が多いオブジェクトを同じ形式で描画するとパフォーマンスが出るのに何故GUIだけ？

やっぱりgifアイコンに対応すべきだろうか？使ってる人結構居るのがなんとも・・
ユーザーストリームのツイート以外の「誰々をふぁぼった」だの，「RTされた」のイベントはどのように通知したら面白いかなー等

挙げればきりがない

• 少しは見栄えのするデバッグ用コンソール <- 開発のテンションに影響する
• 簡易プロファイラの書き直し
• 右クリックメニュー
• ストリーム接続がエラーを吐いた時の対処
• ソースとプラント配置の保存，復元

(2011/12/15)

増えるリスト

Todoリストを1つ処理すると2つ増え，その中の1つを処理すると3つ増え・・

Done

• Editボックス内スクロール
• 上記に伴う選択範囲表示のクリップ
• GUI部品：スクロールバー
• GUI部品：リストボックス
• 簡単な当たり判定に一々C++を経由してた箇所を，判定ルーチンを一部Luaに移植する形での修正
• Windowsのダイアログリソースからレイアウトをインポートする機能
• プールメモリアロケータにrealloc的な機能を追加
• ユーザーポインタ使用のポリゴン描画周りの最適化（失敗）

ざっとこんな所．
もちろんメインディッシュはEditボックス内のスクロールでした．
表示領域をカバーできるサイズのバッファ（テクスチャ）を取り，そこに
昔のゲーム機のBG面のようにフォントを書き込んでいく・・・
ただゲーム機のタイルサイズは通常，固定であるがフォントの場合は幅が文字毎に違うので
バッファから一部はみ出る文字がどうしても出てくる．
考えるだけで面倒くささが伝わると思う．

スクロールバーとリストボックスはまぁ・・・昔に実装した事があったからそこそこという感じで．

次に躓いたのはダイアログリソースからインポートする機能．ダイアログリソース自体の説明は要らないと思う．
ウィンドウ出す毎に座標をポチポチセットしていたのでは（というか先週までそうだった）埒があかないから
ヴィジュアルなエディタで編集しましょうねという事で．
テキスト形式だからすんなり行くかと思ったら構文解析で手間取る．
いつものようにif文でガリガリやればそれなりの時間で終わったんだろうが
つい欲をだして「正規表現で解析してみようか」なんて調べ始めたのが運の尽き．

最初はLuaに備わってるstring.gmatch()でもいいかと試してみたけど，どうもしっくりこない．
これは自分が知らなかっただけなのだが，本来正規表現のマッチングは複雑な処理を伴う物であって
それをLuaにフルで乗せようとすると折角コンパクトなLuaの容量が膨らんでしまうとの事で
string.gmatchは簡易版のようだ．

この時点でLuaを諦めC++の，前から目を付けていたboost::regexを試すが
今まで「なんとなく」で正規表現を使っていたので構文の把握にこれまた手間取る．
（boost::spirit使った方がスマートに出来そうだ）
で，やっと出来たのが3日前くらいか．

今は・・相変わらずツイッタークライアントを作っているんだが
説がまた長そうなんでここで一端止めておく．