続3・ゲームのサンプル実装を作成中

というわけで、続行中。ステージ1の敵の攻撃パターンを作成している。ステージ1は「手毬歌」という感じで作っている。まあ、基本的なところはできたのでアレンジを・・・。毬っていうぐらいだから跳ね返らないとな。もう少し弾を減らして、画面枠で反射するようにしていこう。反射機能は実装済み。敵のライフを全部削ると次へ、というよくあるパターンはやめて敵と味方どちらも10発当てたら次へという設計にしようと思っている。正直、すでに自分で作っておきながらクリアできない(汗)。

続2・ゲームのサンプル実装を作成中

ストーリー部分の画面はこんな感じに・・・。文字送りとかの演出は未実装。

続・ゲームのサンプル実装を作成中

ステージ1のストーリーと基本的なプログラム部分が完成。ソースへの修正は今のところ大規模なものは発生していない。とりあえず、音楽と絵は後回し。音楽は、もうね、自動作曲機能で無理矢理作る。絵は過去に作った同人誌でがんばった限界を踏まえつつ、何とかでっち上げる。ゲームはステージごとにオープニングとエンディングとして、それぞれ一画面程度の物語が挿入される。サークルでずっと以前に議論した内容では、シューティングゲームとしてはテンポや集中力を損なうということで、物語が入るとかはアウトらしいのだが・・・。まあ、シューティングゲームに特別こだわりがない私としては、こういうのもいいかな、と。テーマは夏に向けてってことで、怪談だ。リリースは一ステージごとに製造を終えて、その都度行う予定。リプレイなどの必須機能も順次リリースを繰り返しながら実装していこうと思っている。General Public License version 3.0でソースコードは公開予定。今回こそはリリースするぞー。

ちなみに、キャラクターのベースは美樹とうらはのペアに出張ってもらう予定。

ゲームのサンプル実装を作成中

シューティングゲーム制作サークルの方で作成したシステムを流用し、実際に小粒なシューティングゲームを一本製造してみることにした。できるだけ絵や音楽まで実装することも視野に入れて製造中。この製造過程で判明するであろう改善点は随時修正し、本体ソースにフィードバックする。実際に作ってみないとわからないこともあるだろう。ゲームは全3ステージ構成。ボス戦オンリー。ワンプレイ五分、長くて十分程度を見込んでいる。現在の進捗率は、たぶん10%程度。普段はシューティングゲームで遊ばないので、慣れていない人でもクリアできるようなものになると思われる。湖畔の家は目標を見失いつつあるので、とりあえず凍結。

ソフトの設計や実装をする人が私以外にいたら、実装過程に出る問題について意見を出し合って改善できるのだが・・・。たまに思い出したように作業をする人と、今のところ全く成果を出せてないどころか本当に何か貢献する気があるのかすら怪しくなってきた人と、私だけではソースについての議論など無理。開発中に有用で再利用可能な部分のソースをライブラリとしてスピンオフすることも当初は考えていたのだが・・・。このところサークルからソースを切り離してSourceForge.JPにでも引っ越して・・・なんて考えていたりもした。今月末ぐらいを目処にソースの整理をしていたところ、MLに反応があったので切り捨ては延期になっていたりする。

湖畔の家の改造計画

湖畔の家に3D処理を追加するべく、いろいろと試しているがなかなかに難しい。Quaternion関連クラスは何とか使えるようになってきた。ベクトルや力学の勉強もそれなりに進んでいると思う。しかし、それらの知識を利用し、スキーとかスケボーとかそういう感じの動きを実現できるようなコードを作成しようと思っても、上手に実装できない。難しいものである。今まで物理現象やそれに似た処理を実装することを想定していなかったので、何となくとっかかりで躓いてしまっている感じだ。

湖畔の家、大幅改造計画中

以前から少しずつ作成していた湖畔の家という謎ゲームだが、もう少し謎展開を追加するべく、改造に着手。ついに避けて通っていた3Dゲームへの道を歩むことにした。というわけで、3Dモデルの上にキャラクターを乗せるという一番の難関をクリアするべくテストコードを作成している。今回のテストコードは単にキャラクターをモデルの上に乗せるだけでなく、自由落下やジャンプなどその他3Dレースゲームっぽい物理法則の最低限それっぽく見える実装までを視野に入れてみることにした。ここ二週間ぐらい高校物理の力学を復習したので、何とか作れそうな気分になってきたのだ。例えば加速して斜面でジャンプして・・・とか、U字型の地形で宙返りとか・・・。もはや何のゲームが作りたいかわからなくなってきたけど、なんでもいいかな。湖畔の家は釣りゲームだから、釣り場探しとかをアクション性のある3Dフィールドでやってもいいのではないかというわけだ。釣り場に着いてから、今まで作ってたまま2Dの反射神経系ゲームになるってのもアレだが。まあ、気の向くまま進んでいく予定。湖畔の家に組み込む前のテストコードは満足のいくテストが完了したら公開。

部品によるゲームキャラクターの修飾

　さて、ゲーム制作サークル雅弾会だが、サーバ停止による開発環境の変化から、ようやく復帰。HamachiでVPNを構築し、Windowsのファイル共有機能を使ってネットワークドライブを作成し、Subversionと組み合わせてソースや資料のヴァージョン管理を行うようにした。結構使い勝手よく動いてくれているのではないだろうか。

　で、その間にもゲームのシステム面の開発は継続していた。我々が制作しているのは段幕シューティングなのだが、細かいソフトウェア部品を組み合わせ、複雑な動きを実現可能にする実装を行っている。デザインパターンのデコレータパターンを流用しているわけだが、部品の充実を図れば、楽しく遊べそうな感じになってきた。システム面はこのまま進めばなんとかなりそうな感じなのだが、ゲームのデザインが遅れている。

　今まではゲームのデザインにプログラムがあわせるというアプローチをとっていた。この場合、ゲームのデザインによってはプログラムの見直しやある特定の挙動のためだけに面倒なプログラムの作成が発生する。要件があって、それを満たすための仕様を作り、プログラミングをするというのは当たり前なのだが、今回の開発においてはプログラミングが常に先行している。そこで、現状のプログラムで実現可能なデザインを行ってもらって、プログラムの修正・作成作業を最低限に抑えようというアプローチを考えてみたのだ。そのための資料作成を行っているが、もし、このアプローチがうまくいけば開発速度が向上する・・・といいなぁ・・・。

　ゲームとしての演出面ではHLSLの調査を行ってもらっているが、こっちの作業者の応答がきわめて悪く、というか、無くなってしまっている。進捗がまったく把握できていない。どうなっているのだろうか。

　

イラストと音楽は相変わらず後回しだ。

LinuxとWindows分離完了

　さて、Windows側のソフト整備なども完了して、いよいよWindowsはゲームとゲーム開発、Photoshop、DTMだけの環境となった。Linux側も日常的な作業をすべて行える状態だ。CDやDVDも焼けるし、デュアルディスプレイもOK、WebもメールもメッセもIRCもOKだ。辞書ソフトもJava開発もオフィスアプリも録画したテレビも映画やアニメのDVDも見られる。DTMや画像編集もPhotoshopほどではないが、OK。できないのはDirectXゲームだけだ。無料で手に入れることができる仮想PCソフトがDirectXに対応してくれると非常に助かるのだが・・・。

　湖畔の家はXNAを捨てて、Javaで再実装することにした。試しにUMLモデリングツールで作ってみている。環境依存部分を切り出して作成し今後の方向転換に対して柔軟な対応が出きるように設計中。この辺をしっかりとデザインしておけば他の環境や言語に移植する作業が楽になる。

　ゲーム製作サークルの雅弾会は基盤となるサーバを失ったので、代替手段を実験中。実験が成功したら再びソースコードのヴァージョン管理とWikiが使えるようになるだろう。

　ディスクの割り振りはgpartedで調整しながら色々と試した結果、全体が100GBのHDDをWindowsに65GB(残30GB)、Linuxのシステム領域に12GB(残8GB)、Linuxのユーザデータに20GB(残6GB)、Linuxのスワップに2GBに切り分けることになった(全部、おおよその値)。フルボイスのギャルゲー/エロゲー用にWindowsの空き領域を多めに確保。Linuxのユーザデータ領域が不足した場合は、gpartedでパーティションを切り直してLinuxのシステム領域から充当する。

　来週頭ぐらいからマビノギに復帰できそうだ。でもWindows起動したくないなぁ・・・。

自作ゲームは迷走中・・・

　さて、自作ゲームである湖畔の家だが、動作プラットフォームで迷走中。現在はXNA Game Studio 2.0で作成している。XNAゲームなので、動作環境はWindowsとXbox 360となる。Xbox 360は所有していないので動作確認はできない。よって、結局のところはWindowsのみで動作するゲームということになる。

　で、先日から湖畔の家が配布先で動作してくれないという問題に苦しめられてようやく解決した。動作環境の準備に関しては配布先でXNAゲームを動かす方法・完全版で全部書いた。しかし、ランタイムが三つも必要というのは、単にゲームがやりたいだけなのに大げさすぎる。同じヴァージョンが入っているにも関わらずインストールしなければならないDirectXなんてのは終わっているとしかいいようがない。

　Windowsを古くから使っている人の中にはWindowsUpdateからの修正の適用やランタイムのインストールに拒絶反応を示す人もいる。Windowsが不安定で信頼性の低いOSだった時代に苦労した思い出がトラウマになっているのだ(今も不安定で信頼できないなんて事はとても言えない。昔は・・・それはそれはひどかったのだ。)。とまあ、ランタイムにまつわるあれこれは、開発者にとってもエンドユーザにとってもいいことが一つもない。

