XNA 2.0のコンテントパイプライン~その弐~

プロセッサパラメーター 上の画面はテクスチャのプロパティ画面です。Content Processorの脇に+のついた四角いマークに気づいたでしょうか? クリックすると複数のパラメーターが表示されます。これがXNA GS 2.0の新機能の一つであるプロセッサパラメーターです。XNA GSE 1.0では複数の複数のプロセッサを書く必要がありましたが、XNA GS 2.0ではひとつのパラメーターつきのプロセッサを書くだけで、どのようにコンテントがプロセスされるかを指定できるようになりました。 Textureプロセッサには以下のパラメーターが設定できます。 パラメーター名 用途 Color Key Color カラーキーの指定 Color Key Enabled この値がTrueの時にColor Key Colorと同じピクセルのアルファ値が0に変換される Generate Mipmaps ミップマップ生成のコントロール Resize to Power of Two 元のイメージを最も近い2の乗数のサイズにリサイズするかしないか Texture Format 出力するテクスチャのフォーマット NoChange(変換なし)、Color(32ビットRGBA)、DxtCompressed(DXT圧縮形式) Modelプロセッサでは以下のパラメータが設定できます。 パラメーター名 用途 Color Key Color カラーキーの指定 Color Key Enabled この値がTrueの時にColor Key Colorと同じピクセルのアルファ値が0に変換される Generate Mipmaps ミップマップ生成のコントロール Generate Tangent Frames…

3

カスタムエフェクト

フォーラムの質問を見て、今まで書いていなかったことに気づいたので遅ればせながらカスタムエフェクトの使い方を説明します。 例によって例の如く、コピー元はShawn Hargreaves氏の投稿からです。 独自に作ったエフェクトを使うには2つの方法があります。ひとつはコンテント・パイプラインが処理したエフェクトをゲーム実行時に切り替える方法。そしてふたつ目はカスタムプロセッサを書くことで、コンテントパイプライン内でコンテントビルド時に独自のエフェクトに切り替える方法です。 後者の方法の方が自由度が高く、ゲーム実行時に余計な処理をしなくて済むようになるので、ここではこの方法を紹介します。 まず最初にModelProcessorから派生したプロセッサーを作り、ConvertMaterialメソッドをオーバーライドします。/// <summary> /// ModelProcessorから派生したプロセッサー /// </summary> [ContentProcessor(DisplayName = “MyModelProcessor”)] public class MyModelProcessor : ModelProcessor { // ConvertMaterialをオーバーライドして、マテリアル変換時に自分のマテリアルに差し替える protected override MaterialContent ConvertMaterial(MaterialContent material, ContentProcessorContext context) { // エフェクトを含むことのできるEffectMaterialContentを使う EffectMaterialContent myMaterial = new EffectMaterialContent(); // 使いたいエフェクトファイルを外部参照として指定する string effectPath = Path.GetFullPath(“MyEffect.fx”); myMaterial.Effect = new ExternalReference<EffectContent>(effectPath); // 引数で渡されたmaterialの代わりに、ここで作ったmyMaterialを渡す return base.ConvertMaterial(myMaterial, context); } } ここで指定しているMyEffect.fxファイルは直接読み込んでいるので、Visual…

1

