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

(2009/05/29)

このままだと先が見えないのでひとまず
現状報告代わりにSTGとFPSの2つ動画作ってしまう方向で作業中。
まずはSTGから取り掛かる。

早速問題発生。

今の実装だとマップを描画するのにライトマップをポリゴン一枚に付き一枚確保してるので
ポリゴン一枚一枚テクスチャ切り替えるという凄い無駄な事をしないと描画できないのだ。
XboxだとそうでもないらしいがPCだとテクスチャの切り替えが結構負荷が高いらしく激遅。
(自分の場合は更にオンボードなので余計)
マップ以外何も表示しなくても30fpsとか何の冗談だ。

動画を保存する負荷とあわせて20fpsとかなったら格好悪いなあ・・
なのでBSPというかPVSをきちんと整備して余計なマップは極力描画しないようにした。

と、ここまで読んで「あれ？FPSの4つ目の動画で既にやってんじゃないの？」と思った人も居るだろう。
でもそれはFPSの話でしたー
STGではやってなかっただけです。ああそれだけです、すいません。
ついでといっては何ですが、前より空間分割の効率が良くなるよう細工したし
ランダムマップではないモデリングツールで作ったマップを使う場合に
ある程度ポータルが生成される場所を指定できるよう改良した。

FPSもランダムマップオンリーじゃないので後々役に立つかと。

(2009/05/27)

キー入力部分を適当に作ってたのでキー割り当てが出来ないしジョイパッドも対応してない等
そろそろガタがきていたので
キー入力マネージャ、と言う程大層な物ではないがそれ関係のソースコードを全部書き直し。
そしたら今までキー入力判定していた他のソースも変えなきゃいけなくなってさあ大変
.....という事をしてました。

努力の甲斐あってか少なくとも今のところは
ジョイパッドのアナログ入力、キーボード、マウスすべて正常に動いている。
でも振動はまだやってないなあ。

今回調べて初めて知ったんだけどDirectInputにはコントローラを振動させるという機能は無いんですね。
フォースフィードバックという機能があるのみ。
フォースフィードバックとはレースゲームでハンドルを回そうとしたら逆向きに抵抗ががかるというアレです。
アレですって言ってるけど実際に対応コントローラを触ったことないし、店で見かけた記憶も無いので
出回ってるんだろうか？という印象が拭えませんがどうなんでしょう？
リアルといえばリアルだけど操作性も悪くなるし無理に力を加える訳だから故障も多そうだしなあ・・

で、このフォースフィードバック機能で右向きの力、左向きの力、右向きの・・・と非常に短い周期で交互に力を加えてやれば
振動が再現できますねと。調べたらそういう事っぽいです。
市販のPCジョイパッドで振動に対応してる物はフォースフィードバックの信号を
独自に解釈して内部のモーターを回す等して振動させているらしい。右向き抵抗＝右側のモーター回す　とかそんな感じで。

自分はPS2のコントローラをコンバータ介してPCにつなげてるけど、コントローラの調整ウィンドウから察するに
この製品が対応してる振動って強弱の2種類だけかなあ。
あとUSBの電圧の限界なのかPS2に繋げたときより振動がちょっと弱い気がする。

#追記

色々やってみた結果
左右のモータに送る電流に対してある時間におけるON/OFFの割合を変化させることで
強さのバリエーションを持った振動を起こせるようだ。
例えばOFFの時間を多くすれば弱くなるし逆も然りだ。
(そういえばこれってマザボのファンの制御設定とかで見かけるPWMという制御方法ではないか)

PS2の場合は左右のモーターで振動の特性が違うから研究すれば面白いかもね～というかゲームメーカーは当然してるんだろうね。
まあでも様々な振動を起こす事が現段階では重要ではないので
とりあえずそれがわかったという時点で一旦辞めておきたい。

だって、PCだからなあ・・・
パッドが変わればまた振動の強さとか調整しなきゃいかんだろうし
そもそもパッド持ってない人も居ると思うし。

(2009/05/25)

パーリンノイズ自体は実装したものの（しかも殆どサンプルのコピペだが）、まだやってない。
それとは別に調整が必要な変数値をリアルタイムにいじる機能の強化をしていた。
スクリーンショットに度々出てるウィンドウの事です。
現状ではアプリケーションを閉じると調整した値は保存されるけど、何の変数をどこに開いていたかが
すべて初期化されてしまうんですね。
理想的には終了時テキストファイルにどの変数をどの辺に開いていたのかを記録しておいて
次回起動時に復元できればいいなと。
という様な機能を付け加えてました。

そしてテキストファイルをメモ帳で開いて書き加えられれば便利なので
ウィンドウ位置は座標ずばりではなくて四隅のどの角に近かったかだけ記録。
実際のウィンドウの座標は重ならないように自動的に調整して配置する仕組みを作った。
で、これが手こずりまして。

