ひにけにXNA : XNA

XNA Game Studio 3.1がリリース

Yuichi Ito — Thu, 11 Jun 2009 20:59:00 GMT

XNA Game Studio 3.1がリリースされました。

http://www.microsoft.com/downloads/details.aspx?FamilyID=80782277-d584-42d2-8024-893fcd9d3e82&displaylang=en

インストール時の注意点

インストールするときの注意として、3.0をアンインストールしてから3.1をインストール必要があります。XNA GS 3.1では3.0、3.1の両方をサポートしているので、3.0で作ったゲームがそのまま遊べますし、3.0で作ったプロジェクトもそのまま読み込むことができます。また、プロジェクトメニューから3.1用のプロジェクトへの更新もできるようになっています。

新機能

XNA GS 3.1では以下の新機能が追加されました。

アバター(Xbox 360のみ)
動画再生
XNBファイルの自動シリアライズ
Xbox Live Party (Xbox 360のみ)

アバターAPIではゲーマープロフィールのアバター情報から、アバターを描画することができ、いくつかの基本的なアニメーションを再生することができます。また、任意のボーンデータを設定することで自分のアバターをゲーム内でキャラクターとして使用することもできます。

動画再生ではWMVファイルをコンテントとして追加することで、ゲーム内で動画再生することが可能となりました。2Dの動画再生にも使えますが、動画フレームはテクスチャデータとして取得できるので3Dモデルに貼り付けて再生することもできます。

今まではXNBファイルに独自のデータ形式を格納するにはそれぞれの型に対応するTypeWriter/TypeReaderを作る必要がありましたが、XNBファイル自動シリアライズ機能を使うことで、TypeWriter/TypeReaderを書かなくても独自のデータ形式を簡単に使えるようになりました。

Xbox Live Party機能、今までは複数の友人をプレイしているゲームに招待する場合に、ユーザーがひとりひとり手動で招待する必要がありましたが、LocalNetworkGamer.SendPartyInvitesメソッドを使うことでプログラム側から複数のパーティーメンバーを一気に招待することができるようになりました。ユーザーがパーティーメンバーであるかどうかを調べるにはSignedInGamer.PartySizeプロパティの内容で判断できます。

次回からは、これらの新機能の詳しく紹介していきます。

ローカライゼーション・サンプル

Yuichi Ito — Mon, 17 Nov 2008 13:59:00 GMT

Creators Club Onlineに以下の３つの新しいサンプルが追加されました。

一気に紹介すると長くなるので、三回に分けてそれぞれのサンプルを紹介していきます。今回はローカライゼーションサンプルについて紹介します。

ローカライゼーション

コミュニティゲームでゲームを投稿する場合、配信地域を選ぶことができます。現状ではアメリカ、カナダ、イギリス、フランス、イタリア、そしてスペインの６カ国で、2009年の前半には日本が加わり７カ国になります。世界の複数の国々の人達に自分の作ったゲームを楽しんで貰うためには必要な作業としてローカライズがあります。そこで、このサンプルではローカライズされた文字列とアセットの使い方のコードが含まれています。

ローカライズされた文字列表示

このサンプルでは言語別のリソースファイル(.resxファイル)を用意し、ゲームクラスコンストラクタの中で実行環境の言語情報を以下のコードのように指定して文字列を変更しています。

Strings.Culture = CultureInfo.CurrentCulture;

SpriteFontDescriptionクラスから派生したLocalizedFontDescriptionクラスに複数のリソースファイルを指定できるようになっていて、ここに各言語の文字列が入ったリソースファイルを指定し、コンテント･パイプライン内でLocalizedFontProcessorによって変換されます。

言語別のリソースファイルは、リソース名.言語コード.resxのようになっています。このサンプルではリソース名がStringsになっていて日本語のリソースファイル名はStrings.ja.resxとなっています。この言語コードはISO 639-1で定義されているアルファベット２文字になっています。

殆どの場合は言語コードを指定するだけで済むのですが、言語コードだけでは足りなくなる場合もあります。例えば、同じ英語でもアメリカの場合はcolorでもイギリスの場合はcolourと違いがあります。その場合は言語コードと国名コードの組み合わせを使います。国名コードはISO 3166-1で定義されているアルファベット２文字を使います。アメリカの英語の場合はen-US、イギリスの英語の場合はen-GBとなります。

この言語コード-国名コードの組み合わせをカルチャ名と呼び、カルチャを表すCultureInfoクラスを生成する時に以下のコードのようにして使用します。

Strings.Culture = new CultureInfo("en-GB");

ローカライズされたアセット読み込み

ローカライズ作業の大半は文章の翻訳になりますが、中にはテクスチャ等のアセット自体をローカライズしたい時があります。このサンプルでは読み込むアセット名を前述のリソースファイル名と同じように、アセット名.カルチャ名の組み合わせであることを前提として使うGetLocalizedAssetNameメソッドがゲームクラスに宣言されていて、国別の国旗テクスチャを変更しています。

以下はコミュニティゲームがサポートする国と言語の表です。