　XNAはそんなランタイムを三つも入れるのだ。敷居が高いなんて話ではない。実際にゲームをリリースした段階で動作しない環境が噴出するのは明らかだ。XNAゲームが配布先で動作しない問題はもうすぐ終点でも同じ内容で記事を書いている。あれから再検討してみたのだがやはりXNAはやめておいた方が無難かもしれない。きっちりとしたインストールマニュアルを用意すれば、まあ、何とかなりそうだけれど。

　で、再検討した結果、Adobe AIRとかどうだろう。情報のほとんどは英語圏のものだが、今後、国内でも普及しそうな気配はある。Flash同様にランタイムを一つ入れるだけでOK。さらにインストーラに関する問題も解決でき、WindowsとMacで動くバイナリが手に入り、おまけに開発言語的には私が慣れ親しんだJavaを拡張したものである。というわけで、お勉強。

配布先でXNAゲームを動かす方法・完全版

　旧ブログのサルベージ記事です。

　XNA Game Studio 2.0で作成したゲームは配布先に以下のランタイムを必要とする。。インストール順序は不問。

• Microsoft .NET Framework 2.0 Service Pack 1 (x86)
• DirectX End-User Runtime Web Installer - 日本語
• Microsoft XNA Framework Redistributable 2.0

　DirectX End-User Runtime Web Installer - 日本語は常に最新のDirectXランタイムをダウンロードしてインストールできる。XNA 2.0から.NetのランタイムはMicrosoft .NET Framework 2.0 Service Pack 1 (x86)が必須となっている。

　それでもXNAゲームが動作しない場合、 Program.csの該当箇所を以下のように修正し、動作しない原因を探る。

try
{

    using (GameMain game = new GameMain())
    {

        game.Run();

    }

}
catch (Exception e)
{

    System.IO.File.WriteAllText("error.log", e.ToString());

}

　このコードを挿入すると実行ファイルと同じ場所にerror.logという ファイルが作成され、動作しない原因となったExceptionのスタックトレースが記載される。この作業で原因がはっきりと特定できない場合、その環境はXNAゲームが動作しない環境となる。

湖畔の家・ベータ版 バグ情報

mixiの方でゆーじからバグ情報が入った。

まず、第一報。「エラーが出て立ち上がらない」との書き込みがあった。ランタイムの欠落だと思い、Microsoft .NET Framework Version 2.0 再頒布可能パッケージ (x86)とMicrosoft XNA Framework Redistributable 2.0のインストールを行ってくれるように提案。しかし、それらのインストール後に別のエラーが発生したという「 入れたら違うエラーが出てマイクロソフトにエラー送信する？見たいなのがでた・・・。」という書き込みが。ゆーじのPCはXPだったはずなので、ここで私は日本語フォルダ名が原因でSQLiteが誤動作しているのではないかと推測した。湖畔の家はXNAベースのゲームである。XNAはセーブデータを、XPではユーザの「マイドキュメント」 フォルダ以下、Vistaでは「ドキュメント」フォルダ以下に保存する。Vistaではエクスプローラからは日本語に見えるのだが、プログラムからは英語でDocumentsとして取得される。XPではそのまま日本語フォルダ名である。推測だけでは、原因はこれしか考えられなかった。
しかし、実機で調査していると原因はそうではないことが判明した。
私手持ちのXPマシンでもゆーじが遭遇したと思われる現象を再現できたのだが、開発キットを入れたとたん動作する状態になってしまった。ということは、この問題に関して、私の作ったプログラムが原因ではないということになる。詳しく調べてみたところ、どうやら、XNA 2.0ベースのゲームの動作には以下の三つが必要らしいことが判明。

• Microsoft .NET Framework Version 2.0 再頒布可能パッケージ (x86)
  
• DirectX End-User Runtimes (November 2007) - 日本語
  
• Microsoft XNA Framework Redistributable 2.0

前回の記事と変わっている点はDirectX End-User Runtimes (November 2007) - 日本語が追加されたことだ。ゆーじの環境で発生した問題は(推測だが)DirectXが最新ではなかったために発生したのではないか。開発キットのインストールで私のXPにDirectXの新しいファイルが導入された可能性は十分にある。これで動作しなかったら次はエラーログを回収する仕組みを組み込んだベータ版を提供するしかない・・・。ちょっと面倒なのでDirectXの更新で動いてくれたらいいなぁ・・・。
DirectXのインストーラは適当な場所を指定してそこにファイルを展開した後、DXSETUP.EXEを実行することでインストールを開始する。この辺もきわめて不親切。
ちなみにDriectXはWindowsUpdate経由やゲームのインストール時にインストールされるケースが大半である。が、同じDirectX 9.0cでも実はその内容が違っている。開発者の間では知られているのだが、DirectXの開発キットは二ヶ月に一度更新される。と、同時にDirectXの実行環境も同じペースで更新されている。しかし、この更新はWindowsUpdateから提供されていないのだ。これは非常に開発者泣かせである・・・。ManagedDirectX 1.1の時もまったく同じ問題に悩まされてきた。XNAになってランタイムをサクッと入れたら動作するようになってくれたものとばかり思っていたのだが、私はM$を未だに過大評価していたようだ。XNAが重要な企業戦略の一環であるならばXNAゲームを確実に動作させるためにM$はDirectXの更新をWindowsUpdateで提供するべきである。XNAが重要でないプロジェクトだというならば、C#からDirectXアプリを開発する確実な手段を開発者に提供するべきだ。わざわざXNAを選んでやっているのに、馬鹿にするな。

追加調査
XNA 2.0はどうやらC:WindowsSystem32d3dx9_31.dllがないと動作しない模様。

追加調査2, 3
三つのランタイムを入れていても、DirectXのd3dx9???.dllがそろっていても、XPだとまだ動かないらしい。 システムログを出力して調査する機能を追加したヴァージョンを公開。実行後、いつまでたっても起動してこなかったらエラーが出ている。その場合、実行ファイルと同じ場所にerror.logというファイルができるのでその中身を教えてほしい。

(危険物指定になったので公開停止)

HLSLの調査

かっこいいエフェクトを求めてシェーダーの調査を開始した。XNAなシェーダーには頂点シェーダーとピクセルシェーダーがある。前者は3Dモデルの頂点を操作する。後者はピクセル情報を操作する。これらを組み合わせ、3Dモデルに様々な演出を加えることができるようになっているわけだ。これがまた独特な世界で取っつきにくいこと甚だしい。HLSLを記入するエフェクトファイルだけではなく、C#のソース部分も併せて考えないとダメなのが困ったものなのだ。BasicEffectみたいにサクサク引数で渡してラクチン描画っていう風にはなっていない。謎だ。はっきり言って、スタートで立ちふさがる壁が厚いこと厚いこと・・・。幸いなことに今回は2Dゲームでの利用を想定したシェーダーの調査となっている。頂点シェーダーはあんまり掘り下げなくてもいいだろう。ということは、ピクセルシェーダーの調査に集中できることになる。ピクセルシェーダーは要は大学の研究室でおなじみの、二値化から始まる画像解析の世界とだいたい同じものである。現在の活動メンバーは全員情報工学科卒業者なのだから実習で基礎の基礎は経験済み。というわけで、シェーダーの調査はメンバーの渕上が対応してくれることになった。私はシェーダーのサンプルを作って後はお任せである。

結局ゲーム開発というのは

プログラムというものは何らかの入力に対する出力を返すものだ。
入力の種類はユーザのキー入力でも、何らかのプログラムの出力でも、センサーからの信号でもなんでもいい。出力の方法もまた多彩だが、実用的な目的を持ったプログラムでは、何の出力もないということはあり得ないのではないだろうか。
ゲーム開発を通じて思ったことだが、結局ゲーム開発というものも例外ではない。ゲームはユーザの入力に対し、画面の情報を更新するプログラムだ。ゲームだからといって特別なことは何もない。
Webアプリの開発では画面の完成予想の絵と他の画面との接続関係があって、それにぶら下がって左半分に入力元と入力内容、真ん中にその加工方法、左側に出力先と出力内容を記入した三列の仕様書をよく見かけた。ゲーム開発の仕様書というものを作るならばこのスタイルで問題ないと思う。同じように入出力を扱うプログラムを作るのだから、同じような仕様書で問題ないはずだ。
しかし、仕様書の作成というのは時間と手間がかかる。おまけに仕様書が完成して最後にならないと動くものができてこない。挙げ句の果てに、実際に作ってみると仕様書と食い違いがどんどん発生する。その修正に再び時間がとられることも大いにあり得る。
したがって、今回は厳密な設計というものをあまり気にせず、担当者同士が好き放題垂れ流した妄想に対しMLやblogですりあわせを行いつつ、ある程度妥当なところで落ち着いたらそれを仕様とするような緩い開発を行っていきたい。

XNA 2.0なゲームサンプル、リプレイデータ保存に対応

というわけで、XNA 2.0なシューティングゲームのサンプルコードがリプレイデータの保存に対応した。深刻なバグでもない限り、これで外部公開の更新は終わりだと思う。例によって、データファイルは暗号化され、普通のユーザが保存データをいじるようなことはできないと思う。もちろん、コードをバイナリから解析できるような人相手にはまったくの無力である。ダウンロードは以下のエントリから。
http://khnum.no-ip.org/blog/2007/12/12/1145/

XNA2.0ストレージ関連実装完了

というわけで、XNA 2.0でストレージ関連の処理を実装完了。ファイルは暗号化されて扱われるようにしておいた。ソースは以下のアドレスからダウンロード可能。
http://khnum.no-ip.org/blog/2007/12/12/1145/

XNA2.0のストレージ周り実装中・・・

先日公開したXNA 2.0で作成されたシューティングゲームのサンプル実装ソースでファイル操作周りの処理が抜けていた。本体の開発でも必要になってくるから、現在実装中。1.0の時とStorageDeviceの取得方法が違っているようだ。