ネットワークサンプルの配信

  XNA 2.0リリースと同時に配信されたネットワーク対応のスターターキットにNet Rumbleがありますが、もっとシンプルなサンプルが欲しいという人の為に4つのネットワークサンプルコードが配信されました。 Network Architectures: Client/Sever XNA 2.0上でのシンプルなサーバー/クライアント型のネットワークゲームのサンプルです。このサンプルではクライアントは単に入力情報をサーバーに送るのと、レンダリングするだけの処理をしています。サーバー側はクライアントから受け取った情報を元にシミュレーションを実行し、その結果をクライアントに送るようになっています。 Network Architectures: Peer-to-Peer 上記のサーバー/クライアント形式に対して、このサンプルではピア・ツー・ピア形式のプログラムになっています。それぞれが自分の戦車のコントロールとシュミレーションを行い、その結果をセッションに参加している全てのプレイヤーに送るようになっています。そして、その結果を受け取った側は、その情報を元に処理を行います。 Network Game State Management このサンプルではネットワークゲームを作る場合のセッション参加のための必要なシンプルなメニューを用いて行います。 シングルプレイヤー、LIVE、またはシステムリンクの選択に始まり、新規セッションの追加、動作中のセッションへの参加などの処理をしています。また、ネットワークに起因するエラーハンドリングの処理も行っているので参考になります。 Network Prediction Sample 上で紹介したクライアント/サーバーとピア・ツー・ピアのサンプルでは1/60秒毎にデータを送っています。これはLAN環境では問題なく動作しますが、インターネットを介して遊ぶ場合には遅延や帯域の問題があります。そこで、このサンプルではピア・ツー・ピアのサンプルを元にしてインターネットを介しても動作するプログラムに改善しています。戦車の動きはパケットロスや遅延があった場合でも滑らかに動くように予測処理がなされています。またLAN環境でもインターネット環境をシミュレートするためにNetworkSession.SimulateLatencyやNetworkSession.SimulatedPacketLossを使っています。 これらのサンプルの他にも英文ですが、Shawn Hargreaves氏のサイトではネットワークゲームに関する有用な投稿が複数あります。 Network Latency Network Packet loss Network bandwidth: packet headers Network bandwidth: voice ひにけにの方でも、これらの投稿を日本語訳(意訳?)していこうと思います。 それ以外にもXNAチームメンバのブログを日本語で紹介して欲しいという要望があればコメント欄でリクエストを受け付けます。

0

XNA 2.0のコンテントパイプライン~その壱~

コンテントプロジェクト XNA 2.0のプロジェクジェクトをソリューションエクスプローラで見ると以下のようになっています。 参照設定の項目が二つあることに気づいたでしょうか?これはContentがWindowsGame1のサブプロジェクトになっているからです。XNA 2.0では、このサブプロジェクト内にコンテントを追加します。その他にも、以前まではメインプロジェクトに記述されていたコンテントに関する情報、例えばコンテントがどのようにインポートされプロセスされるかの情報、カスタマイズされたコンテントパイプラインアセンブリの参照などが含まれます。 以前はWindows、Xbox 360の両対応のゲームを開発している時に、XNA 1.0ではそれぞれのプロジェクトに同じコンテントを追加しないといけませんでした。それだけでもコンテントの管理が面倒だったのですが、XNA 2.0になってプロセッサプロパティ対応になったので、細かいパラメーター設定まで両方のプラットフォームのプロジェクトで設定しないというのは面倒であり、エラーの原因にもなります。 そこで、XNA 2.0ではWindows、Xbox 360の両プラットフォームでコンテント情報を共有するための仕組みとしてできたのがコンテントサブプロジェクトです。 XNA 2.0ではWindowsプロジェクトを作ったときにプロジェクトの右クリックメニューで「Create Copy of Project for Xbox 360…」を選択すると、Windosプロジェクトを元にしてXbox 360用のプロジェクトを作ることができます。この時、両方のプロジェクトにコンテントプロジェクトが存在しますが実際には同じサブプロジェクトを参照しているだけです。 コンテントプロジェクトを共有している訳ですから、Windowsのコンテントプロジェクトにコンテントを追加すると、同じコンテントがXbox 360側のコンテントプロジェクトにも追加されるようになっています。これでWindows、Xbox 360両対応のゲームを作る時の手間が大幅に減ることになります。 コンテントプロジェクトの実体 このコンテントプロジェクト、テンプレートを使ってゲームプロジェクトを作った場合、「プロジェクトフォルダ\Content」フォルダ内にContent.contentprojというファイル名で作られます。 このファイル中身は知らない人には単なるXMLファイルのように見えますが、Visual Studio 2005から採用された新しいビルトツールであるMSBuildのプロジェクトになっています。Visual Studio 2005やVisual C# Express上でビルドした場合、裏ではMSBuildがビルドする仕事を担っています。 実は普段目にしている.csprojファイルもMSBuild用のプロジェクトファイルになっているのでパスの通っている状態でコマンドラインから msbuild.exe myproject.csproj と、タイプするとC#のプロジェクトをビルドすることができます。もちろん、Content.contentprojファイルも単独でビルドすることができます。つまり、コンテントビルドだけを単独で行うことができるわけです。 「コマンドラインなんて普段使わないから、関係ないのでは」と思う人もいるかもしれませんが、この仕組みを利用して以前紹介したコンテントパイプラインのデバッグをする第3の方法に使える訳です。 この方法はVisual Studio 2005上でしか使えませんが、コンテントパイプライン拡張用のプロジェクトのプロパティ画面のデバッグ設定を以下のように変更することでコードに変更を加えることなくデバッグすることができます。 外部プログラムの開始にMSBuild.exeを指定する。(私の環境ではC:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exeとなっていました) コマンドライン引数にデバッグ対象となるContent.cotentprojファイルをフルパスで指定する コンテントパイプライン拡張用のプロジェクトを実行する(右クリック/デバック/新しいインスタンスを開始) これで、カスタムプロセッサのデバッグなどを普通のプロジェクトをデバッグする時と同じようにデバッグすることができます。デバッグ設定は一度設定すれば後は変更する頻度は少ないので、コードを変更する必要のある他の手法に比べるとお手軽かもしれません。 デフォルトではプラットフォームはWindows、Debug状態の設定でビルトが行われます。プラットフォームを変更したい場合はコマンドライン引数でファイル名を指定する前にWindowsならば /p:XnaPlatform=Windows Xbox 360の場合は /p:XnaPlatform=”Xbox 360″ と、指定することで異なるプラットフォームでのコンテントビルドをすることができます。 デバッグ、リリースの変更は /p:BuildConfiguration=Debug または…