国名	公用語	言語コード	国名コード	カルチャ名
アメリカ	英語	en	US	en-US
カナダ	英語、フランス語	en,fr	CA	en-CA,fr-CA
イギリス	英語	en	GB	en-GB
フランス	フランス語	fr	FR	fr-FR
イタリア	イタリア語	it	IT	it-IT
スペイン	スペイン語	es	ES	es-ES
日本	日本語	ja	JP	ja-JP

特徴として、カナダでは公用語が英語とフランス語の２つの言語が使われていることです。

このサンプルは複数の言語へのローカライズの参考にもなりますが、リソースファイルを使った日本語表示の方法としても参考になるサンプルだと思います。

PIXを活用する　その２

Yuichi Ito — Fri, 07 Nov 2008 07:02:00 GMT

前回に続いてPIXの機能と、私が実際にどんな状況でPIXを使って来たかを交えて紹介します。

ちなみにPIXはピクスと呼びます。たまにピックスと呼ぶ人もいますが私のまわりではピクスが多いです。

RenderウィンドウからDebug This Pixelメニューを使って表示されるDebuggerタブで、前回はDebug VertexやDebug Pixelをクリックしてのシェーダーのデバッグを紹介しましたが、今回はEvent部分をクリックして表示される情報について説明します。

Debuggerタブ内のそれぞれのピクセル情報の上の部分には、そのピクセルを描画したイベントが表示されます。上の場合はDrawIndexedPrimitiveとなっています。ここをクリックすると、左下にあるイベントウィンドウ内で該当するイベントが選択されます。

描画順序のチェック

PIXは描画に関する全てのイベントとその情報を記憶しているので、好きなイベントを選択することで描画の課程を調べることができます。これはVisual Studio上でブレークポイントを設定するといった未来時間一方向へのデバッグに対して、PIXではキャプチャーしたフレーム内での時間を自由に移動できるデバッグをすることができます。

イベントを選択した状態でRenderタブを選択すると、選択されたイベント処理が終わった直後の描画結果、つまりフレーム描画の途中結果を見ることができます。

不透明のオブジェクトを描画する場合、手前から奥にむけて順に描いていくのが効果的なのですが、普通にゲームをプレイしている限りでは描画順序は判らないし、描画コードを追いかけるのにも負担が掛かります。PIXを使うとそういった描画順序をここで簡単に確認できます。例えば、おっさんを描いている途中のこの段階で、遠景によく使われるスカイドームのオブジェクトが既に描画されている場合は、最後に書くべきスカイドームが先に描画されているという問題を発見することができます。

Meshデータの表示

Draw系のイベントを選択した時、Meshタブにはその描画がどの様に行われたかの詳細な情報が表示されます。Meshタブの上の方には三つのワイヤーフレーム画面が表示され、左から順に以下のようになっています。

Pre-Vertex Shader
Post-Vertex Shader
Viewport

Pre-Vertex Shader画面には頂点シェーダーに送られる頂点、通常はローカル座標のモデルが表示されます。Post-Vertex Shader画面には頂点シェーダー処理後、つまり射影座標内でのモデルが表示されます。そして最後は透視変換後のビューポート座標でのモデルが表示されるViewport画面となっています。

そして、それら三つの画面の下には頂点シェーダーに入力頂点のリストを表示するPreVSタブと、頂点シェーダー処理後の頂点リストを表示するPostVSタブがあります。

頂点シェーダーを書いている場合に良くあるのが頂点変換ミスです。この場合、画面に変な形のモデルが表示されている場合は頂点シェーダーに問題があるというのはすぐに判るのですが、画面に何も表示されない場合は頂点変換ミスの他にもピクセルシェーダー内でのミスという場合もあるので、Viewport画面にちゃんと表示されているかを確認することで、頂点シェーダー、ピクセルシェーダーのどちらに問題があるかを絞り込む事ができます。

頂点リスト内の頂点はクリックして選択することができ、選択された頂点は下図の様にモデル表示画面内と頂点リスト内で黄色で表示されます。また、頂点リスト内では選択された頂点が属する三角形の他の頂点が赤色で表示されます。

Deviceのステートの表示

Meshタブ内で頂点シェーダーが正しく動作しているのを確認したけど、まだモデルが表示されない。そんな時に調べるのがDeviceステートです。この情報はEventsウィンドウに表示されているイベントの左側にある数字(下図の黄色い部分)をダブルクリックすることで表示されます。

Detailsウィンドウには新たにDeviceタブが追加表示されます。このDeviceタブの中には更に複数のタブが追加されます。それぞれのタブにはカテゴリ別のDeviceのステート情報が記載されています。

私がここでよく使うのはPixel StateタブとOutput Stateタブです。Pixel Stateタブ内ではCullingやViewport、そしてAlphaテストなどの情報が役に立ちます。特にCullingが逆になっているとモデルがちゃんと表示されないし、Alphaテストに間違った値を設定しているとモデルが全く表示されないということもあります。また、Samplersセクションでは、どんなテクスチャが設定されているかを調べることができます。このSamplers部分で設定されているテクスチャの数字をダブルクリックすると、以下の様に設定されているテクスチャの詳細を見ることができます。

グロスマッピング、ディテールテクスチャといった、描画結果への反映が少ないようなテクスチャや、テクスチャに色以外の情報を入れている場合はここで調べたりしています。