XNA 2.0が出たので・・・

先日公開したシューティングゲームのひな形をXNA 2.0の正式版でコンパイルしてみた。結果は問題なく動作。ウム。

XNA Game Studio 2.0

XNA Game Studio 2.0が正式リリース。うむうむ。

あれれれれ?

作成中のゲーム、公開したときのソースをもう少し洗練させて、2Dゲーム部分は完全に一段落。次は3Dグラフィックス対応を行おうとそれ用のクラスを追加した。が、なぜか動かない。あれれれれ?なんか勘違いしてるのかな・・・。
原因判明。カメラが明後日の方向向いてました。

GameComponentを使った実装

さて、ゲーム制作の話。今までは自前で更新や描画、初期化等のメソッドを持ったクラスを作っていた。しかし、よくよくXNAのドキュメントを読んでみるとGameComponentなるクラスが存在していた。これは私が自前でやっていたのと同じことができるXNAのゲーム用クラスだ。実行の優先順位とか自前クラスが持っていた機能を余すことなくGameComponentは持っている。これはXNAが想定するのと同じアプローチでゲーム開発を行えていたことを意味する。当然ながら移植作業も簡単だった。同じ機能を持っているのだから、それぞれ一対一で置き換えていくだけである。これによってマルチスレッドで実行するための処理など、デバッグの手間がかかる処理もソースから消滅。他にも自前のクラス群がかなり消え、非常に見通しのいいものになった。やっぱり、フレームワークを使ったプログラミングはシンプルが一番だ。用意されているものをできるだけそのままでスッキリと使う。フレームワークの想定する挙動に沿うように実装する。これだ。というわけで、基礎部分の作成がそろそろ完了だ。

WaitHandle.WaitAll()の最大数制限を回避せよ

作成中のゲームでまたまた問題。スレッドプールに各種オブジェクトをガンガンつっこんで処理させている。ゲーム画面の制御も弾の一個一個も敵も得点も何もかもがまったく同じキューにつっこまれて連続で処理されるのである。それらの処理は終了をWaitHandle.WaitAll()で待ち合わせている。が、WaitHandle.WaitAll()の制限で65個以上のManualResetEventなシグナルを待ち合わせできないようなのだ。ManualResetEventの配列はもちろん普通に配列だから65個以上作成できる。なんでやねん・・・。というわけで、64個ずつセットにして順次待ち合わせすることにして解決。今回確認できた範囲では200個程度のオブジェクトを問題なく制御できた。もっと増えても問題ないだろう。1000個ぐらいさばけたら御の字だが・・・。

XNA 2.0ベータ版に移植

新しく作成しているゲームシステムをXNA 2.0のベータ版で動くように修正した。といっても、私が理解して使っている範囲では、ほとんど修正なしで動作した。Managed DirectXの時の更新とはエラい違いである。XNA 2.0は1.0同様にVisual C# 2005やVisual Studio 2005上で動作する。念のため確認してみたが、Visual C# 2008 Express EdtionからはXNA 2.0の新規プロジェクトを作成できなかった。よって、開発環境は自動的にVisual C# 2005なので、.Net Framework 3.5と共存はできず、.Net Framework 2.0ベースの開発となる。Express Edtionでも問題なく動作するようだ。ドキュメントにもそう書いてあるので間違いない。XNA 2.0らしい機能はまだ何も試していない。
プログラムの開発は基礎部分は完了。ゲーム内容の実装に入った。とはいっても、絵は全部適当なダミーだし、音楽はドの音が一定間隔で鳴るだけだ。 まあ、ボチボチね。ちなみに前回書いた実装では問題が起こった。スレッドプールにキーボード状態を更新するようなオブジェクトをつっこんで、更新作業を行っていた。ところが、キーボード状態の取得はGameクラスのUpdateメソッド内から直接呼ばれるクラス内にないと正常に更新されないようなのだ。よって、Updateメソッドの先頭部分で状態だけ取得しておいて、ボタンの連射とかおしっぱなしとかの判定処理をスレッドプールで行うという二段構えにせざるを得なくなってしまった。カッコワルイ・・・。

ゲームのシステムを整理

LuaInterfaceを用いたゲーム制作サークルのサンプル実装から、それを整理したゲームシステム、さらにそれを流用し制作した個人的なシステムを経て、新しいのを制作中(をい)。
今回はLuaInterfaceを用いたスクリプトでゲーム進行を管理するのやManaged DirectXを呼び出してゲームパッドをサポートするのを取りやめ、全部XNA GSEの中だけで完結させることにした。ゲームパッドのサポートを捨てるのは気分的によくはないが・・・。XNAの性質を考えるとM$の気持ちもわからなくはないのだが、Windowsのゲーム開発環境でもあるという観点から考えると、Xbox360ゲームパッドだけのサポートというのは納得のいかないところだ。
今回のシステム上の改善点はゲーム内で使用されるオブジェクトは互いに無関係にスレッドプールにつっこまれて更新処理されるところだ。今までのは特別扱いでマルチスレッド処理されないオブジェクトがあった。例を挙げるとキーボードとゲームパッドの処理は順番に行っていた。考えてみたら、これらは全く無関係の間柄で、同時にやってしまえる。あるオブジェクトの更新を待ってから処理する必要のあるオブジェクトはそれを待つことができるようにしてあるので、順番を考える必要がある場合もOK。たとえば、入力デバイスの状態(あるボタンは連射中か、押しっぱなしか、押されていないか)が最新の状態に更新されてから、自キャラを動かすとか。現在はC#で利用できるThreadPoolのクラスを使って処理している。検証していないが、ここでは問題が発生しているはずだ。スレッドプールが満タンの状態ですべてが待ち状態に入ったときに、みんな待っているオブジェクトの更新がスレッドプールに突っ込めずにいつまでも処理されず、しかしみんなが待ち続け・・・結果、処理がロックしてしまう現象が起こりそうだ。この辺は後で修正するか、仕様上の制限としてそのまま使うか・・・まあ、私が遊ぶために作ってるから問題を実際に経験してからでもいいかなぁ・・・。結局、一人だとプログラム組んで「あー、楽しかった。」みたいな感じになってしまう。困ったものだ。
今までのシステムは不満点が数個あったのだが、新版では今のところ満足できている気がする。・・・まあ、考えの至っていないところが後々出てくるのが常であるから、どうなるかは未だ未知数。XNA 2.0が年内リリースらしいので、それまではこのままボチボチいこうかと思っている。ちなみにXNA2.0が.Net Framework 3.5と一緒に使えるなら、もう、新しい並列処理方面の拡張(Forループを自動的に並列処理できる等)と組み合わせて非常に楽しい時間を過ごせそうな予感が・・・。が、XNAがXboxに縛られているという現状やVisualStudio 2008がXNAとどういう関係を築くのか不明の現状では、一緒には使えないんじゃないかと思うけど、夢は見ようじゃないか。

最後が大変G2クリア

さて、マビノギだが、不眠症を味方につけてG2を一気にクリア。変身スキルをようやくゲットした。いやー、G2は面倒な場所の往復に始終しているイメージだったのだが、最後の最後にボス二連発という過酷なダンジョンが控えていて苦労した。ラスボスが製造したでっかいゴーレムに殴られ放題ボコられそうになって、逃走。ファイナルヒットでボコり返し、撃破。ここまでダンジョンで一回も死なずに来ていた。で、ラスボス。こいつが魔法使いらしいのだが、某ガンダルフも真っ青な肉弾派。殴る蹴るの暴行と取り巻きの骸骨に殺されること三回。課金サポートの限界にきてしまった。ギリギリでファイナルヒットの発動が可能になり、撃破。さて、このところアツくゲームをしていたが、今週からはゲームもG3もあんまりガリガリやらずに息抜き程度に戻す予定である。とりあえず、マビのデザインコンテストとXNAゲーム製造の方をすすめるかな。XNAも2.0が話に出てきているし、日本語ドキュメントも用意されてきているから、整理しながらいった方がいいかもしれない。

XNAの日本語ドキュメントがXPS文書で公開

XNAの日本語ドキュメントがXPS文書で公開されている。このXPSというファイルは初めて実際にみたいのだが、要はPDFのシェアをM$が崩そうと投入した後発の電子出版物をターゲットにしたファイル形式である。十年以上にわたって着実に普及してきたPDFだが、ここにきて時代遅れだという意見もあったらしい。そこにつけ込んできたM$。とまあ、そんなことはどうでもいい。我々ユーザは電子文書が快適に閲覧できるならば、ファイル形式の存在意義などどうでもいいのである。で、XPSファイルを開いてみた。IEが起動してその中で閲覧するようになっているようだ。いいかげん、なんでもかんでもIEに寄生させるのやめようよ、M$。おまけに超重い。なんで一ページ表示するのにこんなにモタモタするんだ。PDFだとササッと表示されるようような内容でも、いちいち待たされる。マウスのホイールを回そうものならイライラすること間違いなしである。流し読みなんて不可能だ。私のパソコンのスペックが低いなんてことはあり得ないから、単に動作が鈍いのだ。これで打倒PDFなんてことを考えているとは、馬鹿過ぎる。単なる電子出版物をあつかった場合、利点といえばVistaに標準でインストールされているというただ一点のみじゃなかろうか。XPSからPDFに変換して読もうかと思ったのだが、いいツールが見あたらない。

キーボードのロールオーバー問題

