Fallout 3 Character Simulator alpha release.
Download : http://hotstudio.net/serika/file/F3CS.zip
ということでやっと形になったかな。プロトタイプ版を一応公開。
Fallout 3 Character SimulatorはFallout 3のキャラクター作成シミュレーターです。
大幅に改造されていなければ、Vanilla以外のRe-Balancing Modも対応可能です。
副作用的にマルチランゲージ対応も可能です。
Construction Setと紛らわしいかもしれないので名称が変更される可能性があります。
バブルヘッドやら本やらクエストによる追加要素がないとあまり使いものにならなさそうですが、ひとまずちょっと休んでからで。
（追記）スキルの計算式がおかしいというか、元にした某所の計算式が間違ってるなあ。と、new gameで気がついた。
使い方を間違えてるシングルトンてたまらんな。不自然に粗造乱造されたシングルトンはかつてのグローバル変数と何ら変わりなく、オブジェクト同士の依存をガチガチに固めてしまうだけで、仕様の変更時に大崩壊を起こす。
おそらく最も簡単なデザパタの部類に入るので、デザパタ使っちゃってるわという気分になってしまいやすく、注意が必要だ。
とりあえず、今週の連休最終日をプロトタイプ版のリリース目標にしてみる。Perksが実に58もあるので良い感じに解決はしたい。
MVCとか試そうとしたらカオスになってる罠。
Windowsフォームアプリって色々細工してVとCを分離するよりも、多少重複部分が出てもそのまま使った方がマシな気がする。MSの意図してるのもそっちなんだろう。
wikipediaにもVとCが分離できないケースもあると書かれていたりするので、そんなもんなんだろうだけど...うーん。
一応できたが、ストリーミング再生はやはりスレッドが必要だったのでこの辺の細々とした面倒な処理がまだ。
どっちも断片的な情報ばかりでまとまったのが少ねえ...
Vorbisのデコード周りは断片でも単体でそれっぽい動きが確認できるのだが、ストリーミングはDirectSoundの初期化、プライマリバッファの作り方、waveformatexの作り方、セカンダリバッファの作り方、Notifyの扱い方、スレッドの作法、別スレッドでNotifyイベントの通知を受けてその処理の仕方なんぞが必要になってくるが、流石にDirectSoundとスレッドまで絡めて全部の説明は善意で書いてくださってる人でもめんどくさかろう。サウンドに限ったことではないので仕方ない。
なにより昔SDKにあったらしいStreamingDataサンプルとやらが既に無くなっていたのでオフィシャルなストリーミングが分からないというのが痛かった。代わりに用意されたDXUTでもストリーミング再生はあるのだが、用意されてるだけでサンプルで使われてない部分だし、酷いソースなので中を追いかけたくもない代物だし。
割と見かけた他のプレイヤーと同時再生した場合にnotifyイベントが混ざって音が飛ぶ現象は、結局ローカルメモリにつくれば解決っぽい？そういうフラグをとりあえず立ててみてるが、今のところ音飛びは起こってない。サウンドドライバが駄目な所為らしく、憶測と忌まわしい過去からの邪推になるがサウンドは最大手のカニとかC社とかあれだけのシェアでも糞みたいなドライバしか出してねえからハードは信用するなということですかね。
これでも問題が出るようなら整合性の対策とらないと駄目か。
で、ストリーミング再生を作って思ったのは、誰が書いても大体同じようなコードになるだろうなあと。DirectSoundでサポートしてくれりゃ無駄コードも変な問題もこっちで抱えなくて済むのだが、DirectSoundすら切り捨てられる御時世。まあでもめんどくせー言いながら書いて、きっちり動いたときの快感はプログラミングならではか。
C#だと速度無視でこれぐらいの小規模なツールの場合、数時間で作れて便利だ。
例えこの数時間がバッチ書く時間とか、手作業で１個ずつ作る時間のトータルよりも長かったとしても、楽なものを作った方が良いと思うのが性のような気がする。バッチはバッチでありかもしらんが、今回の場合は融通効かせるのが面倒だなあ。
しかしながら、ずっとC#だと緩く書けすぎてアホになりそうな気がしてくるのと、2005EE版だとIDEが各々独立しているのでC++との連携がやりにくいのが難ですね。
MSAAでMRTってできない？
どちらかというと今のところ問題はStretchRectに出ているのだが、BackBufferを使わないでMSAAのRenderTargetとテクスチャ＋非MSAARenderTarget→MSAAへレンダリング→StretchRectでコピーはうまくいった。
しかし、MRTにした途端StretchRectがS_OKを返しておきながら動作しておらず、StretchRectを一切しない意味のないコードと結果が同じになった。要するに未初期化のVRAMなテクスチャのままだ。DXのdebugランタイムもエラーでないし。
どっかでタコミスしてそうな気もするのだが、ざっと見た感じは問題なさそうなコードなのになあ。begin～endとRenderTarget切り替え&コピーのタイミングが重要なのかもしれないが調査中。
とりあえずwebを調べまわった感じではMSAA+MRTの資料がみあたらん。どれもBackBufferからとってくるか（単一しかありえない）、単一のRenderTargetだなあ。
追記：
http://msdn.microsoft.com/en-us/library/bb147221(VS.85).aspx
その割にはエラー出力がでないよなあ。
特定の状況で通常通りの動作を行うと整合性が変になってバグが生じるので、これを回避するような動作を入れたら、それをユーザにバグと言われるとか。
仕様に対して違う挙動だとか、仕様そのものの誤りによる本来のバグではなく、ユーザにとって思いもよらぬことが起こるとバグバグ言われるようになるとは大変ですのう。
texCUBEの前に用いるreflectないしはrefractにはワールド系での視線と法線が必要になるわけだが、これを使うためには頂点シェーダからワールド系に変換済みの頂点座標とカメラ位置と法線を持ってこないと駄目なわけです。（使った雰囲気で多分）
そうすると、頂点ごとにワールド系に変換する負荷を押さえるためにモデルにあわせて回転させておいたパーピクセルランバートとパーピクセルスペキュラのためのライト方向とカメラ位置が無駄になってしまうのだが、どうすればいいんだろうか。ちなみに、回転させたカメラ位置と未回転法線でreflectするとモデルのみの回転ですらキューブマップの参照先がカメラを動かしたようになってしまう。
現実的な順から解決策を書くと
になるんだろうけど、1は当然一番重いし、2は今時はそこら辺のマテリアルすら環境マッピングを用いることが多いので1とあまり変わらなさそうだし、3は適当に考えた感じだとreflectした後に回転させないと駄目で現実味が無いんだよなあ。
普通の環境マッピングなんて初歩的なので未だにワールド系使うサンプルしか見たこと無いし、どうしたもんかしら。
やっぱりライティングといえば3ポイントライティングですよねー。
ということで昨今リムライトの代用でフレネルがよく用いられますが、リムライトの色ってうまく計算から自動で出せないのかしら。
とりあえずその辺のゲームを見た感じでは、大抵凝ったことをしてるわけではなくて、まわりこみとして陰とか区別無く全部均質にキーカラーと同じ色使ってる場合が多い印象。
しかしながら陰部分にあたるカラーは手動で設定してやると輪郭の引き締まりが違っていてやはり良い感じになるなあ。キーカラーと反対の色を算出して補正すればそれっぽくはなりそうだが、彩度の低く効果的でない色になるケースも多くなるんだよなあ。やっぱ手動が一番かのう。
あとは他に光源追加しまくってると白く飛びそうな部分ではあるので、海外ゲーのように光源を多用したようなゲームだと色が混ざり合っちゃうので、そういう場合は前述のように単純にした方がいいのかも。個人制作だとデータの手間が増大するので光源たくさんおけませんがね。
割とメジャーな割にあまり資料が見つからない気がするLight-Scattering。ぶっちゃけ速度を考慮しないのならATIにあるCEDEC2002の資料の式をそのまんま実装するだけでいいので見かけないのでしょう。
しかしながらやはり、適度に簡略化された屋外照明散乱モデルとはいえパラメータの調整が非常に面倒くさいなあ。楕円型の散乱色とひょうたん型の散乱色の和を脳内で展開できるかっていう。しかも色を指定するのではなく散乱量というなんともプログラムには縁のない値で。
LSでなくとも太陽点で円形グラデーションだけでもそれなりに表現できるが、複数色混ざりあうグラデーションと太陽点から90度の方向の減衰が無いのでよく調整されたLSには劣るだろうなあ。
SSは天球＋適当な距離にオブジェクト複数並べるのが面倒だったので無し。適当にしか論文読んでないんだけど、天球ってin-scatteringだけを適用しないと良い感じにならないのって書いてるんだろうか。遠すぎるからout-scatteringの影響を受けないと考えればそうなりそうなんだけど。
さらに天球は遠いので（virtual sky domeがこれにあたるのかな）、それを考慮してスケーリングしてやらないと距離相応分の色がでませんね。
まあこれで太陽位置とその色が抽出できそうなので、Crysisで使われてる光芒表現も試してみたいなあ。
メジャーな割に良い資料がみつからんといえばLiSPSMもそうですね。みんな本家の"あの"コードを見て実装してるんだろうか。