0

XNA 2.0でのGraphicsDevice仮想化

消えたデバイスロスト XNA1.0で作ったソースコードをXNA2.0に移植していて最初に気づくのは以下の警告メッセージだと思います。 warning CS0672: Member ‘MyGame.Game1.LoadGraphicsContent(bool)’ overrides obsolete member ‘Microsoft.Xna.Framework.Game.LoadGraphicsContent(bool)’.   結論から書くと、XNA2.0ではグラフィクスリソースの扱いが簡単になり、Windows上で発生するデバイスロスト等の問題を気にする必要が殆ど無なり、新しく追加されたGame.LoadContent内でグラフィクスリソースを簡単に生成できるようになりました。LoadGraphicsContentメソッドもXNA 1.0との互換性を保つために一度だけ呼ばれます。 Texture2D、VertexBuffer、RenderTargetなどの全てのグラフィクスリソースはXNA2.0上では一度生成したら、そのインスタンスは常に有効な状態になります。もちろん、デバイスロストやデバイスリセットが発生するケース、例えばウィンドウのサイズ変更、フルスクリーンへの切り替え、マルチモニタ環境でウィンドウをモニタ間で移動したときでも最初に作ったインスタンスは問題なく使えます。 ただしDirectX 9のドライバモデルの制限上、RenderTargetやDynamicVertexBufferといった動的に内容を書き換えるグラフィクスリソースの中身はデバイスロスト時に破棄されてしまいます。通常、動的に生成されるグラフィクスリソースの多くは毎フレーム毎に生成されるので、その内容が破棄されても次のフレームで生成されるので特別な処理をする必要がありません。フレーム間でその内容を保持しなければいけないグラフィクスリソース、例えばHDRレンダリングで使われるトーンマッピング用の明度テクスチャ、前のフレームの内容を重ねて描くことによるモーションブラーなどの手法を使うときにのみデバイスロスト時に正しい初期値にする必要があります。 まとめると: グラフィクスリソースはGame.LoadContent内で生成する Game.LoadContentが呼び出されるのはプログラム開始時のみ DrawableGameComponent.LoadContentはコンポーネントの初期化時のみに呼ばれる グラフィクスリソースのインスタンスは作り直す必要がなくなった フレーム間でその内容を保持するグラフィクスリソースはデバイスロスト時にその内容が破棄される インスタンス自体はデバイスロスト時でも有効なまま GraphicsDevice.DeviceResetイベント時にSetData<T>等を使って初期値に変更するのみ と、いった感じになります。   XNA 1.0での問題点 XNA1.0ではGameクラスやDrawableComponentクラスにはLoadGraphicsContentとUnloadGraphicsContentメソッドがあり、デバイスリセット時にはUnloadGraphicsContent(flase)、LoadGraphicsContent(false)の順に呼ばれ、デバイスの再構築時にはUnloadGraphicsContent(true)、LoadGraphicsContent(true)の順に呼び出され、その関数の中でグラフィクスリソースの開放と生成をしなければいけませんでした。 ここでの問題はTexture2DやVertexBufferといったインスタンスを生成する必要があるので、ゲーム側のでこれらのオブジェクトを参照している場合、それらの参照を更新する必要がありました。これではゲームが複雑になるに比例してLoadGraphicsContentメソッド内のコードも複雑になるし、予期せぬエラーの原因になってしまいます。 XNA 2.0では、この問題を解決することでグラフィクスリソースの管理が格段に簡単になりました。   どうやってるの? Texture2DやVertexBufferといったマネージクラスは内部でネイティブのリソースを管理しています。XNA 1.0ではデバイスロスト時にマネージクラス自体を破棄する必要がありましたが、XNA 2.0ではマネージクラスは内部でネイティブリソースに対して処理をするようになっています。マネージクラスはテクスチャのサイズやフォーマットといったネイティブリソースの生成情報を保持しているので、ネイティブリソースの再構築が必要なときでも自動的にネイティブリソースを生成しなおすことができます。 また、デバイスの再構築が必要なとき、例えばウィンドウを他のモニタへ移動させた場合、マネージクラスはD3DPOOL_MANAGEDでつくられたリソースの内容を一旦メインメモリに保持してから、ネイティブリソースの再構築、リソースの内容の復元を行うようになっています。   Xbox 360では? Xbox 360上ではデバイスロスト自体発生しないので、上記のようなGraphicsDeviceの仮想化処理は最初からする必要がありません。逆に言えば、XNA 2.0ではXbox 360のようにデバイスロストのない開発しやすい環境をWindos上に持ってきたとも言えます。   参考URL: http://blogs.msdn.com/shawnhar/archive/2007/12/12/virtualizing-the-graphicsdevice-in-xna-game-studio-2-0.aspx