シューティングゲーム制作で自機が動くようになった。弾も出る。まあ、まだ動いて出るだけの段階だ。XNAはキーボード、マウス、Microsoft Xbox 360 Controllerのみをサポートしている。通常のゲームパッドは使えない。使えるのだが、Managed DirectX 1.0に頼る必要がある。XNA開発といいながら、MDXのランタイムをあてにするのは気持ち悪い。
よって、今回はゲームパッドサポートなしで考えている。そんな状態で、キーボードの話である。現在開発に使っているノートパソコンのキーボードは、同時に四つ以上のキーを関知できないようなのだ。カーソルキーで自機を移動させながら、弾を出すところまでは動かせる。斜め方向に移動させるには、カーソルキーを二つ使う。この段階では、まだもう一つのキーを使って弾を出せる。しかし、さらにもう一つのキーを使うような仕様にすると、四つのうち三つに絞り込まれてしまう。四つ以上の押しているキーのうちよくわからないルールで三つだけ押している状態になってしまうのだ。このキーボードのキー同時押しの認識できる限界数をロールオーバーというらしい。モロにこの問題に衝突してしまった。マビノギやってて、たまにキーの入力を受け付けない時があるのはこれが原因か。まあ・・・いいか、三つでがんばろう。

毎日三時間前後で製造中

というわけで、ゲーム制作を開始した。イラストと音楽の調達は、現状で無視。実際にある程度動くようになってからイラストと音楽調達の算段をする予定だ。音楽はMIXTUREで何とかしちゃおうかと考えている。
ゲームの題材としては、はじめ、プログラミング言語の学習を取り入れたアドベンチャーゲームを考えていた。ペットロボットみたいなもののAIをプログラミングして、勝ち抜き戦でトーナメントを、とか。ストーリーの骨格は、少女が過疎な田舎の中学に転校してきて、その獲得に向けて各クラブがペットロボット大会の地方予選開催に便乗して対決する、少女は自分の自由をかけて自らも参加するみたいな(笑)。まあ、おもしろくなさそうな感じになってきたので中止。
その後、ファミコンテイストなアクションゲームの構想を経て、我々のサークルが元々目指していたシューティングゲームで落ち着けることにした。今まで作ったコードも流用できるし。流用ついでにキャラクターも流用する。ゲームのコンセプトは(前回作成したコードの成果を取り入れた)ピクセル単位の厳密なあたり判定だ。縦スクロールな段幕系にはならない予定。大きめのキャラクターが変なことをするのを避けるようなボス戦だけで構成された横スクロールなシューティングを予定している。Wikiを立ち上げて設計作業と実装作業中。たぶん計算量が増えそうなのでマルチスレッドでガリガリ処理するような箇所も出てくると思う。一応、現在習得済みの知識で実装できるはずである。・・・時間はかかるだろうが、完成させたいなぁ・・・。

ピクセル計算による接触判定試作

XNAで2D画像同士の接触判定計算を試作してみた。まず、それぞれの画像でアルファチャネルが全開のピクセル以外を全部Dictionaryにつっこんでおく。この時点で、半透明の箇所についてどのぐらい透明なら接触していないと判定するかを選別することもできる。FF(16進数)だったら完全透明のみだし、例えば80(16進数)なら半分ぐらい透明でも接触しないようになる。2D画像が回転された場合は、Dictionary内の座標に対しても変換計算を行う。実際の接触判定時には接触元の画像のDictionary内のデータが接触先のDictionary内にあったら接触、なかったら非接触という処理をしてみた。巨大な画像をあつかった場合に座標の回転処理で激しい処理落ちが発生する。しかしながら、別プログラムであらかじめそれぞれの回転角度に応じたDictioaryデータを作成しておいて、それを読み込めば高速化できるだろう。現在の回転角度に対し、前後の角度のデータを背後で別スレッドを使って先行計算しておいてもいいだろう。こういう処理は並列屋さんの得意とするところだ。その場合も360度分用意せずに30度ごとにすれば、一個の2D画像に対して12個のDictionaryですませることができる。サンプル公開はもう少し整理してから。もうね、ゲーム制作サークルの制作意欲の低さは、どうしようもなさそうなので、自分でレトロゲームくさいものを一つ作ってしまい、サークルの成果物としてリリースしてしまうことにした。個人のリリースということにしてもいいのだが、サークルは私が結成したものだし、命名も私だ。サークルとして、何もリリースしないというのは悲しいではないか。ちょっと、仕事が忙しくなっているのでバリバリ作成というペースは不可能だが、ボチボチ作っていきたい。

このサイトの方向性は間違いだろう・・・

このXNAというサイトが日本のXNA公式サイトらしい。・・・いや、XNAはこのサイトの雰囲気でゲーム制作できるようなツールではないだろう、M$。なんかコラムがあって、主婦がXBox360を買いに行ってゲーム制作をするみたいな流れになりそうなんだが、いや、この主婦が「結婚する前はゲームプログラマやってました。」とかではない限り、素人がいきなりXNA使ったからといってゲームをバリバリ作れるとはとても思えない。XNAの説明もつかみ部分で「「自分でゲームを作ってみたいなあ。」「このゲーム、もう少しこうだったら、もっと面白いのになあ」なんてこと、考えたことありませんか？XNAは、そんなあなたの夢を叶えちゃうんです！」とか言ってる。ライトだなぁ・・・。簡単にゲームができると思って使ってみたら、結局のところXNA開発のメインのプログラミング言語であるC#を使いこなせないと何もできないことがわかるだろうし、開発環境であるMicrosoft Visual C# 2005 Express Editionはとてもじゃないが素人に優しいわけではないし、DirectXに起因するゲーム開発のあれこれを知らなければならないだろう。このサイトの雰囲気でゲーム開発を行えるようなツールというと、マウス操作だけでちゃんと影が出て水が流れて太陽がある3D空間を好きなように歩き回れるようなひな形を生成するぐらいはやってもらわないと・・・。やっぱり、何か方向性が違うサイトにしか見えない。

XNAサンプル 第十一回「3D画像透過」

第十一回は3D画像を表示し、半透明にする。GraphicsDeviceのRenderStateのなんちゃらBlendというプロパティを適切に設定すると透明になる。RenderState.BlendFunctionを使えば単なる半透明だけでなく、色の混ぜ合わせ方を制御できるらしい。

「Draw3DTransparent.ZIP」をダウンロード

 

私的に気ままなプログラミング No.014

影の描画をXNAのMatrix.CreateShadow()を用いて得たMatrixでモデルを変換して描画してみた。・・・うーん、いかにも簡易機能という性能である。特定の平面相手にしか影を描画できないのだ。凹凸のあるModelの上にModelをおいて、凹凸に影響された影ができるというような機能はない。Planeに映った影の位置を変換で得られるだけだ。色もついてて微妙・・・。有用に使おうと思ったら、Effectかけて黒くするか黒いモデルを別途用意するか・・・。Effect周りはノーチェックなので、そこまではまだできない。ちなみに影が別のModelの上でチラチラと表示されるときはGraphicsDeviceのRenderState.DepthBiasに数値を設定してあげると前後関係を明示できるのだ。CreateReflectionという鏡面反射の変換Matrixを得る同類のメソッドもある。

私的に気ままなプログラミング No.013

さて、次なる目標は空の描画としたい。空というと、雲と太陽である。雲が描画できたら煙も描画できる。太陽が描画できたら月や照明器具の描画もできるだろう。その次の目標は地面である。普通の地面は3D画像でモデリングすれば事足りるだろう。よって、地面を構成する要素でそれらしいモノを描画することになる。ズバリ水面だ。背景が移り込む水面。流れる流水。ゆらゆらと水面に映り込んだ背景は水の流れによって揺れるってなもんだ。水面が描画できるなら鏡が描画できる。空ができて、水の流れる大地が描画できたら、それらしいパーツは全部そろうんじゃなかろうか。・・・先は長そうである。
追伸、影の描写があったなぁ・・・。次は影に挑戦だ。

私的に気ままなプログラミング No.012

できた。XNA Game Studio Exrpess 1.0 Refresh環境下において、Model オブジェクトからVertexBufferとIndexBufferを取得し、それらを用いて別のModelオブジェクトをModelを構成するMeshの上に置くという処理である。XNA Game Studio Exrpess 1.0 Refreshだけの機能で実現していて、外部のライブラリを必要とせずベクトル計算の基本的なところだけを拾い読みして何とかなるような感じで作成した。ソースコードは清書するつもりで殴り書きであるが、それでも資料価値が高いと思い、とりあえず公開。接触判定、Collision Detection、RayとPlane、交差判定とかで検索しまくって、それでも解決できなかった同士の方々、なんとかできました。参考にしてください。カーソルキーで円錐が動くのだ。2007/07/14に多少清書したファイルに差し替えた。

「PointOnMesh.ZIP」をダウンロード

私的に気ままなプログラミング No.011

さて、今回はModel の上にいかにしてキャラクターを立たせるかという挑戦を・・・。いやー、ベクトル計算なるほどという感じだ。バグがあるが、なにか凹凸をとらえようとして怪しい動きを見せるようになってきた。なぜか複数の面の上に立とうとして挙動不審になる問題が発生している。これができるようになると3Dゲーム製造の野望が一気に身近になるんだけどなぁ・・・。むぅ?

後日談はコチラ。ソースもある。

テストスクリプト作成開始

最近休止していたゲーム制作サークルの活動を復帰。毎日少しずつ機能テスト用のスクリプト作成を続行中である。現在90個の関数のうち14個15%の試験を終了。音楽周りでつまらない勘違いしていて、全関数でバグが出たがそれ以外は今のところ好調。角度の指定がラジアンなのだが、度数指定の方が直感的にわかりやすいと思うので仕様変更を計画中。あるいはラジアン-度数の変換関数を追加するか。その方がいいのかもしれない。基本的にはManagedDirectXベースで作成されていたコードのXNA移植なので、だいたいは動くはずで安心してはいる。

私的に気ままなプログラミング No.010