Output Stateタブ内ではデプステストの有無、ブレンディングステートを調べるのに使っています。特にアルファブレンドを使っている場合の見た目では判りづらいステートの違いはここで調べています。

PIXを活用しよう

急ぎ足でしたが、二回に渡ってPIXの機能を紹介しました。2Dゲームと違って3Dの場合は実に様々なステートがあり、2Dゲームの場合はトライ＆エラーでどうにかなった問題も3Dゲームの場合はトライ＆エラーをするには時間が掛かりすぎてしまいます。そういった問題を解決するのにPIXは非常に強力なツールです。シェーダーのサンプルは沢山ありますが、シェーダーサンプル単体では問題なく動いたのにゲームに組み込んでみたら、動かなくなったなんて話を良く聞きます。そんな時にもPIXを使うと、なぜ動かないのかを調べることができます。

また、Xbox 360向けに開発している場合でも、開発しているPCにShader Model 3.0のビデオカードがあれば、Windows用のプロジェクトに変換して実行できるようにしておけば、殆どの場合は描画に関するデバッグは問題なくできます。そのままデバッグできない例としてはXbox 360限定のvfetchを使った場合ですが、vfetchはあくまで頂点データのフェッチ用の命令なので、シェーダー全体のコード量に比べると非常に小さく、頂点データをフェッチした後のシェーダーはWindows上でもデバッグできます。

私は、初代Xboxの頃からPIXを使って７年くらい経ちますが、今では描画に問題があったらすぐにPIXを立ち上げて調査するというのが習慣化していて、私にとってPIXはゲーム開発に必須のツールとなっています。

綺麗な絵を出すシェーダープログラミングに比べると地味なものですが、これを機にPIXに触れてもらえば幸いです。

PIXを活用する　その１

Yuichi Ito — Thu, 30 Oct 2008 05:06:00 GMT

PIXとは

3Dゲームを開発している時に必ずといってあるのが、モデルが意図しない状態で表示されるという問題です。「色が変」や「形が変」と言う比較的原因が予想しやすい問題から「画面になにも出ない」といった原因を判断するのが困難な場合まで様々な問題があります。特にシェーダープログラムを使っているとこういった問題に直面する機会は多くなります。

こういった問題の原因を見つけるのに非常に有用なツールとして、Direct X SDKに付属するPIX for Windowsがあります。このツールは元々、初代Xbox用に開発されたPerformance Investigator for Xbox (PIX)だったのですが、これを使った人達からの強い要望でWindows版が作られました。

XNA FrameworkはDirect X上で動作しているので、XNA GS用に作られたゲームもPIX for Windowsを使うことができます。

PIXの主な機能としては

１フレーム、もしくは複数のフレームのレンダリング情報のキャプチャ
レンダリングに使われたDirect Xの描画関連命令の表示
リソース使用量の表示
各段階でのグラフィクスリソースの状態表示
- レンダーステート
- テクスチャ、レンダーターゲット
- 頂点情報
- シェーダー情報
シェーダーデバッガ

があります。

PIXの基本的な使い方

Direct X SDKをインストールした状態で(ここではAugust 2008を例にします)、スタートメニューからMicrosoft DirectX SDK (August 2008)/DirectX Utilities/PIX for Windowsを選択してPIX for Windowsを起動します。

FileメニューからNew Experimentを選択すると以下の画面が表示されます。

Program pathに対象となる実行ファイルを指定し、"A single-frame capture of Direct3D whenever F12 is pressed"のラジオボタンを選択して、右下にある"Start Experiment"ボタンを押すと、Program pathに指定した実行ファイルが実行されます。ここではSkinningSampleを使っています。

単独で実行させるのと違うのは、画面の左上にフレーム数などの情報が表示されています。キャプチャしたいシーンになったらF12キーを押してフレーム情報をキャプチャします。レンダリングするシーンの複雑さによってキャプチャに掛かる時間は変わってきます。

キャプチャした後にゲームを終了させると、PIX for Windowsに複数のウィンドウが表示されます。

この複数のウィンドウは上から順にCPUの作業時間をグラフで示すTimelineウィンドウ、グラフィクスリソース確保状況を表示するObjectsウィンドウ、左下はキャプチャしたフレーム内で起きたイベントを表示するEventsウィンドウ、そして右下が詳細を表示するDetailsウィンドウとなっています。

ここで、Eventsウィンドウで調べたいフレームを選択したあとに、Detailsウィンドウ内のRenderタブをクリックすると以下の画面になります。

PIXをシェーダーデバッガとして使う

このRenderタブにはフレームのレンダリング結果が表示されます。また、Eventsウィンドウの選択したフレームを開くと中には複数のイベントが表示されていますが、ここにはXNA Frameworkではなく、Direct Xのイベントが表示されます。ここからデバッグしたいDrawIndexedPrimitiveメソッドを探し出すのは面倒なので、今回は簡単な方法を紹介します。

それはRenderタブに表示されている画面上でデバッグしたいモデルの場所で右クリックして表示されるメニューからDebug This Pixel...を選択する方法です。ここでは、おっさんのアーマー部分を選択しました。

