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

(2011/11/26)

途中結果

Done

• 行列，ベクトル演算クラスの修正
• Luaに平面(Plane)クラスを追加，C++関数との相互変換
• CatmullRom補間とそれを使用したポリライン実装 <= Tweetの軌跡表示に使用
• Editボックスの修正方法を検討
• 基本形状クラス同士の当たり判定，交点計算，めり込み深度計算関数を用意

　↑これにより簡単な判定なら全部Luaで完結させられる（線分と平面の交点を計算など）

予定に含まれてない物もあったりするが，毎度のことなので．
う～む，このペースじゃ11月中に予定が終わるか五分五分といった所か．
CatmullRom補間はいわゆる3次補間で，与えられた点列を滑らかに繋ぐ線を求めたりなんかに使う．
最初スプラインかと思ったがあちらは入力点列を必ず通過するとは限らない（というかまず通過しない）ので目的が違うかなと．
ポリラインはTweetの軌跡表示の他に「柱」作成時，マウスをドラッグした際やユーザーに関連Tweetを指し示したりと用途が広い（といいな！）

右上，右下，左下，左上，・・・・と順に通過点を増やしていくと図のようになる．両端に細工をして矢印のように見せる事もできる．
しかし曲面の分割数決定方法に問題があり，極端に向きが変わる箇所ではポリゴンがぐちゃぐちゃになる．
角度が急な所のみ動的に分割数を増やすべきだろう．

そしてTodoが1つ増える．
Todo

• ラジオボタン，チェックボックスの修正（古いクラスで，最近自前HUDの描画やアップデート仕様に変更があった為）

とりあえず上記1つとEditボックスのバグ取りが完了すれば「柱」作成の下地はできるかなと．

#追記1

ラジオボタンとチェックボックスの修正は完了した．
Editボックスはボックス内スクロールを実現するために根本的な仕組みを作り直す必要がありそうで，少し時間かかりそうだ

(2011/11/22)

クライアントの名前を決めた

「Twilve」読みは　ついるぶ，トゥイルブか？造語だからどうでもいいが．
特に深い意味はない．
私のアカウントを注意深く見ていた人は（居れば）気づいたかも．

相変わらず表に出ない改良が続く．ええと，何したっけかな？

• ふわふわ漂ってるツイートの球をクリックするとそのツイートにフォーカス．カメラが寄る．
• ツイートをフォーカスした時，横にユーザープロフィールアイコン表示
• 非同期でユーザー詳細情報とプロフィールアイコン取って来て，非同期で間に合わせのLoadingアイコンと差し替え
• Twitterサーバからの返信でもしユーザー詳細情報が含まれていたらテーブルに蓄える（が，何らかの条件で消していかないと消費メモリが増える一方）
• ツイートのビルボードを馬鹿正直に処理していたのではちょっと距離が離れると小さくなって読めなくなってしまうので，そのへんの細工
• ツイート投稿
• ストリームAPIにひとまず対応．だが切断処理とエラー処理をしてない．
• Luaにデリゲート的な物を実装．GUIのボタン押し下げ通知等に利用．
• C++で記述したTwitterAPI通信クラスとLuaのクラスとの連携を書き直し．要はリファクタリング．
• ビルボードを重ねるとZバッファ由来のちらつきが発生するので，カメラ位置に対し微妙に前後にずらす機能を付加
• 各所のメモリリークなどバグ修正

こんなとこか．1つ1つ説明する気力がない．
躓いたのは非同期でHTTP通信して画像を取得，更新するところ．
といっても非同期な点を除いて別段なんてことない訳だがクラス間の連携がうまくいかず
ああでもない，こうでもないとやっていた．

ユーザー詳細情報というのはプロフィール画像のURLはどこだとか，プロフィール文，フォロワ数なんかが詰まった物と考えてもらえれば．
TLをクエリする時にその都度一緒に送ってもらう事もできるし，パラメタを指定して省くこともできる．
普通に考えればまずはユーザーInfo無しでツイートを取ってきて，必要ならユーザーIDを通じて別途詳細を取得するのが通信量の観点からしてお得なのだが
知っての通りTwitterAPIには呼び出し回数制限というのがあってレートが確か一時間あたり150回，一分あたり2.5回まで
だったりするからちょっと使い込む人はあっという間にアウト．
従ってPCでは常に詳細アリで行く．一応どっちの方針でも処理できるようにはしたが．

で，今後はどうするかというと