1

XNA Game Studio 2.0がリリース

と、言うわけでXNA Game Studio 2.0がリーリスされました。 以下のリンクからダウンロードできます。 http://www.microsoft.com/downloads/details.aspx?FamilyId=DF80D533-BA87-40B4-ABE2-1EF12EA506B7&displaylang=en インストール時の注意としてはXNA 2.0のベータ版をアンインストールしてからリリース版をインストールしてください。このとき、Games for Windows Live Redistもアンインストールするのを忘れないでください。 その他は GSE 1.0をアンイーストールしなくても 2.0を使える(Side-by-Side) Visual Studio 2005はもちろん、C# Express 2005上でも使える。でもVisual Studio 2008には未対応 GSE 1.0のプロジェクトはProject Upgrade Wizard for XNA Game Studio 2.0で2.0用に更新できる 使い方はこちら(英文) Xbox 360上でXNA 2.0のゲーム開発や遊ぶ為にはXNA Game Studio Connectを使う(要XNAクリエータークラブ会員) Xbox Live、またはGames for Windows Liveを利用したゲームを作るのにも遊ぶのにもLiveゴールド会員であることとXNAクリエータークラブ会員である必要がある といった感じです。 ネットワークゲームの開発環境としてはクリエータークラブ会員である場合はXbox 360とWindowsマシンをLAN接続している環境、つまりXbox 360用ゲームを開発できる環境があればXbox 360、Windows間で遊べるネットワークゲームを作ることができます。 クリエータークラブ会員でなくとも、Windowsマシンを2つ用意してLAN接続することで実現できます。

0

XNA Game Studio 2.0の細かな修正点

Shawn Hargreaves氏のブログから拝借+ちょっと補足説明 XNA Game Studio 2.0になって追加、または修正された細かな機能を紹介します。 GamePadState.IsButtonDownとIsButtonUpメソッドの追加 今まではコントローラーのボタンが押されているかの判定はButtons.A == ButtonState.Pressedと言う様に長いコードを書かなければいけませんでした。特に複数のボタンのいずれかが押されているケースを判定するのには以下のようなコードになってしまいました。// AボタンもBボタンもXボタンも全部ジャンプだ!! if (padState.Buttons.A == ButtonState.Pressed || padState.Buttons.B == ButtonState.Pressed || padState.Buttons.X == ButtonState.Pressed ) Jump(); XNA GS 2.0で追加されたIsButtonDownとIsButtonUpメソッドを使うことによって以下のようにスッキリとしたコードを書くことができます。if ( padState.IsButtonDown(Buttons.A|Buttons.B|Buttons.X) ) Jump();   Keyboard.GetState(PlayeIndex player)オーバーロードの追加 このオーバーロードメソッドを使うことで、Xbox 360コントローラーにつけることのできるチャットパッドからの入力を取得することができます。以前の引数なしのメソッドを呼んだ場合はPlayerIndex.Oneを指定するのと同じ動作をします。   Audio.Cueの再生が途切れてしまう問題の解消 これは、1.0では参照されていないCueのインスタンスがガーベージコレクションが発生した場合、音声の再生の途中に関わらずに破棄されてしまい、その段階で音声が途切れてしまうという不具合がありました。、2.0ではCue.Finalizer内で音声再生中はインスタンスが破棄されないようにすることで解決しています。 この問題は特に3Dオーディオを再生する場合、Cueに対してリスナーとエミッターを関連付けるときに Cue cue = soundBank.GetCue(“fire”); cue.Apply3D( listener, emitter ); のようなコードを書く必要があり、このcueのインスタンスを保持するというのが面倒な作業になっていました。 2.0ではこの問題を解決し、上のように書いた場合でも問題なく動作するようになりました。また、SoundBank.PlayCue(string name, Listener listner, Emitter…