Debug This Pixel...を選択すると、DetailsウィンドウにDebuggerタブが追加され、選択したピクセルがどのようにレンダリングされたいるかの情報が表示されます。レンダリング開始時のフレームバッファーの色、クリアーした時の色、モデルをレンダリングしたときの色と、時系列に表示されています。もし、ここで表示されるリストが多い場合は重ね塗りが何度も起こっているのでフィルレートに影響しているということが判ります。

今回デバッグしたいのはおっさんのアーマー部分のシェーダーなので、リストの中からDrawIndexedPrimitiveメソッドを使って赤っぽくなっているピクセルを探します。

DrawIndexedPrimitiveを使っているピクセルでは、そのピクセルを描画するのに使われた三角形の各頂点の頂点シェーダー、そしてピクセルシェーダーをデバッグすることができます。ここでは"Debug Vertex 0"をクリックして頂点シェーダーのデバッグをすることにします。"Debug Vertex 0"をクリックすると以下のように、Debuggerタブ内に更にシェーダーアセンブリを表示するDisassemblyタブ、ソーソコードを表示するタブ(ここではSkinnedModel.fx)が表示されます。

ここで、ソースコードをPIX上で表示するにはシェーダーソースコードにコンパイル元のファイル情報が記載されている必要があります。XNA Frameworkではデバッグ設定でシェーダーをコンパイルすると、この情報を自動的に追加するようになっているので、プロジェクトをデバッグ設定でコンパイルすることでPIX上でソースコードレベルでのデバッグができるようになっています。逆に言えば、アセンブリしか表示されない場合はプロジェクトのコンパイル設定がリリースになっているのが原因と思われます。

Visual Studio上で提供されているデバッグ機能には及ばないにしても、ステップ実行や実行後の変数の状態表示など、デバッグするのに必要最低限の機能はあるので、シェーダーコードのデバッグをするのに大いに役立ちます。

PIXをシェーダーデバッガとして使うときの注意点

ソースコードレベルでのデバッグをするときには、プロジェクトをデバッグ設定でコンパイルする

次回に続く

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

Yuichi Ito — Fri, 21 Dec 2007 04:32:00 GMT

コンテントプロジェクト

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

または

/p:BuildConfiguration=Release

と、することで変更することができます。

XNA Game Studio 2.0がリリース

Yuichi Ito — Fri, 14 Dec 2007 04:23:00 GMT

と、言うわけで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接続することで実現できます。

XNA Game Studio 2.0の細かな修正点

Yuichi Ito — Thu, 29 Nov 2007 04:16:00 GMT

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 emitter)メソッドが追加されたので、簡単に3Dオーディオをサポートした効果音を再生することができます。

フレームワーク内での不要なメモリ確保の削除

不要なメモリ確保をすることはガーベージコレクションの頻繁な発生につながり、結果的にパフォーマンス低下に繋がります。特に世代別GCを実装していないXbox 360上では大きな問題になります。

2.0ではフレームワーク内で不必要なメモリ確保している部分の修正をしました。

簡単なところではGamePad.GetState、SpriteBatch.DrawStringメソッド内でメモリ確保しないようになりました。SpriteBatch.DrawString内では、Dictionary<K,T>を使って実装していたのですが、キーがバリュータイプだと不要なメモリ確保がXbox 360上で発生することがありました。興味深いのはデバッガ使用時と、未使用時でJITが生成するコードに違いがあり、デバッガ上で実行させるとボクシングが発生することがあります。ですから、GCの発生の有無を調べる場合はF5ではなく、Ctrl+F5で実行することをお勧めします。

ModelMeshCollection、ModelMeshPartCollection、ModelEffectCollection、そしてModelBoneCollectionクラスのGetEnumeratorメソッドの実装がIEnumeratorを返す代わりに、Enumerator構造体を返すように実装されました。

これはモデルを描画するのによく使われるパターンとして

    foreach (ModelMesh mesh in model.Meshes)
    {
        foreach (Effect effect in mesh.Effects)
        {
            BasicEffect be = effect as BasicEffect;
            if (be != null)
            {
                be.Projection = proj;
                be.View = view;
            }
        }
        mesh.Draw();
    }

のようにforeachを多用します。この時、コレクションがIEnumeratorを返すと暗黙的なメモリ確保が発生してしまいます。
せっかく便利なforeach文なのに、GCを避けるためにわざわざfor文に書き換える必要がありましたが、2.0ではforeachを使ってもメモリ確保は発生しません。

SpriteFontのカーニングサポート

カーニング(Kerning)とは、英数字でWAITのような文字を表示したときに全体の見た目のバランスを取るためにAとWの間を意図的に狭めるような処理のことです。これはspritefontファイル内に<UseKerning>ture</UseKerning>を指定することで設定できます。spritefontファイルで何も指定しない場合はカーニング処理をしないので、1.0で作ったファイルをカーニングさせるのにはUseKerningエレメントを追加してSpacingの値を0することをお勧めします。

XNA Game Studio 2.0ベータ

Yuichi Ito — Tue, 20 Nov 2007 22:58:00 GMT

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スターターキットが参考になる

