以前注文していた Windows API の本が届きました。基礎的な部分は再確認。ちょっと進んだ内容は新しく勉強することになりました。 Windows API はゲームプログラミングを目的とする場合は最低限の知識で問題ないと思いますので、最後まで読んでみて良かったら紹介させていただきます。

猫でもシリーズだったら買ってもらって損しないと思うのですが、もし OpenGL や DirectX を使われるような場合に Windows API を学ぶための専門書となると選ぶのが難しいですね（個人的には知識として知っとくってのも悪くないと思いますが）。

Objective-C を使うのか、…と最初はとまどったのですが、 OpenGL でゲームがつくれるというのがとても便利そうです。もし、仕事で iPhone アプリのゲーム開発案件が来ても絶望しなくて済むかもしれません（過去の経験上、こう思ってると来ないです）。

余談なのですが、新しい技術を学ぶ際、もやもやしている概念の一般名がわかると、一気に理解度が増すことがあります。自分も、ここ９年くらいずっともやもやしていた考え方があるのですが、一般的に「ステートマシン」と呼ばれているそうです。 Google で検索したら良い文献がたくさん出てきました。もっと早く知ってれば DirectX を勉強するのも楽だったなぁ…

「作曲入門」と銘打っても、読んでみると前提知識が必要なことが多く、文面から「～なのはご存知かと思いますが」といったニュアンスを感じてしまうことがあります。でも、本当に入門したいときは「ご存知」ではないことがほとんどかと思います。結果、 Amazon なんかでよく見る「入門できない」という評価になってしまうのかもしれません。

たとえばコード進行があります。それ以前の話なのですが、コードって思いつくだけで 100 個以上あるのです。本当の入門者は次のことがわかりません。

• 全部覚えないといけないのか？
• 暗記しないといけないのか？
• １曲中にどれだけ使わないといけないのか？
• 逆に１曲中にどれだけ使えるのか？
• どうやって使うのか？

しかしながら、だいたいケアされているのが最後のひとつだけという場合がほとんどでした（自分が読んできた本では、ですが）。この辺、面白いので興味ある方は勉強していただくと良いと思いますが、曲によってはコードを１つだけで構成することもできます。平坦な曲（さして感動もない簡単な曲というか…）で良ければ５つくらいで曲になります（その５つはキーによって変わりますが）。こういった雰囲気だけでもわかってないと読み進めにくいとあっては「入門できない」という判断になっても仕方ないのかもしれません。

今後求められるのは、こういう目に見えない不安をいくつ拾えるかなんですが、まだまだ先の長い戦いになりそうです。

唐突ですが、自分が普段思っている考えを文脈無視で述べさせていただきたいと思います。先日、作曲のレッスンにて、今後のレッスンの方向性について自分の希望を述べさせていただきましたところ、「あ、唐突ですね」と返ってまいりました。すみません、いつもこんな感じです。

考えというのはゲームプログラミングについてなのですが、自分は中身がしっかりしていれば外見はいい加減で良いと思っております（テキトーというニュアンスではなく、いわゆる「いい、加減」というやつです）。

Windows アプリケーション構築でたとえると、コアロジック部分をしっかり作れば GUI はウィザードやジェネレータが作ったもので OK みたいなところがあります。

ここで言う、「しっかりしている」とは、少なくとも現状で想定できる範囲で変更に耐えるという点です。せっかくアイデアや改められるポイントをいただいても、「あ、今の設計じゃ、それはできんわ」となってしまわないように気を遣っています。変更には SDK のバージョンアップなんかも含まれます。

現在は DirectX によるゲーム制作を考えております（というか M-Project 第一作に関しては決定しております）が、ここで変に「あとで OpenGL にも対応できるようにしよう」と考えると、私の実力では設計することができなくなります。それをやるには DirectX と OpenGL の両方に精通していることと、ゲーム開発の要件をかなり深く理解していることが求められます。

ですので、現在は「これ以降、 DirectX などの技術に依存する部分が多く出てくる」と判断した段階で、生のインタフェース（ IDirect3DDevice など）を取得して API による直接的なランタイム操作を考えています（ちょうど昨年、 yomogi さんにいただいたゲームエンジンがこうなっておりまして、リンクできるように考えました）。

「この考えが実際にうまく働くかな？」というのが今年かもしれません。

こんな Byerkut ですが、本年もよろしくお願い申し上げます。

DirectX9必携

目次を見た限りなんですが、プールとかロック、また、量子化といったサウンド関係の項目も見受けられ、速攻で注文してしまいました。コンセプトやページ数などの関係からかと思われますが、ついつい飛ばされがちな項目でしたので楽しみです。良かったら改めて紹介させていただこうと思います。

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

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

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

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

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

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

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

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

Windows で非同期読み込みというのをやったことが無く、どうやって実現するのか MSDN で探していたのですが、 CreateFile() にてファイルを開く際に FILE_FLAG_OVERLAPPED を指定し、続く API に OVERLAPPED 構造体のデータを作って渡すと、その API のファイル入出力が非同期になるそうです。

うそー、そんな簡単に。

もちろん、非同期読み込みならではの注意点をすべてケアしないといけなくなるわけですが、近いようなことは ActionScript でやってきたのでうまくいけばいいなぁ、と思います。ただ、描画に影響しないのかは実際にやってみないとわかりません。

当初の予定通り SQLite を使うようにすると非同期読み込みは簡単みたいです。 SELECT を投げたら、あとはループでぐるぐる回して、 if 文で「読み込み終わった？」というのを確認することができるとのこと。

ただ、どっちにしても DirectX なんかでテクスチャを生成するのに時間がかかったら意味ないかもしれません。ロード画面でアニメーションがカクッってなりそうです。

DirectXの真実 － ＠IT

ブログ、ウェブログに古い記事を載っけても良いじゃないか、その日を生きた印（ログ）なんだし、みたなムーブメントが起こっておりますので、ちょっと前に見つけた必読記事をば紹介という運びになりました。

これを使うとパソコン（というかビデオボードか）が DirectX の機能をどれだけサポートしているかわかります。「このパソコンでは２の乗数以外のサイズのテクスチャが作れるのだろうか？」なんて気になってしまうのですが、確認するためのサンプルプログラムをこさえるまでもなく写真のように結果がわかります。 My ThinkPad ではどうやらできるようです。

これは勉強の意味でも有用かと。