• リプライの実装
• ツイートがリプライに対しての物だった場合，横に対象のツイートを並べて表示
• ツイートのパーティクル制御を座標変換含め全てLuaでやっていたら50個超えたあたりで重くなったのでC++化を検討
• GUIのEditボックスがたまにカーソル位置がバグるので，その修正
• ツイートの球に軌跡を追加
• HUDのウィンドウが増えるとマウスカーソル判定回数が異様に膨れ上がる問題の修正
• RPGの会話ウィンドウのような枠の各部をパーツに分けて描画する（なんて名前かわからない）ビルボードクラスを作成
• 行列演算クラスの修正．3x4行列 * 3x3行列の積算がうまくいってない等
• ユーザーが自由に「柱」を置く機能
• マウスのホイールでカメラの前進，後退，Alt押しながらでロール(！）

これら11月中の予定．完了できれば一応使えるツールにはなる筈．

カメラにロール？と思うかもしれないが
このプログラムはツイートが浮遊する上も下もない3D空間を自由に動くのがコンセプトとしてあって
ユーザーは前後左右の移動と軸にとらわれない方向転換ができるのでロールがあるのは自然かなと．実装もすぐだろうし．

そして「柱」・・まあなんのこっちゃといった感じだろうか．
自分ではTweetFlowと呼んでいるのだが，文字通りツイートが流れていく川のような「部品」である．
ユーザーが好きな場所に配置し，眺める．飽きたら消す．
ソースはホームTLやパブリックTL，検索結果にストリームAPIなどなんでもいいし
気が向けば混ぜてもOK．<=の予定

部品はこれ以外にも幾つか考えてはあるが，今はこれだけ．
たとえば自分に対する返信を表示するMentionsは流れていっちゃ困るからユーザーがチェックするまで留まるようなのとか．

(2011/11/07)

luaプログラムのドキュメント

今の所C++のプログラムはVisualC++のインテリセンスのお陰でとくにドキュメントを作らずとも把握できているのだが
luaはクラスや変数型といった概念がないせいもあってつい最近書いたプログラムでも
ええと引数の型は，順番は・・nilにしてもいいんだっけか？等といちいち確認する事態が多発している．
これでは開発どころじゃないのでやっとこさ，重い腰を上げluadocというドキュメント生成ツールを探して使ってみた．
予め決められたフォーマットでコメントを書いておけば
（画像が小さいけど）こんな風にHTML形式で出力される．

主にファイル最初の説明文，module定義文，あとはテーブルと関数しか認識されない必要最低限仕様のようだ．
クラスを出力できれば良かったが元々luaにクラスは無く
メタテーブルで細工して各自実装する物だから仕方ないかな？
にしても公式マニュアルが適当な気が・・

他には関数の引数，戻り値の説明文に型を記述する場所がないので
自分でフォーマットを決めて書いている．（luadocのソースを弄るのは面倒）
ちなみに説明文中に一部のHTMLタグが使えるようだ．試したのは改行と水平ラインとフォント関連．

(2011/11/05)

メモリ上のファイル

twitter投稿者のアイコンは無事に取得し，ひとまずファイルに保存できた．
ファイルに保存できたなら後は何も難しい事は無い．普段と同じように読み込めば終わりな筈だが・・
ここに来て「わざわざディスクに書き込むと無駄だし遅くないか？」そんな邪念が．
データを受信できたならメモリ上に置いてそこから読み込む．
専用のオブジェクトを用意するのも悪くはないが
折角だから普通のファイルと同じように読み書きできれば便利だなと．
（”折角だから”毎度毎度こいつのせいで進捗が遅い．少々うんざりである）

具体的にはこうした．
ソケット送受信マネージャの関数getFile()の引数にURLと保存先ファイル名を渡すとHTTPプロトコルでファイルをゲットし，保存してくれる．
この時ファイル名を"C:\ImageFile.png"等とすれば通常のファイルを意味する．
"@ImageFile.png"と，最初に@を入れればメモリ上に疑似ファイルとして保存してくれる仕様．
もちろん"@my_image/ImageFile.png"とやれば階層構造にもできる．

で，画像ファイルを外部からHTTPで取ってきてテクスチャとして読み込ませたいなら
TextureMgr.load("@ImageFile.png")　のように疑似ファイル名を指定すれば向こう側で
ディスク上のファイルか，メモリ上のファイルか区別する事無く処理が進められる寸法だ．

最初に書くべきだったかもしれないが
ファイル入出力関連はすべて抽象化してあり，従ってファイルを扱うクラスに特別な改変は要らない．
エンジンの初期化時にベースパス（保存先ディレクトリや読み込みディレクトリ）を指定して
ユーザーは全てその下の階層しか読み書き出来ないので間違えて重要なシステムファイルを消したりとかの心配もなし．
無駄に時間かかったしまだ実装が穴だらけとはいえ，作ってよかったと思っている．

(2011/11/02)

アイコン取得

そもそもHTTPヘッダを自前で処理するなんて選択をしたのが間違いだったような気がしなくもない．（単純だろうと甘く見ていた）
というのも，いちいち面倒くさい．画像取ってくるだけなのにHTTPヘッダの解析に手を加えBODYの読み込みにも細工をし・・
いや，HTTPの仕組みはよくわかるんだけども．
これC#やJavaやその他ネットワーク対応のスクリプト言語だったらget("url")とかで一発だよなぁ
逆に考えればTwitterに特化した速いHTTPヘッダ，JSON解析を書けるかも（携帯端末用）・・なんて野望も湧いて来たり．

それはそれとして．ツイートの発言者のアイコンを取ってくる処理を書いている．
URLを送られてくるデータを見るとどうやらPNGならPNGファイルの内容を直に送ってきているだけのようなのでこれを
一端ファイルに保存するかメモリに置くかして
テクスチャに読み込めば行けそうな感じだ．