実は以前、コンピューターの技術で食っていくのをやめようかと思った時期がありまして、持っている本を売りに出してしまったのです。入手できなくならないうちに買いなおそうと思って Amazon に突入です。

この本は最初に読んだ時と、ある程度わかってから読んだ時で違う面を見せてくれるのでためになります。どれだけ勉強が進んでいるかのバロメーター的な存在。

レビューで、「ソースコードの割合が多い」との意見がありましたが、自分は全部本で確認できた方がありがたい気がします（自分が書く本はページ数の関係で無理そうですが…）。

テーマがテーマだけに 3D ゲームプログラミングとしての基礎（パイプライン模式図の１・２・６・７に相当する部分）はオライリー本の方が詳しく載っていますが、基礎がわかったら、次は DirectX といった具体的な技術の勉強をしなければなりません。その時に見る本がこれです。

前提となる知識が多い 3D ですが、だいぶ安心感が増してまいりました。こういった書籍のおかげですね。

実は簡素な表現（幼稚な表現というか…）のゲームが好きなので、自分で作るときは陰影すらつけないかもしれませんが、そういった場合でも十分活用できます。次に作るゲームは 2D ですが、 3D のパイプラインを使いますので復習目的で読んでおります。

テクセルからピクセルへの直接的なマッピング (Direct3D 9)
ラスター化ルール (Direct3D 9)

スクリーン座標を算出する際、各頂点のＸとＹ座標を -0.5 となるようにするときれいに出るということかとでしょうか。ただ、 DirectX 10 ではこの辺りの考慮が不要とのことで、なんとも嬉しいやら残念やら…

パフォーマンスの最適化 (Direct3D 9)

ただ、こういった情報は計算量が多い 3D のようなゲームを想定してのものかと思われます。１フレーム（ 1/30 くらい）中に描画するポリゴン数が 30 で 256×256 程度のテクスチャ数が５枚くらいだったら、必要になったタイミングでステートやテクスチャを切り替えて差し支えないかと思います（どうやら今のゲームがそれくらいになりそうで…）。

これを確かめるためにはページ中にある「アプリケーションのパフォーマンスを絶えずテストする」が重要だと考えているのですが、解説の途中に結論みたいなお話が出てきてちょっと面白く感じました。

一応、制作中のクラス設計に反映しております。

矩形転送というのは、それを一気にやることです。四角形で一括転送するので矩形転送という呼び方なんだと思います。

絵を表示することが目的なのに転送という表現がわかりづらいかもしれませんが、絵のデータを VRAM にコピーすることによって、そのデータを（ディスプレイなどの）ピクセルに反映するわけですので、やってることは転送なんだと思います。

DirectX でこれをやる IDirect3DDevice9::UpdateSurface() というメソッドがありまして、これを使うと「絵を画面に表示する」というゲームの基本的な機能を実現することができるのですが、どうやらアルファブレンディングができないようです（実際だめでした）。

面倒ですが、テクスチャで絵書いた方が良いかもしれません。

こういった場合、 D3DXCheckTextureRequirements() 関数を使うと、実際にテクスチャを作る前にその可否がわかります。

この関数は、「そのサイズは作れないけど、もっと大きくてビット深度の深いこのサイズなら作れる」という情報を返してくれる点が大変魅力的です。

そもそも D3DX を使うと、こういった問題を調整し、良い感じのテクスチャを提案して作ってくれるのが利点なのですが、時として「その提案はいらない」という場合があるかもしれません。こういう場合に、「じゃあ自分で調べるから教えろ」の答えになるのがこの関数です。

昔は、「そのサイズ、どうやっても作れないから、絵を縮小して作りました」というのがあったそうです。「だったら別の方法をとるから最初からできないって言えよ」と思う方にはおすすめできます。

ロックと聞くと、「排他する必要があるのか」と思ってしまうかと思います。これは間違いではなく、こっちが手を加えているうちは DirectX が勝手にテクスチャの配置アドレスを変えてしまわないように排他しなければならないのだと思います。

いつも文章が下手で何が言いたいのか伝わらず申し訳ないのですが、要は、一度取得したテクスチャやサーフェスの先頭アドレスを保持しておいて、「次からもここにアクセスすれば絵が描けるだろう」と思ってはいけないということです。

ロックによってピクセル情報を編集するためのアドレスがわかるというのは覚えておくと学習が楽になるかもしれません。もちろん、ドキュメントに書いてあるのですが、最初のうちは見落としてしまいやすいかと思います。

前に、テクスチャを扱う際の注意点を載せておいたのですが、画像ファイルなんかの読み込み先くらい自由にさせて欲しいと思っておりました。ただ、このテクスチャは描画することができないそうな…。ソフトウェアで処理するわけですので、描画コストがかかるのは覚悟の上でってことになりますが、手軽に 2D のゲームが作れたら嬉しかったかも。

ちなみに頂点をソフトウェアで処理するには D3DUSAGE_SOFTWAREPROCESSING 、自由なサイズのテクスチャを作りたいときは D3DPOOL_SCRATCH を指定して IDirect3DDevice9::CreateTexture() を呼び出します。なるほど、 SCRATCH か、そういう用途なのか。

この後、本物のテクスチャにコピーするなら普通のメモリに画像を読み込んでも同じですな。

ひとつ、今日知ったのが、「スプライトは座標を変化させるだけで移動できること」という要件です。たとえば、座様を変化させたときに、残像が残ったり、背景がくりぬかれてはいけないということのようです。

スプライトの実装には Direct3D にて板ポリゴンを使う予定ですので、今の設計だとうまくいきそうですが、スプライト愛好家の方の考えがちょっとわかったような気がしました。

最近よく、「一見、 2D のゲームでも 3D の技術で描いてるときがある」と説明するのですが、これのもっともわかりやすい実例がスーパーペーパーマリオです。実際に遊んだことある人はよくわかると思います。あのゲームはＡボタンで 2D と 3D が切り替わりますが、あの 2D は疑似で、本当は全て 3D で描いているのです。

3D は必要性がないと興味すらわかない分野かと思います。 Windows の場合、特に DirectX8 からの 3D 化が激しいですよね。最初から 2D のゲームしか作る予定のない人が「 2D を切り捨ててまで 3D に移行する必要あるか？」と疑問に感じられても無理のないことだと思います（ただ、 DirectDraw も COM なので切り捨てられたわけではないようです）。しかしながら、 3D で 2D を作ると楽なのも事実です。少なくとも DirectX ならクリッピングは不要、透過転送も不要、拡大縮小回転も用意されているので自作のコードは不要。…魅力的です。

これからゲームプログラミングを学ばれる方が好きな作り方を選択できるよう、実例はたくさん欲しいところです。もちろん、自分で作れれば一番良いのですが…