なんとかXNA Game Studio Exrpess 1.0 Refresh環境下でModelから頂点のデータを取り出して、それからPlaneを生成して、飛行機に対応したBoundingSphereとの当たり判定を行うことに成功。まだ、当たり判定の半径とかのサイズが微妙で当たってないのに当たってたりする。が、基本的な方針は固まったと言えるだろう。もう少し、当たり判定周りの仕組みを調べたら、もっとゲームらしいことができそうだ。XNA Tutorials and XNA Tools - Model Triangle Selection in XNAとかが参考になった。後は地面にキャラクターを立たせるとかそういうのを理解すればいろいろなところで利用できるだろう。

ベクトル計算勉強中

最近ずっと停止中だった3Dゲームで、ベクトルの計算についていろいろと特性を知っていると目的のものを作ることができそうだと判明。そこで、ベクトルの計算や性質についての勉強を開始。・・・高校と大学でやった覚えがあるなぁ。英語も数学も高校や大学で習ったときにきっちり覚えてたら、何度も同じ勉強をして時間を無駄にすることはなかったんだろう。が、ベクトルに関する問題の出題パターンや英単語や英文の丸暗記といったいわゆる暗記型勉強にはどうも興味が持てない体質だし、やっぱり興味を持って自分から学ぶというのはまた違うと思ったりもするのだった。とりあえず、XNA開発に流用することを前提として勉強している。

過去三ヶ月のゲーム制作サークル

　さて、ゲーム制作サークルの活動を少し休んでみたところ、見事に三ヶ月間何の反応もなくなった。これはいったいどういうことだ。昨日、MLで近況報告を頼んだところコアチームメンバーの一人から反応があった。曰く「XNA使ってSTG的な操作の実装方法を一通り網羅」という。結局のところサークルとして活動しているのだから、サークルへフィードバックが行われないというでは、あまり意味がない。そもそも、三ヶ月も誰からの反応もない状態というのはどうなんだろう。自分のテストコードを公開するのがいやだったら、工夫した点や押さえておいた方がいいポイントなどをWikiにちょっと書いてくれると役に立つに違いない。一からコードを書くとき、ちょっとした工夫やポイントというのは必ずあるものだ。ましてや、それは同じゴールを想定したコードなのだから資料としての価値は高い。私のコードはLuaスクリプトの実行が中心を占める。シューティングゲーム以外のゲームにも流用できるよう汎用的な用途に使うこともある程度視野に入れて作成されている。汎用的であるということは、それだけ無駄も多い。コアチームは全員プログラミングをこなすことができる人間だから、スクリプトを用いない設計でもそれほど問題にはならない。スクリプトの実行エンジンを持っているために煩雑になっている箇所がある。一部だけスクリプトを用いるなど、この辺の調整を行っていった方がいいのだろう。こういう試行錯誤を行うなら別の思想で作られた同じ目的のコードというのは価値がある。ゲームのシナリオについては、ストーリー作成は完了してくれている。しかし、それをゲームとしてどう演出していくのかという点で止まってしまっている。今の段階ではサークルとして機能していないといわざるを得ない。
追伸。よく見たら丸二ヶ月だった。

XNA Game Studio Express 1.0 Refresh

XNA Game Studio Express 1.0 Refreshがやっとリリース。待たせやがって!

XNAの更新はまだか!!

　今月、XNAの更新が行われる予定らしいのだが、まだ公開されない。3Dゲームの方は今回の更新で実装される予定の機能を使う予定なので更新停止中。そこで息抜きもかねて、ラグナロクに課金。保護者付きの非公平狩りに二晩ついて行って、対人間・動物スキルブルズアイを習得。

私的に気ままなプログラミング No.009

　遠くのものにフォグがかかるようになった。後は当たり判定さえ実装したら、とりあえず必要最低限だ。ここまできたら、タイトル画面、自機やマップの選択、速度変更等のゲームとしての体裁を整える段階である。当たり判定はthe XNA Game Studio Express Updateの"Added the ability to read vertex and index buffer information from Model types"の機能を使う予定。すでにメソッドだけは用意されているようなのだが、実行してみたところ"Not Supported Exception"とかなんとか言われてエラーになる。未実装だったんだなぁ・・・。

私的に気ままなプログラミング No.008

　でっかいモデルがでっかすぎると処理落ちした。というわけで、でっかいモデルの大きさをある程度制限する必要がありそうだ。だが、狭いマップでは興ざめということもあるだろう。そこで考えた。ここでも困難は分割せよ、である。でっかいモデルを真上からみて六分割(あるいはもっとたくさんに)したデータを用意する。そのモデルをきっちりと3D空間に並べる。カメラの視界内に収まっているものだけを描画する。これによってモデル全体の描画が発生しないため、処理低下を軽減できる。分割数を増やすことでより細かいディテールを持つモデルもストレスなく表示できるだろう。この辺に関してはすでにできているコードをほとんど修正することなく実現可能である。タイトル画面とかゲームとしての体裁を整えながらXNAの更新待ちかな。ある程度できたら、同志達と知識を共有するために全ソースを公開する予定。

私的に気ままなプログラミング No.007

　某XNAアプリを解析したところマップもModelで実現している!!でっかいモデル作って・・・それでいいのか。なんと恐ろしい。そうなれば話は簡単である。結論としてはあるものをそのまま使って、ある程度までできるようになっているという前提を忘れないようにということだろうか。この方向で再度設計を行うことにした。

私的に気ままなプログラミング No.006

　問題発生。どうやらIndexBufferの配列はshort型の範囲が限界らしい。符号付きだから数としては32768個だ。とりあえず作成するのを目的として、マップ全体のプリミティブを一気に作成して、それを一気に描画するということを予定していた。が、最大数に現実的な限界があるとなると別の方法を考えなくてはなるまい。進行方向だけの毎回作成して描画するしかないか・・・。うーむ。とりあえず、データをテキストファイルで用意すると作成にエディタとかを使わなければならず、半角フォントは縦長であり、実際にできてきたのとイメージが食い違いそうだった。そこでグレイスケールのBMP画像を用意して、ピクセルのデータ=高さという風に高低を計算することにして再度設計中。バンプマッピングの要領である。最低限のサンプルとして用意されたものを理解しても、それを組み合わせて一本の意味のあるプログラムにしようとするとなかなかに難しい。というわけで、ネチネチ進行中・・・。

私的に気ままなプログラミング No.005

　地形生成の設計を開始。地形を生成してから、アレンジとして3Dモデルを配置するという方向で設計している。前回は全部3Dモデルで実現しようとしたのだが、地形の傾斜などを実現するにはすべての3Dモデルに対して個別に角度などを設定する必要があった。はっきり言って一生かかりそうな作業・・・。というわけで、地形はプリミティブで作成して、それにテクスチャを張ることで実現することにした。モデルと違っていろいろと考えることがあるので、少々かかりそうだ。この辺ができてきたら、かなりそれらしくなるだろう。

私的に気ままなプログラミング No.004

　とりあえず、なんとかソレっぽい見た目になってきた。うーん、マップの生成どうしようかなぁ・・・。

私的に気ままなプログラミング No.003

　カメラは自機の後ろ一定距離固定になった。まあ、カメラと操作法はもう少しできてから再度調整した方が良さそうな状況だ。
で、次。どんなゲームを作る場合も問題になってくるのだろうが、画面が動くだけではゲームとはいえない。パスルでもシューティングでもRPGでも、システムだけできてもデータがなければどうしようもない。現在作成中のゲームもレースゲームだからコースが必要だ。2Dでパズルだったらテキストファイルで適当に・・・なんてこともできるが、3Dで自由に移動なゲームだとどうしよう。この問題を解決すべくマップを作成するツールを作ることにした。キーボード操作で新規の3Dモデルや接触判定を配置していこうというプログラムだ。とりあえずは完成。使ってみると・・・面倒くさい。それも超面倒だ。はじめにひな形をサクッと作るような手段を考えた方が良さそうだ。座標軸の一定距離ごとにテキストファイルで平面的に3Dモデルを置くようにデータを流し込んで、後で角度とかを調節するとか・・・。地面の高さ＞地面から2.0fの高さ＞地面から4.0fの高さ＞・・・みたいな感じでデータを流し込んでおいてから、調整するという方向で再度検討中。

XNAサンプル 第八回「3D画像移動」

　第八回は3D画像の移動。行列計算で平行移動を行う。

「Draw3DMove.ZIP」をダウンロード

XNAサンプル 第九回「3D画像回転」

　第九回は3D画像の回転。回転は回転角度をラジアンに変換し、行列計算にて行われる。回転角度は各座標軸を基準にしたものを指定する。ヨー/ピッチ/ロールを指定したQuaternionというものを用いた回転が用いられることも多い。これについては、また後日。

「Draw3DRotation.ZIP」をダウンロード

XNAサンプル 第十回「3D画像縮小」

　第十回は3D画像を表示し、縮小させる。拡大・縮小ともに行列計算で行う。今まで行ってきた平行移動や回転などと同時に計算できる。拡大・縮小や平行移動、回転を同時に行うときには順番に注意が必要。平面図で試してみれば確認できるが、計算の順番を変えると結果も変わる。

「Draw3DScale.ZIP」をダウンロード

XNAサンプル 第七回「3D画像表示」

　第七回はいよいよ3D画像の表示である。これまたXNAに全面任せっきり。

「Draw3DSimple.ZIP」をダウンロード

私的に気ままなプログラミング No.002

　3D空間をクルクル飛び回れるようになった。次はカメラで自機をどうやって撮影するかってところを作成中。追尾させるのが一番自然なんだろうか。ゲーム的には搭乗者視点も選択できるようにしたい。その場合は簡単でカメラ位置を自機と同じにして、注視点を進行方向の延長線上にすればいい。追尾させる場合は、自機の古い座標をとっておいてそこに順次カメラを移動させていくって感じだろうか。まあ、いろいろ試行錯誤してみよう。明日は定休日なので第七回以降のサンプルを一気に更新してみようかな。