左上に配置するとしても、同じ左上に関連付けされたウィンドウだけでなく
対岸の角のウィンドウ(左下とか右下とか)と重なっていないかとか判定しなきゃいけない、
コリジョン判定の必要があるんですね。
どうせ四隅だけだろ～簡単簡単。ウィンドウの横サイズは全部同じで高さが違うだけだし
とか甘く見て取り掛かったので大変でした。そんな事がありましたとさ。

次はジョイパッドの本格的な対応をするつもり。
とりあえずの目標はデジタル入力だけだが
できればアナログ入力と振動機能も入れたいな。

(2009/05/22)

煙の移動制御について、温度と空気の粒子密度が高いほど上に移動するようにしてるのだが
眠いときに組んだ部分だからか
本来なら空気の粒子密度テクスチャをセットする筈の所でなんとテクスチャをセットしてなかった！
私が一番びっくりですよ。
例えるならカップ焼きそばのお湯を注いで捨てる前にソースをかけてしまった位の衝撃。

それはともかくテクスチャをセットしてないのに読もうとするとどうなるか？
経験から言って大抵は砂嵐になるか以前セットしたテクスチャの断片（しかも所々上書きされてたり）が読み込まれる。
それでトップページのように「煙に見えなくも無い煙」が生成されていたのだから、現実は奇なりというか。

で、ちゃんとテクスチャをセットして描画したら今度は驚くほどノッペリした煙（というかもう白い水飴だ）
になるから頭を抱えてしまう。

だが待って欲しい（自分が）。出鱈目テクスチャを使ったらうまくいったのだから・・・
てことはパーリンノイズ・・とかランダムなテクスチャを設定しておけば
先日の「少しはそれっぽい煙」になるのか・・・・・？？

(2009/05/21)

引き続き煙と格闘中。
しかしなんだろう、ピクセルシェーダー2.0って分岐命令とループ命令が無いんだけど
if文を2重3重かませても上手いことcmp命令や飽和命令などを使ってコンパイルしてくれるHLSLコンパイラは凄いと思う。
流石にfor文は厳しいが・・

もちろんあまりにも複雑な分岐は処理しきれないんだろうけど
今まで文法エラー以外でコンパイル拒否された事は水面の処理を書いていた時の一回しかない。
（確かテクスチャ参照に使うUV座標の計算が複雑すぎるとか何とか怒られた）
条件付代入や飽和加算命令があれば使用命令スロット数は多くなろうが大抵のプログラムは記述できる・・・とか
誰か偉い人が論文を発表してそうだな

GPUのシェーダー言語は実行中に外部から変数を書き換えられる事を考慮しなくて良いのと
完全に内部で処理が完結（キー入力判定とか外部のメモリを読み書きしない）から出来る芸当なのかな？

(2009/05/20)

ずっと流体シミュやってる気がするが・・・今は煙をやろうかと試行錯誤。煙が終わったら次は炎を。
なんというか、煙に見えるようなパラメタの調整が難しいなあと。
ただまあシミュレータではなく純粋にゲームが作りたいので物理的に正しいかとかその辺は無視するつもり。

(2009/05/16)

なんか流体シミュがそれっぽく動くまで気になるから寝られないという、凄く下らん理由で徹夜してしまったので凄く眠い
でもまあ、一応動いたから良し。
ただ、本当にそれっぽく動いてるだけだ。
気体や液体をかき混ぜたら渦が出来ないと駄目だろう。現時点では出来てない。
それに染料を置いた部分から周囲に流れを発生させても染料が薄くならないのであたり一面真っ白になったりする。
これについては文献に解決策云々の記述が無いのだが・・・見落としたか？

あとはまあリアルタイムで使う訳じゃないのでそんなに気にしてない事だが
処理速度の問題。256x256のテクスチャで処理して30fpsなのだが思ったより動くと言うべきか、やっぱオンボード遅ぇと言うべきか・・・

(2009/05/12)

先日のGPU Gemsを更に読み進めて
2Dの流体シミュは大体実装は出来そうだ。
でも数式が一箇所だけ納得いかない（理解できてない）のでまだ実装には至ってない。
(HTML版は記号の誤記が数箇所と1つ画像が無い場所があるなあ・・)

3Dの流体シミュは素直に2Dから3Dに拡張するだけなので割とすぐ・・かな？
何が難しいかと言うと表示で、主にそれの為に文章の大半が費やされている。
現在のGPUでは3Dのテクスチャを立体的に表示する機能は無いので
現行のシェーダーを駆使し何とかして表示しましょうという話。

ところでゲームに使わないなら何故そんな事を勉強していると思われるだろうが
処理が重すぎて直接的には使わないが何らかの形でゲームに組み込む予定だ。

(2009/05/11)

