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

(2011/04/30)#2

その２

チマチマと．

(2011/04/30)

リハビリング

はいはい．モデリングのリハビリ．

野暮ったく見えるけど実際には下のようになるんじゃないですか？多分．

(2011/04/27)

リソース構造

22日に記事を上げようとメモ帳に書いたところで放置してしまった．いつもの悪い癖．
以下は17～27日の状況と思ってほしい．

---

OAuth認証は面倒だなぁ，と嘆いていたらTwitterには簡易版のxAuthというのがあるようで．
でもまあOAuthで認証する所まで行けたしいいか．
後は気が向いた時にでも少しづつやっていくつもり．
数学もチマチマとベクトル，行列，座標変換と進み今はクォータニオンで苦戦中．
当然ながら四元数の名の通りまずは複素数から学ばないと入っていけないようだ．

そしてゲームの話．リソース管理について．
今まで同じリソースは1本の可変長配列で管理していた．
（例えばテクスチャならテクスチャ全体で1本，モデルならモデルでというように）
リソースにはハンドルという番号を割り当て，ユーザーはこれをマネージャに渡して実際のポインタを得るわけだ．
しかしこの構造はゲームで使う上で問題になる．

ぶっちゃけ図を入れるまでもないが・・一応説明しておくとこの図は
新しい要素を追加する時に空きが足りなければ新しく領域を一本確保して既存要素をコピーするという可変長配列の動作を示している．
アクセス自体はインデックス一発で高速なものの
誰かがリソースを使用していると勝手に拡張も出来なかった．
どんな時にマズいかと言えば

• あるテクスチャAを読み込み中にテクスチャBも必要だとわかった
• 続けてBも読みたいが，配列に空きが無いので拡張したい（新しく領域を確保して，そこへ既存の領域をコピー）
• しかしAは使用中なので勝手にメモリを移動できない = Bを読めない

といった具合．

もちろんこのケースではBの読み込みを遅延させる方法で回避可能だ．しかし根本的な解決とは言えないのも事実．例えば

• テクスチャAの関数内でモデルXの関数を呼ぶ
• モデルXの関数ではテクスチャBの情報が要る（Bはまだ読み込まれていない）

となればやはり破綻する．
悪い事に実際ゲームでは上の状況は日常茶飯事なのだ．
今までは騙し騙し小細工で乗り切ってきたがいい加減に抜本的な改善が必要である．

考えてみればそもそもリソースを一本の配列でメモリに置かなくてはならない理由など無いのだ．
（いや，出来るだけ1箇所に纏めたいが）
一先ず大まかなデータ構造で思い付くのは「配列（ベクタ）」「線形リスト」「ツリー」・・だろうか．
とりあえずアクセスの度に大量の分岐が入る線形リストは論外だし
ツリーにしても乱暴ではあるが似た様な物か．
だからといってリソースをハンドルを使わず生ポインタで管理するのも避けたい．というかそれではリソース管理の意味が無い．
でも根元の部分だけに速度はある程度欲しい・・・

結局インデックスアクセスだろう，配列1本が駄目なら2本以上だという考えに至った．
配列を拡張したいのにそれが使用中であったら新しく配列を確保してしまえという方向．

この図を見て「やっぱ目的のリソースがどの配列にあるか分岐が要るじゃない？」と思われそうだが
ある種の制限を加えれば計算で一意に求まる．それは

• 各配列サイズは2の累乗とする
• 新しく確保する配列のサイズはこれまでの全要素数に等しい

のような物．
2つ目の項目は何を言ってるのかというと{ [2] }の状態で新たに配列を確保する時のサイズは要素数=2, 新しい配列サイズも[2]であり，
{ [2],[2] } となる．更に追加すれば { [2],[2],[4] } になる．
まぁこんな小手先テクニック，大して高速化にならんだろうが・・

頃合を見計らって一本に纏める機能もつけた．車輪の再発明感がプンプンするがこれで先ほどの問題解決に至った．

臭うどころかこのようなデータ構造は既にあって，前にネットでそれらしい資料を見かけたのだが
当時は全く必要としていなかったため「フ～ン」と流してしまっていた．
適当に単語で検索しても一向にヒットしないので仕方なくそれっぽい実装をしてみたわけだ．
あちらの実装では各配列のサイズが可変だったかな？

(2011/04/16)

再び寄り道

ゲームの方は進んではいるが未だ光明がみえない．
キャラクターのアニメーションやマップとの当たり判定，場面（会話シーンや戦闘シーン）
を包括的に管理する仕組みというんだろうか？
いわばゲームの裏の部分をせこせこと作っている．
一回作り方を確立してしまえばスムーズに進むとは思うが・・
HLSLと違って結果が地味なだけにモチベーションが低下せざるを得ない．

そこで前々からやりたかったシリーズが再び発動（前回の入力ログは完了した）
今回のお題は「Twitterのクライアントを作りたい！」である．
ゲームとは全く関係ないが気晴らしという事でご容赦願いたい．
とはいえフツーなクライアント出来ました～なんてやっても誰も使ってくれないどころか自分も楽しくないし
正直言ってそんなのは作る意味がない．1つでもオリジナリティが要る．
作るというからには何か思いついたんだなと察して貰って結構だが詳細に関しては後ほど．
少し前にBasic認証は廃止されたのでOAuth認証が最初の壁か？（そのくらいは自分で書きたい）

で，更にそれとは別に最近は数学の勉強をしている・・といったら大げさだが
今まで3D描画の時になんとなく計算していた行列を，プログラム見直しのこの機にキッチリ押えておこうと．
（行列の各列が基底を表していて～くらいは分かるがクォータニオンはブラックボックス）
具体的には「ゲームプログラミングのための3Dグラフィックス数学」という本を中心に
ネットに散らばる資料を参照しつつたまにテレビでやっている放送大学の「線形代数」を録画してみたり
マイペースでやっている．
いつまでにコレをやるという目標は特に無い．必要だと思うからやっているだけの事なので．
というより基本的な座標計算を生涯ライブラリに頼るなんて格好悪いじゃないか．

(2011/04/12)

キーログ

既に3回ほどオブジェクト継承やステート実装について記事を書こうとメモ帳に下書きしてはみたものの
例によって文章がまとまらない．完成してないんだから当たり前か．

とは言ってもその部分が何時終わるのか見通しつかないので
気晴らしにとキー入力のログ取りと再現のルーチンを実装している．
レースゲームやタイムアタック要素のあるゲームで定番の，デモを撮る（動画ではない）機能だ．
今作っているゲームに必須ではないのだが「前からやってみたかったシリーズ」のうちの1つであった．
特定の状況でのみ起こるバグの原因究明にも使えるかと思われる．

動作はフレーム毎のキー入力をテキスト形式でファイルに書き出し，読み込んでキー入力を再現する・・・という
単純なものだ．説明の必要はないだろう．
もちろん毎フレーム分の状態をバカ正直に書き出したのではメモリとファイル容量の無駄遣いである為
キーの入力状態が変化した時だけ記録し
ファイルへの読み書きもfstreamを使用したストリーミング形式としてある．
キー入力再現の次にやりたい事といえばクイックセーブ&ロードであるがこれは難易度が高そうだ．