私的に気ままなプログラミング

　ちょいと疲れたので、私的に気ままなプログラミングという感じにライフゲームじゃないコードを記述中。コンセプトは「せっかくだからこの際XNAで3D空間を満喫しよう。」という感じで、本日より進行中。サークルの方では2Dベースなので、3D周りは結構おざなりにしていた。軸が増えると頭の中でまとめられなくなる。今はQuaternion近辺でウロウロ・・・。要は、Yaw/Pitch/Rollを元にQuaternionを作って、そいつをMatrixに変換、任意のVectorをそのMatrixでTransformすりゃいいって感じか。ベクトルとか高校でやって以来忘れ果てて結構厳しいなぁ。高校生か数学科の大学生辺りが一番さくさくプログラミングできる分野なのかもしれない。
XNAに関する英語ドキュメントも日本語ドキュメントも断片的な知識が主である。このBlogでも紹介しつつあるようなコードは世界中に同様の品が出回っている。これらのレベルならXNAの正規ドキュメントを見れば網羅できる。わざわざネットで調べなくても、ネットでバラバラの知識をかき集めるようなまねをしなくてもXNAのドキュメントを読めば事足りる。しかし、それらを実用的に組み合わせて何か動かしているものとなるとグッと数が減る。XNA付属のサンプルはといえば、XNA的にXbox360のコントローラしか対応していない。ManagedDirectXを使って普通ののゲームパッドでも動くなんてマネはしてくれていない。こういう実際的な事例も組み込んで、ある程度資料価値が高いものとして何か作ってみたいというのも目標の一つである。期間は夏ぐらいまでを予定。サークルの方のすすみ具合も監視しつつ作業するので、止まったりするかもしれない。

XNAサンプル 第六回「2D画像透過」

　第六回はゲーム画面に画像を表示し、縮小させる。拡大・縮小ともに倍率を指定するだけ。

「Draw2DScale.ZIP」をダウンロード

XNAサンプル 第五回「2D画像透過」

　第五回はゲーム画面に画像を表示し、透過させる。色の指定を調整するだけ。
このエントリは記念すべき666エントリ目。獣の数字である。

「Draw2DTransparent.ZIP」をダウンロード

XNAサンプル 第四回「2D画像回転」

　第四回はゲーム画面に画像を表示し、回転させる。ラジアンで回転角度を指定すればグルグル回る。

「Draw2DRotation.ZIP」をダウンロード

よっし、今度こそ全部実装!!!

　よし、今度こそゲームシステムの基本機能を実装し終えたと思う。やっと、デバッグだ。長かった。デバッグを終えることができたなら今度こそ、ゲーム本体の製造に突入できることを祈るばかりである。ゲームの内容に関しては別メンバーの担当である。あくまで私は統括であり、プログラムの担当であり、ゲーム本体に関してはサポートなのである。でなければ、メンバーが互いの得意分野を生かし、役割分担をする意味がなくなる。遊びとはいえ、それぞれが重要な部分を担当しているということを忘れないでほしいのだ。そして、この活動を楽しんで、自ら動くという姿勢を貫いてほしい。楽しくなかったり、やる気がないなら、やめてしまえばいい。私は一人になっても、何か作ることを続けるつもりだ。作ったコードは、現状における私のXNAに関する知識の集合体である。今後何を作るにしてもXNAを前提にしている限り、ムダにはならないのだ。というわけで、私はサークルの活動をすることで新しい知識の獲得を行い、探求心を満たし、満足を得ている。だから、自分から進んでサークルの活動を続けている。技術者やクリエイターなど、何かを作り出す人間が新しい知識の獲得や探求心を捨てたとき、死を意味する。今の状態が最上であるはずもない。目標に到達していないなら、それはまだ何か足りないことがあるからだ。足りないなら足りるように努力を続けなければならない。現状に満足してはならない。満足できないから、自分でやるのであり、満足できているならやるひつようはない。時間がないなんてのは大部分がいいわけだ。やらなきゃまずいよな・・・といった状態で都合のいいいいわけを見つけたに過ぎない。例えば、今日は時間がないからゲームでもするかではなく、今日は時間がないからゲームか創作活動か残念だけどどっちかしかできないといって悩むべきなのだ。悩んで、どっちかに決めたらそうすればいい。自分が既存のものに満足できず、満足できるものを作りたいから作るでなければ、いいものはできるはずもないし。まあ、私はそういう感じで作りたいから作っている。

プロファイリング

　ゲーム制作だが、未実装の機能があることをすっかり忘れていたので実装作業。キー入力のログをとってゲームのリプレイ再生をするという機能のためのキーロガーである。まあ、別段難しい機能でもないだろうと楽観視しつつ、開発中。後はキーコンフィグの拡張をして完成という運び。で、コードのブラッシュアップという作業がそろそろ必要になってきた気がする。最大の速度低下を引き起こしていた箇所は並列処理によって力業的解決をみた。しかし、依然として高速な動作とは言い難い。メソッドごとの速度やメモリの使用に関するデータを収集して、問題箇所を洗い出さなくてはならない。並列コードは全体としてはごく一部だ。普段から並列処理は簡単に高速化をできるみたいに書いているが、実はいろいろと考えなければならないこともある。並列コードでない箇所が全体の半分を占めているとする。するといくら並列処理で高速化を行っても倍以上の速度には決してできない。これは有名な論文にも書かれている法則だ。初期化に五秒。処理に五秒かかるとする。全行程で十秒だ。このとき処理を並列化して二秒になったとする。初期化処理はそのままだから全体では七秒となる。初期化処理に五秒かかってしまうのは決定事項なので、全行程はいくらがんばっても五秒未満にすることはできない。並列処理を工夫して一秒になっても、六秒。五秒の壁は厚い。できるだけ並列処理でない箇所を短くして、並列処理による恩恵をできるだけ長く継続させなければならないのだ。この法則による限界を打ち破るためには並列処理でない箇所を改良しなくてはならない。ゲームの場合は同じループが延々と繰り返される。起動は現状でも妥当な速度である。ゲーム中の動きがもっさりしているので、その繰り返し部分だけでもいいからもっと調査・修正する必要がある。いつでも鉄則はより遅い箇所をより早く、だ。適当に普通の箇所は放置。
で、そういう場面に使われるのがプロファイラである。JavaだったらEclipse上からキレイなグラフを作ってくれるプロファイラが有名で非常に役に立つ。何から何まで知りたい情報を収集してくれる。が、VisualStudioには見あたらない。M$によるとSystem.Diagnosticsというクラスが用意されているらしいのでそれを使うことになるらしい。ソースコードにトレース用のコードを追加しないとだめなのか・・・。面倒だなぁ・・・。

XNAサンプル 第三回「2D画像移動」

　第三回はゲーム画面に画像を表示し、移動させる。2D画像の表示ができるなら、新しいポイントは特になく、表示後に座標指定を行っている箇所の数値を変化させるだけ。

「Draw2DMove.ZIP」をダウンロード

XNAサンプル 第二回「2D画像表示」

　第二回はゲーム画面に画像を表示する。画像はプロジェクトに含めた後にAsset名をつけて、その名前を使い画像を読み込む。

「Draw2DSimple.ZIP」をダウンロード

XNAサンプル 第一回「初期化」

　今回からXNA Game Studio Express 1.0でゲームを作成する際に役に立ちそうな小さなソースを順に公開していこうと思う。以下のような内容のソースを追加していく予定。付属の英語ドキュメントで、それぞれの項目について今までのDirectX SDKよりもしっかり解説が行われている。まずはそれに目を通すことをおすすめする。

** 画面初期化
** 2D画像表示
** 2D画像回転
** 2D画像透過
** 2D画像縮小
** 3D画像表示
** 3D画像移動
** 3D画像回転
** 3D画像透過
** 3D画像縮小
** 2Dと3D同時表示
** 3D画像の接触判定
** 3D画像 + Effect
** 3D画像 + Fog
** 3D画像をQuaternionで回転
** キーボード入力
** ゲームパッド入力(XNAでサポートせず / Managed DirectX 1.1使用)
** Xbox360 Controller入力
** Xbox360 Controller振動
** スクリーンモード切替
** 音楽再生
** バックバッファサイズの変更
** タイトル変更
** マウスカーソル表示
** 同時起動抑制
   Vector3をQuaternionで変換
** ファイルの取り扱い
   インストーラ作成(InnoSetup)
   動画再生(XNAでサポートせず)
** 2D画像移動

(注)
**:  動作確認まで終わっている
* :  ハードをもっていないなどの理由で動作確認できない
空白:まだできていない

第一回はゲーム画面の初期化について。XNA Game Studio Express 1.0を起動して、ゲームのプロジェクトを新規作成するとソースが自動生成される。XNAゲームはこれを元に作成する。特に言及すべきことはない。

「InitScreen.ZIP」をダウンロード

XNAで3Dモデル同士の衝突検出

　XNA Frameworkで3Dモデル同士の衝突検出はどうやるんだろうと思って調べてみた。そもそも基本機能として用意されているのか。2Dにも適用できるんだろうか、とか。調べてみたところ、XNAには標準でcollision detection用の機能が用意されているようだ。詳しくは「How to: Detect Whether Two Objects Collide」というヘルプがあるのでそれをみてもらうとして、なるほど。当たり判定用のオブジェクトを作ってそいつを3Dモデルと一緒に座標移動して、そいつ同士で当たり判定をするという流れか。モデルの形状自体が当たり判定用のオブジェクトになるわけではなくて、球や直方体(BoundingBox, BoundingFrustum, BoundingSphere, Plane, and Ray)でモデルを近似的に表現してあげないとだめなようだ。でも、これが標準で用意されてるだけでずいぶん楽だろう。なるほど。まさに近代的なソフトウェア開発である。自分でいろいろ作らなくても標準機能におんぶにだっこ。積み木細工である。