進捗・・・はプログラムコード組んでないから一切無し！

だけど精神面のレベルアップはしたかもしれない
少なくとも英語の文献読んで速攻眠くなるという事はなくなってきた。
gpu gems以外の資料も読み始めている。
同じサイトの別のページのpdfとか。
もうちょっと時間掛かりそうだね。

話は変わってちょっと前にトーンマッピングの明るさ調節に遅延を持たせる実装をした。
要するに暗いところから明るいところをいきなり見たら目が慣れるまで時間が掛かるのを再現しましょうという話。
（ついでに複数フレームにわたって処理するから負荷軽減にも役に立って二度おいしいねと）
現状だと明るさが10フレーム遅れて線形に変化するからまだ機械的な感じがして違和感が。
場合によっては遅延ナシの方が良い。改良の余地あり。

(2009/05/09)

引き続き流体シミュのページを読むのに四苦八苦。
日本語で読んでも理解できるかな？って感じなのに英語だと、ねぇ。でも頑張るが。
ソースコードの部分読むとやってることはそんなに難しくは無かったりする。
関係ないけど「数式」って何であんな難しそうに見えるんだろう・・・

一つ問題が。今は煙のシミュレーションをやろうとしているのだけど
シミュレーション自体は出来るとして、煙の表示はページ読む限り
ビデオカード買わないと表示できません。
サンプルコードでは液体の表示にジオメトリシェーダなんぞ使ってるけど、煙の場合は・・最低でもShaderModel3.0じゃないと無理だと思った。

(2009/05/05)

後々GPUを駆使した流体シミュレーションなんぞをやりたいと思っているので
NVIDIAのサイトで勉強。
恐らく最新のGPUをもってしてもゲームに使うには重すぎるからFPSに使う予定は無いんだけど
ゲーム本体のプログラムが煮詰まってしまったので、気分転換のつもり。

思ったんだけど
英語がさして上手くない人が英語の文章を読むのは日本語の倍労力を使う。少なくとも自分はそうだ。
だけど将来の為という事で。
今日はそんな事を半日も頑張ってやっていたので（しかもあまり読めてない）まだ寝る時間でないのに眠くなって
妙な時間に寝てしまった。
そしてまた生活リズムが崩れるという。

(2009/05/04)

ソフトパーティクルやってみた。
やる事は単純で、描画する位置のZ値とスプライトのZ値が近いほど透明度を高くするだけ。そんだけ。

なのだが！

またしても初歩的なミスを犯してしまい時間食いまくった。
少しでも処理速度を稼ごうとしてマルチレンダリングターゲット(MRT)を活用しつつ組んだのが事の発端である。
MRTは複数の描画先（テクスチャ）に一度に描画する機能だ。
MRTには制限がある。

• α合成に対応してないハードウェアがある
• αテストはできない
• MRTのテクスチャはすべて同じサイズじゃないといけない
• 加えて同じビット深度(1ピクセルに使うビット数)でないといけない
• ステンシルテストもできない
• フォグは無し

とまあ、そんな感じなのは知っていた。でも今回のミスはそこではなくて。
ソフトパーティクルに使う比較用Z値を格納するテクスチャ形式としてD3DFMT_G16R16(Redに16bit,Greenに16bit)
というのを使って描画を試みても砂嵐になってしまうのだった。
なんでかねと思って色々変えて試したら、どうやらα合成を切るとうまく動く。
ちなみに自分が使ってるのはAMD690GというオンボードだけどMRTのα合成に対応しているのは確認済み。なんでやねん。

で、小2時間くらいまた試して悩んで結局はG16R16というテクスチャ形式自体がα合成に対応してないっていうしょ～もない原因だった。
多分使ってないチャンネルは1が入ってるものだという先入観だろうな～

結局メジャーな形式であるA8R8G8B8(Red,Green,Blue,Alpha各8bit)の各色成分に
本来24bitで記録されている深度値を分割して格納するというまあみんな知ってるよ的な方法で解決した。
最初からそうしろって？
分割して格納するのってちょっと重いじゃん、読み出すのもやっぱり重いじゃん。
ソフトパーティクルに使う深度値は16bitの精度あれば全然OKそうだからじゃあG16R16つかえばいいんじゃね？という甘い考え。

まあ最終的に動いたからいいか。

(2009/05/02)

おお、しまった。もう5月か。このゲームがいつ完成するんだか私にもわかりません。
まあそれはさておき。

影、水面をやったらHDRもやりたいなという事でトーンマッピングをしてみた。
トーンマッピングは暗いところや明るいところを見てると次第に目が慣れてきて地形や物の形状がわかるようになる、という処理。
明るさの調節とも言うかな。
次は極端に明るい箇所から光があふれ出ているように見せるブルームエフェクトをやる予定。
いや、その前に軽くソフトパーティクルやるかも。