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

XNA Game Studio 4.0がリリースされました。前述のとおり、XNA Game Studio 4.0はWindows Phone Developer Toolsに含まれる形でリリースされました。 Windows Phone Developer Toolsのダウンロード リリースノート CTP版やベータ版のWindows Phone Developer Toolsをインストールしている場合はリリース版をインストールする前に以前のバージョンをアンインストールする必要があります。 Windows Phone Developer ToolsにはVisual Studio Express for Windows Phoneが含まれるのでVisual Studioがインストールされていない状態でもWindows Phone Toolsをインストールすることができます。 Visual Studio 2010 Professional以上がインストールされている場合は、お使いのVisual Studio上で開発をすることができます。 Windows Phone Developer ToolsはWindows VistaとWindows 7のみのサポートとなっています。Windows XP向けにはXNA Game Studio 4.0のスタンドアロン版をダウンロードできます。 Windows Phone Developer Toolsには以下のものが含まれます。 Visual Studio 2010 Express for…

0

XNA Game Studio 4.0、グラフィクスAPI・リファクタリング

XNA Frameworkの歴史 XNAチームは発足当初から他のMicrosoftのプロダクトチームに比べると非常に少ない人数です。人数的に見て他のチームがXNAチームの10倍の規模なんていうのは普通にあることで、時には100倍の人数規模のチームと仕事をするなんてこともあります。 私達がXNA Game Studio 1.0の時にFrameworkを設計したときにはXbox 360上で.Net CFを動くようになったのは最初のリリースの四ケ月程前でした。もちろん、たった四ケ月という期間と少ない人員でFrameworkの設計、実装、そしてテストをすることはできないので、Xbox 360上で.Net CFが動くまでの間に平行して他の作業を進めました。 この時点で私達が設計、実装ができたのはWindows上のみだったので、自然とManaged DirectXの設計を参考にする機会が多くなり、どちらかというとDirectX 9.0のラッパーのようなものが多くなりました。 この方針は設計期間を短くすることに繋がったのですが、後になってXbox 360とWindows上の動作に違い、例えばRenderTarget2Dの振る舞いの違いなどがあることに気づいた時には既にAPIの仕様を変更するには遅すぎる時期になってしまい、結局はXbox 360とWindowsの動作の違いはそのままにすることになってしまいました。 また、追加してしまつた機能を削除するのは、新しく機能を追加するよりも遥かに難しいということを実感したのもXNA Game Studio Express 1.0をリリースした後になってからでした。 一度追加してしまった機能は、使用頻度が少なくとも削ってしまうと、それまで動作していたゲームが動かないということになってしまいます。この使用頻度が低いAPIというのが厄介で、いかに使用頻度が低くてもAPIとして提供している以上はそのAPIが動作しているかどうか確認するためのテストをする必要があります。そして、前述のように人員の少ないXNAチームでは、このテストに掛かる時間が多くなってしまい、そのことで新機能を追加する時間が少なくなってしまうというのは問題です。 将来を見越したリファクタリング XNA Game Studio 4.0でWindows Phone 7シリーズへの対応が決まった時、私達はこれがリファクタリングをするにはいい機会だと考えました。 特にグラフィクスに関しては今までスマートフォーン向けのGPU用のDirectXドライバは存在せず、ドライバの設計はもちろん、ハードウェアベンダーとの話し合いからすることができた(しなければいけなかった)ので、XNAチーム側からの意見の多くが採用されました。 ここで私達は今まで経験から、できるだけ長い間使えるAPIになるようにDirectX10 APIを元にしたAPIへとリファクタリングをすることにしました。と、言うと「ジオメトリシェーダーが使える!」と、考える人がいると思いますが、残念ですがXNA Game Studio 4.0の段階でDirectX 10特有の機能はサポートしていません。 XNA Game Studio 4.0ではDirectX 9世代のGPUもサポートしているので、DirectX 10 APIをDirectX 9世代のGPU上で使用する、D3D10Level9と同等のことをしています。 XNA Game Studio 4.0のグラフィクスではこの他にも以下のようなリファクタリングが施されています。 Capsメカニズムの廃止、Reach、HiDefのシンプルなフィーチャーレベルの採用 RenderStateを廃止し、BlendState、SampleState、DepthStencilState、そしてRasterizerStateとして分別 RenderTarget2DをTexture2Dから派生したクラスにし、深度バッファとの統合 アルファテスト関連のステートの廃止(代わりにAlpheTestEffectを使用) トライアングルファン・プリミティブの廃止 ポイント・スプライトの廃止…

0

XNA Game Studio 3.1がリリース

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プロパティの内容で判断できます。 次回からは、これらの新機能の詳しく紹介していきます。

0

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

Creators Club Onlineに以下の3つの新しいサンプルが追加されました。 ローカライゼーション サンプル(Localization) セーフエリア サンプル(Safe Area) 招待 サンプル(Invites) 一気に紹介すると長くなるので、三回に分けてそれぞれのサンプルを紹介していきます。今回はローカライゼーション サンプルについて紹介します。 ローカライゼーション コミュニティゲームでゲームを投稿する場合、配信地域を選ぶことができます。現状ではアメリカ、カナダ、イギリス、フランス、イタリア、そしてスペインの6カ国で、2009年の前半には日本が加わり7カ国になります。世界の複数の国々の人達に自分の作ったゲームを楽しんで貰うためには必要な作業としてローカライズがあります。そこで、このサンプルではローカライズされた文字列とアセットの使い方のコードが含まれています。 ローカライズされた文字列表示 このサンプルでは言語別のリソースファイル(.resxファイル)を用意し、ゲームクラスコンストラクタの中で実行環境の言語情報を以下のコードのように指定して文字列を変更しています。Strings.Culture = CultureInfo.CurrentCulture; SpriteFontDescriptionクラスから派生したLocalizedFontDescriptionクラスに複数のリソースファイルを指定できるようになっていて、ここに各言語の文字列が入ったリソースファイルを指定し、コンテント・パイプライン内でLocalizedFontProcessorによって変換されます。 言語別のリソースファイルは、リソース名.言語コード.resxのようになっています。このサンプルではリソース名がStringsになっていて日本語のリソースファイル名はStrings.ja.resxとなっています。この言語コードはISO 639-1で定義されているアルファベット2文字になっています。 殆どの場合は言語コードを指定するだけで済むのですが、言語コードだけでは足りなくなる場合もあります。例えば、同じ英語でもアメリカの場合はcolorでもイギリスの場合はcolourと違いがあります。その場合は言語コードと国名コードの組み合わせを使います。国名コードはISO 3166-1で定義されているアルファベット2文字を使います。アメリカの英語の場合は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…

1

PIXを活用する その2

前回に続いて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を使って7年くらい経ちますが、今では描画に問題があったらすぐにPIXを立ち上げて調査するというのが習慣化していて、私にとってPIXはゲーム開発に必須のツールとなっています。 綺麗な絵を出すシェーダープログラミングに比べると地味なものですが、これを機にPIXに触れてもらえば幸いです。

1

PIXを活用する その1

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の主な機能としては 1フレーム、もしくは複数のフレームのレンダリング情報のキャプチャ レンダリングに使われた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…

2

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 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