初期化処理も高速化

　実際にゲームを載せる場合には改良も必要だろうけど、一応の完成をみた自作のゲームシステム。システムでは初期化時にゲーム内のオブジェクトを大量に生成する。このシステムやゲームに限ったことではないのだが、システム内で必要になった場合にその都度オブジェクトを生成すると、オブジェクトの生成という処理は非常に負荷が高いため全体の処理速度が低下してしまう。そこでオブジェクトを事前に作っておいて、それを使い回すことによって高速化する手法がある。起動速度やメモリの使用量を犠牲にしてでも、稼働状態のパフォーマンスを確保しようという考え方だ。オブジェクトプールなどといわれている。一般的なWebアプリケーションなどでも使われている。例えば、データベースへの接続をあらかじめ作っておいて、データベースへの接続が必要になったときに使っていない接続でデータベースへの処理を行う。使い終わったら返却する。こうすることでデータベースへ接続する際の認証とかの遅い処理を毎回することなくデータベースを使うことができる。特にこのケースはコネクションプールと呼ばれる。まあ、そういう手法を自作のゲームシステムでも使っている。が、ゲーム中の処理がいくら早くても、起動が遅いとイライラするわけだ。ゲームじゃないWebアプリとかなら起動速度を犠牲にしてもいいのだろうが、ゲームを起動するということは早く遊びたいに違いないわけで・・・。で、起動と同時に遅い処理を開始して、その処理をやりつつ、同時に他の処理をやってしまうことにした。マルチスレッドの技術を使えば一定時間の間に完全に独立した処理を複数実行できる。ハイパースレッディング対応のCPUやマルチコアのCPUだと複数の処理を同時実行しても互いに影響を受けにくい。というわけで、初期化処理をマルチスレッド化してみた。結果、起動速度が劇的に改善した。他にもオブジェクトプールやマルチスレッドによって高速化できる箇所を探してみるかな。

XNAへシステム移植完了

　ManagedDirectX 1.1で開発していたゲームのシステムをXNA 1.0に移植していたのだが、先日完了した。フォントとかゲームパッドとかXNAだけでさばききれない部分は切り捨てるか迷ったのだが、結局、MDXのサポートを借りることにした。前にも書いたが、明快さにおいてXNAの方がほとんどの部分に関してMDXよりも優れている。XNAはWindowsとXbox360との互換性にこだわりすぎている感じがする。ゲームパッドなんてXbox360のゲームパッドにしか対応していない。Windows用も売っているが、わざわざアレを買う人はいないだろうし、互換品もまだなさそうだ。もう少しWindowsゲーム開発環境としての面も考慮してくれたらいうことなしなのだが。次は並列処理部分を改良しようかと考えている。現在、ThreadPool.QueueUserWorkItem(WaitCallback, Object)でオブジェクトを順次処理させている。これよりもスレッドを起動しておいてから、それぞれのスレッドに自分からデータを取りに行かせて処理をした方がよいだろう。処理を自分で書かないとだめなので、慣れてないならリスクがある。まあ、慣れてしまえば、ちょっと面倒なだけで難しいわけではない。というわけで、手抜きをやめて改良開始。他にも高速化できそうな箇所を探していく予定。

XNAの問題点

　XNA開発だが、Windowsゲーム開発環境とみた場合に微妙に気に入らない点がある。まず、一番気に入らないのはゲームパッドである。XNAではXbox 360 Controllerのみをサポートする。通常のゲームパッドを使いたい場合はManaged DirectX 1.1の助けを借りなければならない。次に気に入らない点はフォントを使った文字の描画を行うことができないこと。ユーザーが作成したそのような機能を提供するライブラリがいくつか提供されているようだが、あまり他所からコードを流用したくはない。最後にビデオカードのハードウェア要件が厳しいこと。順当に作った場合、ピクセルシェーダ 1.1以上をサポートするDirect3D9レベルのDirect3Dデバイスが必須となる。多少細工をすればこの制限を回避することはできるようなのだが、わざわざフレームワークを用いて開発を行っているのだから、そういうところを降り下げるのは何か間違っている気もする。手を抜きたいからフレームワークを使うわけで・・・。この三点は下手をしたらXNA Frameworkを使わないという選択肢をとらざるを得ないという状況を生みかねない。私が作成しているコードでは、ゲームパッドの入力についてManaged DirectX 1.1の助けを借りることにした。場合によってはすぐに切り離すことができるように作成してある。ゲームパッド、キーボード、Xbox 360 Controller用のモジュールに分けて作ってあるから追加や削除は簡単である。で、文字の描画はそれほど大量のメッセージを出力する予定がないため、画像をやりくりして間に合わせようと考えている。ビデオカードはそれほど低機能なカードを使うのは、ある程度旧型のパソコンであると考えて割り切ることにした。旧型のパソコンは今回高速化のために作った並列処理部分をさばききれないことがわかっているので、切って捨てるのはアリだろう。とまあ、こんな感じで進行中。XNAだが、不満箇所以外はDirectXの意味不明で複雑怪奇なところがきれいに整理されてなかなかいいのではなかろうか。

XNAへ移植

　さて、進んでるのか進んでないのかよくわからないゲーム制作だが、手を入れずに動くだろうと思っていたVistaで動作しないことが判明。結局、ManagedDirectXはVistaに標準で乗らなかったようだ。あるいはオプションで用意されているのかもしれないが、よくわからない。XPと同じようにランタイムをインストールしてやれば動いてくれるだろう。Vistaのリリース候補ではそうやって動いていた。ManagedDirectXの次のヴァージョン2.0もリリースされないことになったらしい。M$的にはXNAに移行していきたいようなのだ。現在使っているManagedDirectX 1.1もいつ終了するかわかったものではない。M$は過去の製品を容赦なく切り捨てるのが得意だからなおさらだ。というわけで、XNAへの移行を決意。ゲーム制作サークルのメンバーは、私以外開店休業状態になっているので文句もあるまい。ボチボチ情報も本家や国内外のユーザから出始めているからやりやすくなってきた。全体的にはXNAはDirectXの意味不明な箇所をかなり覆い隠してくれている感じだ。すんなりと移行するには違うところが多すぎるが、ソースのさらなるリファクタリングも兼ねて移行中。

テストも大詰め

　さて、サークルで作ってるゲームだが、システムの単体テスト用スクリプトの作成が80%を超えた。来週頭ぐらいにラストスパートをかけて完成に持って行きたいものだ。未実装機能と追加・変更の必要を感じるLuaスクリプト用関数やバグが相応にあるので、テストスクリプト作成完了後はそちらの方に着手予定。もはや自己満足のような状態なのだが何とかならないものか・・・。まあ、現在作業予定の積み残しのあれこれをある程度解消したら、個人的にこのシステムを使って、何か公開してみるのもいいかもしれない。ちなみにライフゲームはJavaのがあるので作らないかな。

XNA Game Studio Express 1.0

　さて、XNA Game Studio Express 1.0を少し試してみた。私のノートだとデバイスの初期化がうまくいかない。何も手を入れないで、XNAで提供されているひな形からゲームを作成しようとした場合には、作成したゲームはDirectX3D9とpixcel shader 1.1のサポートという条件を満たしたビデオデバイスを持っていないと正常に起動しない。少なくとも私のノートパソコンである2003年製のThinkPad X31に使われているATI Technologies Inc.のMOBILITY RADEONだとアウト。ビデオデバイスの初期化部分を自前で作ってあげたら動作した。ただ、ManagedDirectXをそのまま使って初期化しているのと同じような状況になってしまって、「デフォルト状態で使って楽できるところは楽をする。」という雰囲気ではなくなってしまう。作ったゲームの動作環境を、3Dグラフィックスのハードウェアアクセラレーションを一定水準以上でサポートした環境に限定する勇気があるか否かでXNAを採用するかどうかが決まりそうだ。あるいはXBOX 360で動作させる予定があるのか・・・。雰囲気的にWindows Vistaの新GUI環境AERO(Aero Glass)が動くかどうかというのと同じ話になるような気がする。古めのマシンを切り捨てるかどうか・・・。悩ましいところだ。私の作ったコードはメイン処理が並列処理で実装されている。私が作った処理は、少なくともPentium 4でハイパースレッディングをサポートしていないと見込み通りのパフォーマンスで動かないらしい。ゲームがある程度完成してきても、これをいかに軽量化するかという問題が残っている。もし、XNAに乗り換えて、AEROが動くレベルのハードウェアを動作対象としたならば、遅い処理をがんばって高速化する必要がなくなる。パソコンの買い換えサイクルは一般のユーザでも現在は非常に短い。ゲームの開発が完了するまで短期間のうちに、ゲームをするユーザの所有するパソコンは買い換えられて高速化している可能性が高い。実行速度が遅いなら速いマシンに移せというのは一番簡単な高速化手法だ。以前も書いたが、ソフトウェア開発の現場にも同じことがいえる。以前から動作しているシステムが遅くて不満だとする。だいたい、今の二倍の性能がほしい。新しいマシンを導入し、環境の移行作業を行ったとする。この場合、実行速度は三倍になる。一方、新しいアルゴリズムを考案し、それを実装するためにソフトウェア技術者を雇い入れるとする。この改良により、実行速度は五倍になるとする。これはどちらがいいのだろうか。どちらがより多くの手間がかかるだろうか。果たして、五倍の性能をたたき出すアルゴリズムが存在するのだろうか。存在したとして、それに思い至ることができるだろうか。現在ゲームを作っているからといって、その動作環境を現在のスペックにあわせる必要もない気がするのだ。難しい問題である。