といった感じです。

XNA 2.0のネットワーク機能

Yuichi Ito — Mon, 19 Nov 2007 23:41:00 GMT

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のベータ版をはもうすぐでますので、より良いものにするためにバグ報告、要望などを言って貰えると有難いです。

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

Yuichi Ito — Wed, 10 Oct 2007 21:31:00 GMT

Shawn Hargreaves氏のブログに、コンテントパイプラインで使われるタイプがどのように使われるかを表した図が記載されています。

図の左側から、ソースアセットからどのインポーターを使ってContent DOM形に変換され、どのプロセッサーがどんな型のデータを出力し、TypeWriterによってXNBファイルに書き込まれ、最後にランタイム時にTypeReaderによってどの型に読み込まれるかというのを網羅しているので、非常に有益な情報です。

何も問題がなければ、この情報は次のXNA Frameworkのドキュメントに記載される予定です。

クリエーターズクラブオンライン更新　07年9月号

Yuichi Ito — Sat, 29 Sep 2007 04:38:00 GMT

クリエーターズクラブオンラインのサイトが更新されました。先月はGameFestの開催と重なったので数が少なかったのですが、今月は4つのサンプル、3つのユーティリティ、そして1つのアーティクルが追加されました。そんな訳で例によって例の如く私なりに紹介させて頂きます。

Collision Series 4: Collision with a Heightmap

このサンプルはコンテントパイプライン上でビットマップイメージから生成されたハイトマップ上での衝突判定をするサンプルコードです。コリジョン判定自体は単に指定した座標の高さを取得するシンプルなものですが、カメラも衝突判定を使っているのでカメラが地面にめり込んでしまうという不具合を回避しています。

Custom Model Class

このサンプルでは、ランタイム時に独自フォーマットのモデルデータを扱う為に、コンテントパイプラインのDOMに格納されたモデルデータの取得、カスタムコンテントの作り方、そしてランタイム時のデータの読み込みとモデル描画のコードが含まれています。自分なりの独自フォーマットデータを作るときの雛形として有用なサンプルです。

Mesh Instancing

通常、複数のモデルを描画するにはDrawPrimitive等のメソッドを複数回呼びますが、描画するモデルの数が大量に増えた場合、GPUが実際に描画するよりもDrawPrimitiveの呼び出し自体に掛かるオーバーヘッドの方が大きくなる場合があります。

この問題を解決する為にWindows上ではモデルインスタンスと呼ばれる手法が使われます。このサンプルでは同じモデルを複数の行列で示される位置に描画するようになっています。私のPC環境ではモデルインスタンス使用時と、インスタンス無しステートバッチング無しの状態と比較すると8倍程のフレームレート差がでています。

Xbox 360上ではvfetchと呼ばれるシェーダーのインラインアセンブラを使って実現しています。

Shatter

このサンプルでは任意のモデルに使われている三角形ポリゴンをひとつずつアニメーションさせることで、モデルがバラバラになっていく視覚効果をだしています。

コンテントパイプライン内で指定されたモデルを独立した三角形ポリゴンのモデルデータに変換し、必要なパラメータを追加しています。ランタイム時は頂点シェーダー内で指定された時間によって三角形の位置や回転状態を計算しているので時間の逆再生などもできるようになっており、CPUリソースを使わないという利点もあります。

Curve Editor

XNAフレームワークにはHermiteベースの一次曲線を使うためのCurveクラスがあります。このクラスの使い道として代表的なのはPosition値を時間として扱うアニメーションカーブで、モデルのアニメーションに使われるのはもちろん、例えばゲーム内の時間によって太陽の位置やフォグ等のパラメーターを変化させたりするときに使います。

簡単な曲線や直線の場合はプログラムで直接書くだけで済みますが、複雑になってくると欲しくなってくるのがエディタです。

このユーティリティには単体で動作するCurveEditorがあり、このエディタ内では以下の機能があります。

複数カーブの同時編集
タンジェント値の自動計算
タンジェント値の視覚的編集
コンテントパイプラインでそのまま使えるXMLファイルへのCurveの読み書き
任意のキーのPositionとValueを直接編集できるテキストボックス
Undo/Redoサポート

また、CurveEditorが使っているCurveControlは使い回しができるユーザーコントロールとして設計してあるので、自分で作ったゲームエディタ内で使ったり、デバッグビジュアライザーを作る時に便利です。

Input Reporter

このユーティリティーではXbox 360コントローラーの入力情報をリアルタイムに見ることができます。振動モーターの有無や複数のコントローラーの接続状態も右上のアイコンで表示されるようになっています。

基本的にXbox 360用の入力機器は標準コントローラーとしても使えるようになっています。ですから、ダンスパッドやギターコントローラーを繋げた時に、標準コントローラーのどのボタンやキーに割り当てられているかを調べる時に便利なユーティリティではないでしょうか？

Xbox 360 Controller Button Glyphs

とか等のXbox 360コントローラーのボタンのイメージがTGA形式で入っています。また、SpriteFont用にXboxControllerSpriteFont.tgaも予め用意されているので、ゲームの「Aボタンを押してください」等のメッセージテキスト中のAの部分を実際のコントローラーのイメージにしたりする時に便利です。

