3/26 ねこtwin
みみけっと３より８日経ちました。
みみけっと３の時点ではいささか中途半端な感のあったプログラムも、少しはマシになってきたという事で、ここにねこにっきtwin試作版、公開させていただきます。
fig.1 ねこtwin試作版、むしろ試作すぎ
nekotwin_pr4.lzh (3,919,241バイト)
木くらいは生やすとか言っておきながら、まだ生えてません(^^;) でも、四方２kmのムダに広いフィールドを歩き回れます。フライトシミュレータとかだったら２kmは一瞬で横切ってしまいますが、徒歩で行くとなると結構な距離です。このデモでは、グラフィックにはまだ反映されていないものの、ホウキに跨って飛んでいる状態を想定しているので、約20km/hでふわふわ飛ぶ、という設定にしています。スピード感もなんにも無いので多分にストレスフルな速度かもしれませんが、ホントにデフォルメ無しのサイズで3Dモデルの中を動き回れるというのはゲームに慣れている僕としては新鮮な気分がしたので、皆さんにも味わってもらいたいんです。 完成版では、ストレスを感じない事を優先して設定しますので、ご安心下さい。
みみけ３終了からは、高速化の方を重点的にやってました。そのおかけで、視界の広さのわりには、そんなに遅くないんじゃないかと思います。申し訳程度の実装になっている水面の描画にもランドスケープクラスを使っています。つまり、ランドスケープの描画を一フレームにつき２回やっていますが、十分実用的なフレームレートが出せていると思います。ちなみに、当方の環境(Athlon500 + 初代GeForce、32bppで表示)ではメッセージなどを表示していない状態で80〜100fpsです。現状だと８m四方のセルでハイトフィールドを構成し、４００m先までレンダリングしてます。尚、「主役」の丈は１mになってます。
今後のランドスケープ回りの予定としては、木を生やし、雲と川を流し、太陽を登らせる…と。フレームレートが悪化してきたら、LOD管理も…うぅ、泣ける。エディタも作らないと。 あまり立派なのはいらないから、とにかくラクして地形をこしらえられるようなのを、こう。
それから、開発中に出くわした不条理な現象とかについて。 …先に当方の環境について書くと、GeForce256搭載の3DBlasterGeForceを、Detnaor6.50で動かしています。OSはWindows2000です。
現状のランドスケープの表示においては、可視判定にQuadTreeを使っています。で、QuadTreeの終端ノードには8x8セル分の地形データがLVertexの配列として入っています。8x8個の四角形のレンダリングには256個の頂点が必要になるので、とりあえず256個のLVertexの配列を、地形データの読み込み時に作って、可視判定に通ったノードをレンダリングするのですが、何故か地形に大穴が空くことがあったのです(^^;) 穴のサイズはノード一個分のサイズと一致しており、穴は必ず同じ位置に空きました。
普通はLVertexを生成する部分がおかしいから、そういう事態に陥るんだろうと思うでしょうけど、実際にはLVertexの配列は妥当なものになっており、こりゃ一体なんでだろうと思ってノードをレンダリングする際のDrawIndexedPrimitiveメソッドの返り値をチェックすると、時々D3D_OK以外の返り値が返ってきてました。そのエラーコード、実に0x00000020…どんなエラーだよ、それは(^^;;)
で、256頂点じゃなくて16頂点ずつに分割してレンダリングすると、何故かD3D_OKがきちんと返って来て、描画も正しく行われるようになりました。 仕方がないので、現在では 「まず256頂点ずつ描かせて見て、DD_OK以外が返ったら16頂点ずつ分割してレンダリング」させてます。
…なんだかなぁ。
先日のみみけっと３終了後のぼとむらいんメンバーによる会合の席にて、holy氏とDirectX8でDirectDrawが廃棄されたことを酒の肴にしていたのですが、よくよく考えると、DirectDrawに相当する部分が完全になくなってしまったら、どうやってバックバッファとかを確保してたっけ…という部分がひっかかりました。IDirectDrawSurface8が弱体化したのは覚えているのですが、果たして具体的にどの程度弱体化したか、僕は明確に覚えていないのです。
GDIとの橋渡しがなくなってしまったので、X8は過渡的なバージョンに過ぎないんだろうと決め付けていたのですが、もうちょっと詳しく調べてみれば、何か手助けになるような物が掴める可能性があります。勿論、ここで探しているのはPixelShaderなどの派手派手な、売り文句に列記される類のモノではなく、以前から使っているような人間には涙モノ…というような、気の利いたメソッドです。
…というわけで、IDirect3DSurface8インターフェイスや、IDirect3DDevice8回りを重点的に、もう一度調べてみました。
ここでまず気が付いたのは、IDirect3DSurface8で使えるメソッドは、プライベートデータ回り等を除くと、Lockくらいしか無いという事です。つまり、Bltのようなメソッドが無い。代わりにに、IDirect3DDevice8に、CopyRectsメソッドがあります。 つまり、画面に直接影響を与えるような事は、IDirect3DDevice8を通じて行うようになっているようです。
このため、IDirect3DSurface8や、IDirect3DTexture8インターフェイスは、単なるメモリ置き場くらいの位置付けとなり、全体の見通しが非常に立てやすくなったと言えます。なぜなら、とりあえずIDirect3D8と、IDirect3DDevice8のリファレンスだけ読めばDirectGraphicsの全体像が把握できるからです。書き換わったクラスの継承図を見ると実に頷けますね。
で、前述の疑問である、バックバッファやプライマリサーフェスはどうやって確保されてたかというと、Direct3DDeviceを作ると、勝手に付いて来るようです。バックバッファへの参照をIDirect3DSurface8として得るメソッドもありますね。但し、プライマリ・サーフェスへの参照を得る事は出来ず、プライマリ・サーフェスの中身をARGB8888フォーマットに変換したものをシステムメモリに確保されたサーフェスとして生成してくれるメソッドはあります。…ゲーム画面のスナップショット用でしょうか(^^;)
また、IDirect3DDevice8.CopyRectsはどの程度使えるメソッドかという点について良く読んでみました。もし、使えるメソッドなのであれば、今までのBltの如くこき使えるかもしれないからです。さて、CopyRectsメソッドの特徴は…
- 拡大、カラー キー、アルファ ブレンド、フォーマット変換、および転送元または転送先矩形のいずれかのクリッピングをサポートしていない
はい、Bltと比較すると、全くといっていいほど使えませんm(__
大概のビデオカードでは、一辺のサイズは2の累乗にせねばならず、更に、正方形のテクスチャしか作れない事もあるので、例えば画面をちょうど一杯に埋めつくすサイズのテクスチャなどは作れません。これでは2Dのゲーム作る際に、背景の描画などに困るかもしれないですね。もっとも、背景をベタっと表示するだけなら、クリッピングもカラーキーイングも不要なので、CopyRetcsの使いどころなのかもしれません。 一応、IDirect3DDevice8.CreateRenderTargetメソッドによって、サーフェスを作る事は出来ますし、それにゲームの背景画像を確保しておく、と。あるいはフィードバックかます時に使えるかもしれません。
というわけで、CopyRectsはGameSDKの頃から格闘していた僕らの悲願の一つであった、BatchBltとは全く違うメソッドですし、AlphaBlend付きBltでも無いのです。ま、無いよりは100倍マシという事で。とほ〜
気を取り直して更にヘルプを読み進めてみると…おぉ
なんと、IndexBufferがあります。これは嬉しいですね。DirectX7にて、H/W T&L + VertexBufferコンボの威力は周知となったわけですが、困ったことにIndexBufferが無い。つまり、ビデオカードにIndexまで置いて、ビデオカードの中で処理を完結させるわけにはいかないので、DrawIndexedPrimitiveVBを使うと、頂点を山のようにビデオカードに置いてDrawPrimitiveVBを使うよりもかえってパフォーマンスの低下を招くケースも有ったのです。これはH/W T&L登場以前では考えられない事態でした。
また、PointSpritesも有ります。これは、従来におけるビルボードと同じ事をやってくれる仕組みのようですね。もう自前のビルボードエンジン使わずに、H/W T&Lの威力を使ってパーティクルお気楽極楽大作戦なわけです。やったぜ！ でもさ、ウチの環境で3DMark2001見ると、何がどうPointSpriteなのか分かんないんですが… まさか描画されてない？ 馬がグルグル回るだけに見えます。
…IndexBufferがホントに羨ましい(^^;)
文字の描画も遅そうだけど、一応程度にツールキットとして提供されてるし。
あとはD3DXか…はぁ。
なんだか、DirectX8の事を考えると、溜息しか出ないんですけど。こりゃ一体どうしたもんでしょうかね。
戻る