0

XNA Game Studio 2.0ベータ

2007/11/28追記:メールでの解除キー取得はベータ版でのテストのみに必要です。リリース版では解除キー取得の必要はありません XNA Game Studio 2.0のベータ版がリリースされました。日本語での概要はXNA Japan Team Blogに載っています。 最初のリンクは英語ですが、今までXNA GSEを使っていた人、初めて使い始める人のためのセットアップの仕方が載っています。直ぐにダウンロードしたい人は以下のリンクから。 http://www.microsoft.com/downloads/details.aspx?FamilyId=1A096AC7-AEC5-4CD0-9826-1F07EB26EEFD&displaylang=en 基本的にそのままインストールするだけで使えるようになりますが、以下に幾つかの注意点などを書いておきます。 GSE 1.0をアンイーストールしなくても 2.0を使える(Side-by-Side) Visual Studio 2005はもちろん、C# Express 2005上でも使える。でもVisual Studio 2008には未対応 GSE 1.0のプロジェクトはProject Upgrade Wizard for XNA Game Studio 2.0 (Beta)で2.0用に更新できる 使い方はこちら(英文) Xbox 360のプログラムはベータ版では実行できない(ビルドはできる) Windows – LIVEを利用したゲームを作るには解除キーを取得する必要がある(ベータ版のみ) ネットワーク対応のゲームの作り方はNet Rumbleスターターキットが参考になる といった感じです。

3

XNA 2.0のネットワーク機能

XNA TeamブログにXNA GS 2.0におけるネットワークサポートについての投稿がありました。元の投稿では各シナリオについて細かい説明がありますが、ここではできるだけシンプルなルールを書いていこうと思います。 XNA Game Studio 2.0ではネットワーク対応のマルチプレイヤーゲームを作れるような仕組みが提供されます。このネットワークの接続形態はシステムリンクとLive!接続の二つがあります。 システムリンクは、同じサブネット内同士でのマルチプレイヤーゲームを可能にします。一般的なのは同じネットワークハブにPC、Xbox 360を繋げた時に使うことができます。 Live!接続ではXbox 360上ならばXbox Live!、Windows上ならばGames for Windows – LIVEを通す、つまりLive!サーバーを介してのマルチプレイヤーゲームを可能にします。離れた場所からのネットワーク接続を可能にする方法です。 ここで注意しないといけないのはLive接続によってゲームを遊ぶ為にはXbox 360、Windowsの両方ともLiveゴールド会員であることとXNAクリエーターズクラブ会員である必要があるということです。   マルチプレイヤーゲームを遊ぶのに必要なものをまとめると以下の用になっています。   システムリンク Live Windows なし Liveゴールド、XNA CC Xbox 360 XNA CC Liveゴールド、XNA CC 注:XNA CCはXNAクリエーターズクラブの略 WindowsでのLive接続にXNA CCは必要ないのでは?と思ってしまいますが、そこらへんは色々と解決しないといけない問題があるので現状のようになっています。 ともかく、XNA 2.0のベータ版をはもうすぐでますので、より良いものにするためにバグ報告、要望などを言って貰えると有難いです。

0

コンテントパイプラインで使われる型

Shawn Hargreaves氏のブログに、コンテントパイプラインで使われるタイプがどのように使われるかを表した図が記載されています。   図の左側から、ソースアセットからどのインポーターを使ってContent DOM形に変換され、どのプロセッサーがどんな型のデータを出力し、TypeWriterによってXNBファイルに書き込まれ、最後にランタイム時にTypeReaderによってどの型に読み込まれるかというのを網羅しているので、非常に有益な情報です。 何も問題がなければ、この情報は次のXNA Frameworkのドキュメントに記載される予定です。

1