Ship Game Article - 3D Collision using the BoxCollider library

このアーティクルは、先月追加されたShip Gameで使っている衝突判定用のライブラリ「BoxColider」を自分で作ったゲームで使うための方法が書いてあります。このライブラリではOctreeベースの衝突判定、および衝突した場合にどこまで移動することができたかという情報も取得できるようになっているので、ゲームで使うときに便利です。

フィードバックを反映した更新

これらの更新の中には、クリエーターズクラブ内のフォーラムに寄せられた意見を元にしたものがあります。但し英語のみなので日本からのフィードバックはMSDNフォーラムに気軽に「こんなサンプルが欲しい」といった投稿をして貰えれば、できるだけクリエーターズクラブの更新の方にも反映するようにします。

XNA Game Studio 2.0

Yuichi Ito — Wed, 15 Aug 2007 06:38:30 GMT

GameFest 2007でXNA Game Studio 2.0のアナウンスがありました。XNAチームブログに詳細がありますが、ここでは個人的な意見(つっこみ？)を交えて説明してみたいと思います。

XNA Game Studioの新機能

全てのバージョンのVS 2005で動作するようになる

これで仕事でVS2005にはあるけど、XNA GSEでは使えなかった、マルチスレッドのデバッグや、デバッグ時に自動的にローカル変数を表示してくれたり、更に個人的に外せないはキーボードマクロとか使えるようになります。

Xbox 360との接続するための手続きが簡単になった

ノーコメント

コンテントビルドが使いやすくなる

ノーコメント

コンテントパイプライン用のプロジェクトテンプレートを追加

コンテントパイプラインの拡張コードを書くときには色々と煩雑な手続き多かったので、これでカスタマイズするのが楽になるかも？

コンテントプロセッサーにカスタムパラメーターを追加することができるようになる

現バージョンでは、複数のテクスチャ処理用のプロセッサーがありましたが、これをひとつのプロセッサとしてパラメーターによって処理方法を変えるといったことができるようになります。また、今まではちょっとしたパラメーターでもXMLファイルから読み込むコードを書く必要がありましたが、カスタムパラメーターの導入で簡単になります。

XNA Frameworkの新機能

Xbox Live!のサポート

Xbox Live!を通しての、Xbox 360間はもちろん、Xbox 360とWindows間で動作するネットワークゲームを作るのに必要な機能があります
機能的にはロビーへの参加、セッションの生成、ゲーム中のデータパケットのやりとりなどを簡単にできるようになっています。
System Linkもサポートしているので、Xbox Live!を介さないでLAN上でも動作します。

新しいXACTエディター

DirectX SDKに付属しているのがアープデートされてるので、追いつかないとねいけませんしね(笑)

Windows Form上で動作するようになった

これでレベルエディターとか、非ゲームアプリも手軽に作れるようになります。

GraphicsDeviceの仮想化

デバイスのリセットや再生成を意識せずに使えるようになります。
新しく追加されたGame.LoadContentメソッド内でデバイスがリセット時か生成時か気にしなくて良いのはもちろん、グラフィクス、非グラフィクスのリソースかを気にしなくてもよくなります。

Windows、Xbox 360間でのRenderTargetの振舞いの統一化と、Xbox 360上でのMRT(Multiple Render Target)のサポート

ポストプロセス系の処理、特にブルームとかの処理をしているとWindowsとXbox 360上での振舞いの違いを考慮しないといけないのでプログラムが煩雑になってしまうという問題を解決します。

GameComponentを階層構造にするのが簡単になる

ゲームを作るときに、タイトル画面、メニュー画面、ゲーム画面といった数種類の画面を行き来する必要があるのですが、この時にそれぞれの画面をGameComponentとして使い、その中で更に複数のGameComponentを扱うようにすると各画面の管理が簡単になります。現バージョンではGameComponentCollectionが、このシナリオを想定していない作りになっているので実現するのが難しかったという問題を解決します。

と、いった感じです。リリース時期は年末を目指していて、リリース時期が近づくにしたがった更に詳細な情報がリリースされます。

Content Pipeline その４そのデバッグ

Yuichi Ito — Tue, 08 May 2007 07:10:00 GMT

コンテント・パイプラインのデバッグ

前回は、実際のコードを見ながらコンテント・パイプラインのカスタマイズの方法を紹介しました。前回のように、ロジック自体が簡単な場合は良いのですが、もう少し複雑なプログラムをコーディングしている時に必要になるのが、インポーターやプロセッサのコードをデバッグすることです。

ここで問題なのは、ゲーム本体をデバッグする感覚でブレークポイントをコンテント・パイプラインのコード部分に設定してビルドしたとしても、何事も無かったかのようにビルトが終了してしまうということです。コンテント・ビルドは普通にアプリケーションを走らせるのと違い、GSEが水面下でMSBuildを実行しているので、GSE上で走らせるアプリケーション用のブレークポイントを設定しても意味がないからです。

コンテント・パイプライン用に書いたコードをデバッグする方法としては、JIT(Just-In-Time)デバッガをつかう方法とCLRデバッガをアタッチする二種類の方法があります。