ビッグタイトルリリース

　今日仕事から帰ってきたら、ビッグタイトルが二つもリリースされていた。一つはJava SE 6。もう一つはXNA Game Studio Express 1.0だ。どちらもダウンロードしただけで、まだ試していない。明日、ゆっくりと検証したい。たぶん、明日からこのblogはJava SE 6で動かしていくことになるだろう。いろいろと楽しいことができるらしいので、ゆっくり遊んでいきたいものである。XNAの方は現在作成中のゲームを移植する方向で調査する必要がある。ゲームのリリースは遅れに遅れているが、確実に進行している。XNAはベータ版を試した限りでは、ManagedDirectX SDKで開発するより面倒なところが多少隠蔽されている。長い目で見て楽できるなら移行するに越したことはない。まあ、それぞれの詳細は明日以降。
追伸。OpenOffice.org 2.1もリリースされている。が、日本語版はまだ。

復活中

　やる気がマイナスまで落ち込んでいたゲーム制作サークルのプログラミングを再開。マルチスレッドで動いてるスレッドからlog4netを使ってログを出せるようにする作業を他メンバーに任せているが、それの開始と完了を待たずにソースのリファクタリングを開始。リファクタリングと同時に一部未実装機能の取り込みを予定している。現在、ファイル数で15%を完了。本ゲーム制作サークルで作成しているゲームエンジンはLuaから各種ゲームを実現するための機能を呼べるようにしてある。よって、ゲームエンジンはあくまでもゲーム用のプラットフォームを提供しているだけだ。サンプルとしてスクリプトで実装されている試作ゲームも、多少ルールを変更してメンテナンスの容易なスクリプトを使えるようにする予定。LuaからC#で実装した各種機能(ManagedDirectX関連機能等)を呼んでそれなりに動くことは確認されたので、このまま制作が続行できそうだ。不安箇所ももちろんある。ゲーム内のオブジェクトはすべてLuaスクリプトで制御される。このとき、パフォーマンス向上目的で処理を並列化して行っている。ところが、非ハイパースレッディング対応や非マルチコア(あるいは非SMP)などの多少古いマシンだと逆にパフォーマンスが激しく低下する。これは少々問題だ。ゲーム動作対象マシンのスペックをXP完動レベルからVista完動レベルに引き上げたら、まあ、大丈夫なんだろうが・・・。

C#とManagedDirectX

　一年以上にわたって勉強してきたC#とManagedDirectXだが、それらとLuaInterfaceを組み合わせた汎用ゲームエンジンの試作品がかなりできてきた。当初は十人近くのグループで分担作業をしていたのだが、班ごとの開発速度差(ゲームデザイン、ゲームプログラム班の生産力とイラスト班の生産力の差が顕著。あっちは何もしていないのに、こっちばっかり作業させられていると感じてしまうこともあったようだ。)やグループの方針(基本は月例ミーティングと多数決。決定事項の再審議や現状の問題点については、月例ミーティングにて何がどう問題なのか、それに対する代替案を述べる。月例ミーティングでは筋道だった意見以外は意見として認めないとしていた。心情的な意見はすべて無効。意見を最後まで言わない/言えない/皆を背得するだけの説明力がない/道筋だった説明ができないメンバーに多大なストレスを与えたようだ。)にあわないメンバーがずいぶん抜けて、今では実質的に三名(休眠メンバー二名)。それも私以外は仕事の負荷が高くて作業になっていないという状況だ。社会人というのは、何かやりたくても仕事やつきあいが忙しかったりして、集中できないわけだ。その中でいかにして時間をひねり出すかというのも、社会人として重要なことだとは思うが・・・。私が主に関わっているのはプログラム班だが、会社でソフト開発して、家でも同じような作業というのは確かに辛かった。ゲーム開発と業務アプリ開発は、はっきり言ってそう違ったものではない。ソフト部品の入出力を決めて、中身の設計をして、データを用意して、プログラミングして、ソフト部品を組み合わせて、試験して、問題のあったソフト部品を修正して、最後はリリースする。データの種類や操作方法がちょっと違うだけだ。要は操作したら、画面に何か出てくる。雑音を取り除いてしまえば、ゲームであるか業務アプリであるかという、言葉だけの違いといっても言い過ぎではない。まあ、そんなことはいい。バグとか修正箇所・改良点は当然あるが、プログラム面だけだがようやくそれらしいものが形になってうれしいわけである。団体として作っている以上、一から一人で作っているというのが少々問題ではある。現段階の試作品でもインベーダーゲーム程度なら楽勝で載せられる。LuaInterfaceは、バグがあったり、多少パフォーマンス的に問題がある。が、最悪、Luaスクリプト側で実装と動作確認が終わってしまってから、それをC#で置き換えて高速化してもいいと思っている。多数の短いLuaスクリプトを組み合わせて、ゲームを作るというスタイルなので、C#へコードを移植する手間はさほどではないと見込んでいるのだ。入出力のデータが同じなら、中がどうなっていようが関係ない。プログラムの一部を例え人間が計算するように変更しても、速度的に遅くなるだけで、結果は変わらない。世界の裏側にネット経由でデータを送って、処理してもらった結果をつかっても同じ。そう作ってある。コレ基本。まあ、とりあえず、もう少し手直ししつつサンプルゲームを作成中・・・。C#とManagedDirectXを使い、ある一定以上の完成度を持ち、目的を持ったプリケーションとして動作するソフトウェアで、ソースが手に入るものというのは未だほとんどない。WorldWindぐらいだろうか。完成度も高く、資料価値は計り知れない。しかし、全画面の処理がちょっと変なのだ。完成度の面で劣っていても、私の作っているコードの資料価値も高いのではなかろうか。ManagedDirectXはユーザに環境設定の作業を強いることなく動いてくれる動作環境がないというのが、最大の問題点だ。XPでさっさとサービスパックにランタイムを組み込んでしまわないところをみると、Windows Vistaを待たなければダメなのだろう。

ManagedDirectXとマルチスレッドによる描画

　とりあえず、動作するサンプルの作成にようやく成功。ここで問題だったのは、マルチスレッドのそれぞれのメソッド内から同時にDirectXをつかった描画が可能なのかという点だ。デバイスの初期化を行う際にスレッドを使うというオプションが指定できるため、マルチスレッドからガリガリ描画できるものと思いこんでいた。が、そうではないようだ(DirectxX10で対応???)。どうしてもタイミングによって動かない場合があったので、描画部分だけを逐次処理にしてデータキューをReaderWriterLockで排他制御にしてみた。そうするとあっさり動作。マルチスレッドやマルチタスクを用いた並列処理というものは、まったく同時という処理が発生しない従来のハードウェアで動作検証するのは極めて困難だ。大量のスレッドも一瞬一瞬では一個しか走っていない。ところが近年になって、ハイパースレッディングなCPUやマルチコアのCPUが普通の店でも入手可能となった。以前では比較的高価なSMPのマシンを入手しない限り、デスクトップではそういう技術とは無関係だった。五年ぐらい前、大学院時代に出席した学会ではマルチコアCPUも発表されていたが、ようやく登場といった感じだ。脱線したが、C#で利用できる排他処理をもう少し調べて、この技術はクリアである。意味不明のエラーに悩まされ、かなり長くかかったなぁ・・・。

C#とManaged DirectX勉強続行

　相変わらず、故あってのC#とManaged DirectXの勉強を続行中。後二・三の技術的事柄が確認できれば簡単なゲームぐらいは作れそうだ。2D描画方面の一部分しかチェックしていないが、まあ、3Dゲームを作るのでなければ問題なかろう。主な残件はマルチスレッドでDirectXな描画領域に画像を描き込めるのかということ。大量の画像を一定時間以内に全部描画してしまうためには、スレッドにして無理矢理詰め込むしかない。そうでなければ、画像が増えれば増えるだけリニアに時間が増加してしまう。ちなみにC#とManaged DirectXに興味のある人はNASA WorldWindのソースを見てみることをおすすめする。CVSのソースにアクセスすればインストーラについても知ることができる。かなり有用なプロジェクトだ。CVSは面倒なことをしなくても、SorceForgeからWorldWindのプロジェクトページを開けば、Webで見ることができる。

Microsoft DirectX 9.0 SDK Update (October 2005)

　故あってManaged DirectXをさわっているのだが、DirectXは二ヶ月に一回の偶数月に開発キットが更新される。DirectX 9.0の開発キットは更新すると、ライブラリの関数の仕様がいきなり変わって以前のソースがコンパイルできなくなったりする。愚かなことに付属のサンプルもコンパイルできなかったりする。通常のDirectXならばランタイムは同じでいいのだが、Managed DirectXの場合は専用のライブラリを入れなければならない。これがまたヴァージョンによって、インストーラを普通に実行するだけだと、入ったり入らなかったりする。最近のヴァージョンは開発キットに付属のインストーラを実行すれば入るのだが、昔のは引数でオプションを指定しなくてはならなかった。で、ヴァージョンアップが面倒なので六月版をしばらく使っていて、久々に更新をした。結果、コンパイルが通らなくなった。挙げ句の果てに画像の回転を行う関数の仕様が変わって、以前、かなり癖のある仕様だったのを理解するために苦労した経験が無駄に・・・。新しい引数の方が素直なのだが、むしろ何ではじめからこうなってないのか疑問で仕方がない。他にも引数が変わっていて修正が必要に・・・。ドキュメントも日本語版は一年以上前のものしかない。当然仕様変更に追いついていないから役に立たない。どうもユーザーをナメてるとしか思えない。さすがM$というべきなのだろうか。