JITデバッガを使う

Visual Studio 2005をインストールしているか、.Net Framework 2.0 SDK(無償)をインストールしたときに使えるようになるCLRデバッガがあるWindows XP環境なら、コード部分に

    System.Diagnostics.Debugger.Launch();

と、書くことで、ビルド実行時に以下のようなJITデバッガ選択ダイアログが開きます。

このダイアログから、CLRデバッガ、またはVisual Studio 2005をデバッガとして起動することで、コンテント・パイプライン用コードのデバッグができます。

CLRデバッガをアタッチして使う

残念ながら、現状では、前述のJITデバッガ機能はWindows Vista上では動作しません。そこでWindows Vista上でコンテント・パイプラインをデバッグするにはCLRデバッガ(Visual Studio 2005でも可)をVisual Studio C# Expressにアタッチしてデバッグする方法を紹介します。CLRデバッガは、.Net Framework 2.0 SDK(無償)をインストールすることで使えます。

まずは、以下のコードのように、デバッガがアタッチしている時にのみ中断するようにします。

    if (System.Diagnostics.Debugger.IsAttached)
        System.Diagnostics.Debugger.Break();

次にVisual Studio C# Expressを実行した状態で、CLRデバッガ(スタートメニューから、Microsoft .Net Framework SDK v2.0/Tools/Microsoft CLR Debuggerを選択)を別に実行し、CLRデバッガ上で「Tools/プロセスにアタッチ」を選択すると以下のようなダイアログボックスが開きます。

この選択可能なプロセスのリストの中から、VCSExpress.exeを選択してから、アタッチボタンを押します。これで、CLRデバッガがVisual Studio C# Expressをデバッグしている状態になります。

この状態で、Visual Studio C# Express上でビルドを実行すると、先に書いたコード部分で実行が中断し、後はCLRデバッガ上でVisual Stuidio C# Express上と同じようにデバッグができます。実行中断したときに逆アセンブルが表示されいる場合がありますが、逆アセンブルウィンドウ上から右クリックして「ソースコードへ移動」を選択することで、C#のソースコードが表示されます。

また、デバッグした後にCLRデバッガ上で続行を選択すると、ビルド作業が続行されるので、一度アタッチしてしまえば何度でも簡単にデバッグすることができます。但し、インクリメンタルビルドが働いているので、単にビルドを複数回実行すると二回目以降は実際にビルド作業が入らないのでデバッグすることができません。コンテントの量が少ない場合はリビルドし、コンテントの量が多い場合はデバッグしたいコンテントファイルを更新してからビルドするのが効率的です。

まとめ

今までは、私もJITデバッガを使っていたのですが、この方法だと常にデバッガを起動しようとするので、急いでいるときにコンテント・パイプラインのデバッグを終えてコードを戻すのを忘れて、他人にコードを渡してしまうなんてことも考えられます。それに対して、CLRデバッガをアタッチする手間はあるものの、逆に言えばデバッガをアタッチしない限りは、普通に動作するのでJITデバッガを使うときの問題は起きませんし、特定の例外が発生したときに中断するようにCLRデバッガ上から設定(Debug/例外メニューを使う)できるという利点があります。欠点を強いていうなら、中断するコードを大量に残したままに…なんてことがあるくらいでしょうか？

以上をまとめると、

Windows Vista上で開発してる場合はCLRデバッガ(Visual Studio 2005でも可)をアタッチして使う
Windows XP上で開発している場合は好みによって使い分ける

と、いった感じになります。

プログラムが思い通りに動かない時にデバッガを使うことで、問題点を直ぐに見つけることができることが多いので、カスタムインポーターや、カスタムプロセッサが期待通りに動かない時には、今回の方法でデバッグして効率的に問題を解決しましょう。

クリエーターズクラブも更新

Yuichi Ito — Fri, 27 Apr 2007 04:52:00 GMT

http://creators.xna.comに新しいコンテントが増えました。

スターターキットとして、新たにRacing Gameが追加されました。これは以前からXNAレーサーと呼ばれていたゲームです。もちろん、スターターキットなのでフルソースコード、フルコンテント付です。

また、新しいサンプルプログラムとして以下のものが追加されました。

Bloom

ポストプロセスの代表的手法の一つである、眩しい光などが滲む、ブルームのサンプルです。

プリミティブ描画

Spacewarで使われていた、VectorShapeクラスを元にしたPrimitiveBatchを使ったサンプルです。このクラスを使うことで簡単に点、線分、三角形などを画面に描画することができます。

Game State Management

ゲームを作る上で必ずといって必要だけど、作るのが面倒なメニュー画面。このサンプルでは、複数のメニュー画面の切り替え簡単にするための仕組みを提供しています。

3D Audio

GSE 1.0 RefreshでサポートされたXACT 3Dの使い方のサンプルです。

2Dパーティクル

SpriteBatchを使った2Dベースのパーティクルシステムのサンプルです。

シェーダーシリーズ 1:頂点ライティング

シェーダーの基本である、頂点ライティングのサンプルです。

また、ユーティリティとして以下のものが追加されました。

Bitmap Font Marker Utility

WindowsのTrueTypeフォントから、.bmpファイルを生成するツールです。ここで生成された画像をFontTextureProcessorを使って、SpriteFontとして使えます。変換された画像を加工することで、影付の文字にしたり、文字列の中にコントローラーのボタンイメージを表示したりといった事に使うことができます。

Xbox360 コントローラーグラフィクス

ゲームの操作方法を説明したりするときに使えるXbox360のゲームコントローラーのイメージファイルがあります。

その他にもアーティクルや、チュートリアルビデオにも有用な情報が追加されているのですが、全て英語なので読みづらいと思います。チュートリアルビデオに追加されたXACTツールを使っての、サウンドエフェクトの音量やピッチを変更する方法や、3Dオーディオの使い方などは映像を見るだけでも、なんとなく判るかも？

GSE 1.0 Refresh API その詳細

Yuichi Ito — Fri, 27 Apr 2007 03:39:00 GMT

GSE 1.0 Refreshは1.0とバイナリ互換、つまり1.0でコンパイルしたものが、そのまま1.0 Refreshで動作するようになっているので、1.0のAPIはそのままで、新しいAPIが追加されています。

ここにRefreshで追加されてAPIのリストがあります。今まで概要は説明してきましたが、詳細は省いていたので、以下に追加されたAPIの詳細を書きます。

Math関連

BoundingBoxとBoundingFrustumのGetCornersメソッドを追加。Cornersプロパティと違って予め確保した配列を指定できるので、GC発生率を抑えることができます。
Curveクラスにタンジェントを計算するComputeTangentとComputeTangentsメソッドを追加。現在のCurveKeyの状態でCurveTangentで指定したタンジェントを計算します。例えば、CurveTangent.Smoothを指定することで、滑らかに繋がった曲線になるようにタンジェントを計算します。
MatrixとQuaternionにCreateFromYawPitchRollメソッドを追加。ヨー、ピッチ、ロールの角度を指定することで、回転行列やクォータニオンを生成します。
Matrix.CreateReflection。指定したPlaneの位置でオブジェクトを鏡で反射させた場所に移動させる行列を生成します。水面や鏡の反射されたものの描画に使えます。
Matrix.CreateShadow。オブジェクトを指定したPlaneとライト方向によって、射影行列を生成します。平面への投射しかできませんが、簡単な影の描画に使えます。
Matrix.Decompose。行列をスケール、回転、移動の三つの要素を取り出します。指定する行列はスケール、回転、そして移動の順で組み合わされたいう前提があります。
Matrix.Transformメソッド。指定した行列を、指定されたクォータニオンで回転させます。
Vector2、Vector3、Vector4のTransform、TransformNormalメソッドで配列が指定できるようになった。
Vector2、Vector3、Vector4のTransform、TransformNormalメソッドでQuaternionが指定できるようになった。
RayとPlaneの交差判定、Ray.Intersectsメソッド追加。線の始点と面の距離を返します。
RectangleとPoint、Rectangle同士の交差、包括判定、Contains、Intersectsメソッドの追加。

グラフィクス

文字描画の為のSpriteFontクラスの追加。文字列を描画したときの領域を計算するMeasureStringメソッドなどがあります。実際の描画はSpriteBatch.DrawStringを使います。
SpriteBatch.BeginでMatrixを指定できるようになった。画面分割などのゲームを作るとき等、Drawメソッドを呼ぶときに自前で移動させたり、スケールさせたりする計算をする手間が省けます。
BasicEffect.PreferPerPixelLightingプロパティの追加。このプロパティにtrueにすることで、ピクセル単位のライティングを使用するようにします。ピクセル単位のライティングにはシェーダーモデル2.0以上のビデオカードが必要ですが、BasicEffectはそれを自動判別するので気軽に使えます。
GraphicsDeviceで、Vector2、Vector3、Vector4、Quaternion、そしてMatrixといった構造体をピクセル/頂点シェーダーの定数レジスタに直接設定できるようになりました。

オーディオ

XACT 3Dオーディオサポートの為に、AudioEmitter、AudioListenerといったクラスが追加されています。3Dオーディオは5.1chスピーカーで、後ろの方から音が聞こえてきたりするのはもちろん、救急車が目の前を走り去るときに起こるドップラー効果もサポートしています。ここにサンプルコードがあります(ねこの泣き声のドップラー効果つき)。

コンテント・パイプライン

SpriteFontをサポートするためのFontDescriptionやFontDescriptionProcessorの追加。
任意の画像、例えばコントローラーのボタンイメージをSpriteFontとして使う為のFontTextureProcessorの追加。
3DテクスチャをサポートするためのTexture3DContentの追加。
外部のコンテントを参照するときに使える、ExternalReference<T>クラスの追加。
コンテントクリーンビルドのためのMSBuild用のタスク、CleanContentの追加。

この殆どの機能は、フィードバックを元に追加されています。特にMath関連の追加機能は全てフィードバックを元にしたものです。逆に言えば、フィードバックさえすれば、その機能が次のリリースに反映される可能性が非常に高いということです。日本語の報告もMicrosoft Connectにできるようになったので、沢山のフィードバックをお待ちしております。