続・真・簡単(かもしれない)日本語表示

問題報告をツイッターでつぶやくと…… 以前紹介したWPFフォントプロセッサーを使ってくれている人からツイッターの方で不具合報告がありました。 不具合報告は太いアウトライン描画をすると下図のような状態になるというものでした。 これはWPFのアウトライン描画時の使用するペンに線を繋げる時の方法を指定するPenLineJointというプロパティがあり、それがMiterになっていることが原因でした。これをBevel、もしくはRoundにすると問題は解決します。 また、アウトラインを描画するとフォントの上にラインを描画するので、小さなサイズのフォントでは1、2ピクセルの太さのアウトライン描画をすると下図のようにアウトラインが文字に覆いかぶさった状態になってしまいます。 今回、不具合を報告してくれた方がしていた方法として、アウトライン描画をした後にもう一度アウトライン無しで文字を描画することで、小さい文字でも綺麗に見えるようにしていました。同じ方法はAdobe After Effectのテキスト描画の時にアウトラインを先に描画するのか、後に描画するかを指定できるようになっています。     WPFフォントプロセッサーが更新される この二つの機能は便利なので早速WPFフォントプロセッサーに取り入れることにしました。今回追加したのは以下の二つのプロセッサーパラメーターです。 アウトライン形状 アウトライン描画方法 アウトライン形状には、Miter(鋭角)、Bevel(ベベル)、そしてRound(円形)のいずれかを設定できるようになっています。それぞの違いは下図の、特に「W」の文字で違いが分かると思います。 そして、アウトライン描画方法には以下の3つの方法を指定することができます。 StrokeOverFill 文字本体描画の後にアウトラインを描画する FillOverStroke アウトラインを描画した後に文字本体描画する StrokeOnly アウトラインのみを描画する   WPFフォントプロセッサー サンプル いつものように、今回もサンプルプログラムとWPFフォントプロセッサーのソースコードを公開します。 サンプルプログラムはWindows, Xbox 360,そしてWindows Phone 7 (7.1)のプロジェクトが用意されています。このサンプルプログラムでは複数のフォントを使った文字描画をしています。Xbox 360コントローラーのスティック、キーボードの上下キー、マウスのホイールスクロール、そしてタッチとフリック操作で文字をスクロールさせることができます。 サンプルは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFont20120604.zip XNA 4.0で用のWpfFontPiepline.dllは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFontPipeline20120604.zip

5

真・簡単(かもしれない)日本語表示

2012年6月4日追記 新しい機能を追加したものを投稿しました  いままで、ひにけにXNAではXNAで日本語表示する為の投稿を複数回してきました。 続・簡単(かもしれない)日本語表示: ツールによる日本語文字の追加 簡単(かもしれない)日本語表示: プロセッサー・パラメーターを使った日本語文字の追加 Content Pipeline その3 そのカスタマイズ: XNA 1.0時代のコンテント・パイプラインのカスタマイズの例として紹介 こうやって見返すと、今までの投稿ではいかにして簡単に日本語文字を追加するのかということを紹介してきました。 XNA標準のフォントプロセッサーでは、これ以外にも以下の基本的な問題があります。 OpenTypeフォントが使えない 大量の文字を処理させると時間が掛かる これらの問題を解決するには新しいフォントプロセッサーを作ることですが、独自のフォントプロセッサーを作ってしまうと、それに伴って独自の表示プログラムも用意しないといけません。XNAで用意されているSpriteFont描画に慣れている人達が多く居るなかで、似たような、だけどちょっとだけ違う文字表示APIを作るというのには抵抗がありました。 ですが、XNBファイルフォーマットが公開され、Silverlight 5のToolkitの中ではXNA 4.0のコンテント・パイプラインをそのまま使用し、Windows用のXNBファイルから直接3Dモデルなどを読み込んで、Silverlight 5で表示することができると知ったときに思いついたのが「同じデータを出力してSpriteFontになりすまことができれば、実行時にXNAの文字描画APIをそのまま使うことができるかも?」というアイディアが浮かんだので試してみたら、思ったよりも良い物ができたので公開することにしました。 WPF フォントプロセッサー 今回紹介するのはWPFを使用したWPFフォントプロセッサーです。WPFを知らない人の為に補足しておくと、WPFはWindows Presentation Foundationの略で今までのGDI/GDI+を使ったUIフレームワークとは違い、GPUアクセラレーションを利用した新しいUIフレームワークです。SilverlightはWPFのサブセットでWindows Phone 7でも使われいて、Windowsの後継OSであるWindows 8の新しいアプリケーションモデルの1つであるXAMLアプリケーションはこのWPFが元となっています。 WPFフォントプロセッサーはその名の通り、WPFの文字描画を使用したフォントプロセッサーです。特徴としては以下の3つがあります。 OpenTypeフォント対応 処理速度の高速化 JIS漢字追加機能 文字装飾 WPFは今までのようにTrueType、そしてOpenTypeフォントに対応しています。OpenTypeフォントはOpenの名が示すとおりOSに依存しないフォントフォーマットで、現在広く普及しているフォントフォーマットです。OpenTypeフォント対応によって、これらの多くのフォントをXNAで作られたゲームでも簡単に使えるようになりました。 そして、処理速度の高速化ですが、XNA標準のフォントプロセッサーは生成したテクスチャをできるだけコンパクトにまとめる為のアルゴリズムを採用しています。ですが、文字数の増加に対して指数関数的に処理時間が掛かってしまうという問題があります。ゲーム内で使われる文字だけを抽出して生成する場合は1,500文字程度で収まるので大きな問題とはならないのですが、常用漢字やJIS漢字といった2千文字を超えてくると極端に時間が掛かるようになり、場合によっては20分近く掛かってしまうということがありました。 そこで、WPFフォントプロセッサーでは漢字などの大量の文字を処理するのに適したアルゴリズムを採用して処理速度の高速化をしています。以下は私のPCで測定した結果です。 文字数 XNAフォント プロセッサー WPFフォント プロセッサー 速度差 常用漢字を含む2,331字 3分20秒 0.6秒 333倍 JIS第1水準漢字を含む3,438字 10分28秒 0.82秒 765倍 JIS第2水準漢字を含む6,974字 N/A 1.63秒…

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 4.0アセンブリファイル

SilverlightからXNAフレームワークを使用する Windows Phone 7 シリーズでアプリケーションを作る場合は、SilverlightとXNA Frameworkを使うことができます。SilverlightはMicrosoft Expression Blendとの連携で簡単にUI構築ができるという利点があり、XNA Frameworkは3Dを筆頭に高パフォーマンスが求められるゲームアプリに向いています。 Silverlightでアプリケーションを作っているときにXNA フレームワークの機能、特に追加されたばかりのダイナミックオーディオ機能や、GamerServices機能を使いたいというケースがあります。 細分化されたアセンブリファイル このことを実現するために、4.0ではアセンブリファイルが機能ことに細分化され、それぞれが独立して機能するように変更が加えられています。 XNA Game Studio 3.1までは実行時に必要なアセンブリファイルはMicrosoft.Xna.Framework.dllとMicrosoft.Xna.Framework.Game.dllの二つでしたが、4.0のReachプロファイルでは以下の様に各機能毎に分割されています。 Microsoft.Xna.Framework.dll Math、オーディオ、メディア Microsoft.Xna.Framework.Game.dll Gameクラス関連 Microsoft.Xna.Framework.GamerServices.dll GamerProfile、Achievement、Leaderboard等 Microsoft.Xna.Framework.Graphics.dll グラフィクス関連 Microsoft.Xna.Framework.Input.Touch.dll TouchPanelクラス これらのアセンブリファイルはMicrosoft.Xna.Framework.dllへの依存する以外はそれぞれ独立したアセンブリとして使用することができます。これで前述のように、SilverlightとXNA Frameworkの機能を組み合わせて使えるようになっています。同様にWindows上でもWPFやWinForm用のプロジェクトから、XNAのそれぞれのアセンブリを自由に使用することができるようになっています。 このアセンブリの細分化を言い換えると、Microsoft.Xna.Framework.Graphics.dll以外のアセンブリはからグラフィクスへの依存がなくなったとも言えます。 この副作用として、以前はTexture2DだったものがStreamを返すように変更されています。例えばGamerProfile.GamerPictureプロパティやメディアライブラリ内のPicture.GetTextureメソッドはGetImageメソッドに名称変更されているというようにです。 ここで返されるStreamは.Netフレームワークで読み込むことのできる一般的な画像フォーマットファイルとなっているので、SilverlightやWPF上で簡単にDataBinding先として使用することができます。 逆にこのストリームデータをゲーム内でテクスチャとして使うためにTexture2D.FromStreamメソッドが追加されています。

0

Windows Phone Developer Tools CTP版リリース

昨日のMIXのキーノート内で発表された通り、Windows Phone開発用ツールのCTP版がダウンロードできるようになりました。 Windows Phone開発者用ページ http://developer.windowsphone.com/ Windows Phone開発者用ツールCTP版ダウンロードページ http://www.microsoft.com/downloads/details.aspx?FamilyID=2338b5d1-79d8-46af-b828-380b0f854203&displaylang=en リリースノート http://download.microsoft.com/download/D/9/2/D926FB38-BB43-4D87-AE5A-1A3391279FAC/ReleaseNotes.htm このツール群の中にはXNA Game Studio 4.0 CTPを使うために必要な以下のものが含まれています。 XNA Game Studio 4.0 CTP Visual Studio 2010 RC1とVisual Studio 2010 for Windows Phoneに対応 Visual Studio 2010 Express for Windows Phone Windows Phone Emulator GPUアクセラレーションを使用するにはDirectX 10に対応しているビデオカードが必要(対応していない場合はソフトウェア描画となる) XNA Game Studio 4.0として使う場合の注意点 今回公開されたのはReach、HiDefのプロファイルのうちのReachプロファイル部分のみとなっていることに注意してください。これに加えて以下のことに注意する必要があります。 Reachプロファイルのみ対応 Xbox 360版は未対応(Reach版のコードは書くことはできる) 自動スケーラー未対応 Windows Phone上では常に480x800のポートレート画面を使う必要がある。ランドスケープ にする場合はランドスケープ用のRenderTargetにゲーム画面を描画してから、最後にSpriteBatchを使って回転して描画する必要があります。 XNA Game…

0

XNA Game Studio 4.0の新機能

  最近、私の忙しさの尺度はこのブログの更新頻度に反比例しているということに気づきました。去年の秋あたりから忙しくなり、今年に入ってGamefest、GDC、そしてMIXへ向けての作業に追われる毎日でした。で、ちょっとだけひと段落したので、またいろいろと記事を書いていこう思っています。 まず最初のニュースはXNA Game Studio 4.0についてです。XNA Game StudioはWindows、Xbox 360、そしてZuneと対応プラットフォームを増やしてきましたが、4.0ではWindows Phone 7シリーズへの対応が決まりました。 Windows Phone 7シリーズでは要望の多かった3D APIが追加されています。ただし、Xbox 360やWindowsなどと比べると非力な携帯デバイスなので、複数のプラットフォームでゲームを作る場合にはプラットフォーム間のパフォーマンス差を考慮する必要があります。 この労力を軽減するために4.0では、”Reach(リーチ)”と”HiDef(ハイデフ)”の二つのCapsを設けました。ReachはWindows Phone 7シリーズを含めたどのプラットフォームでも動作させることのできるAPI群からなり、HiDefはXbox 360やハイエンドWindowsマシン上で動作することを前提にしたAPI群からなります。HiDefではReachの全APIが使えるようになっています。 以下はXNA Game Studio 4.0の主な新機能です。 XNA Game Studio 4.0の新機能 Visual Studio 2010に対応 グラフィクスAPIを機能的に”Reach(リーチ)”と”HiDef(ハイデフ)”にカテゴリ分け ダイナミックオーディオ マイク BasicEffectに加えて以下の基本的エフェクトクラスの追加 SkinnedEffect (スキンモデル用のエフェクト) EnvironmentMapEffect (環境マップ用のエフェクト) DualTextureEffect (デュアルテクスチャ用のエフェクト) AlphaTestEffect (アルファテスト用のエフェクト) これらの詳細は今週開催されているGDC、そして来週開催されるMIXで公開される予定です。 http://blogs.technet.com/microsoft_blog/archive/2010/03/09/game-developers-have-a-great-opportunity-with-windows-phone-7-series.aspx http://blogs.msdn.com/shawnhar/archive/2010/03/09/in-which-hints-become-facts-xna-game-studio-4-0.aspx#comments http://klucher.com/blog/achievement-unlocked-xna-game-studio-4-0-for-windows-phone/

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

ClickOnce その2

スタートメニューの登録名を変更する デフォルトの状態でClickOnceを使うと、インストール時にスタートメニューにはプロジェクト名/プロジェクト名のように登録されます。前回の例ではSuperCatsというプロジェクトを作ったので、SuperCats/SuperCatsのようになります。 この設定の変更はプロジェクトプロパティの発行タブで行います。 発行タブページは上図のようになっていて、この中のオプションボタンを押すと、以下の発行オプションダイアログが開きます。   このダイアログ内の発行者名と製品名を変更することで、スタートメニューには発行者名/製品名のように登録されます。ここでは、発行者名を「ひげねこ」、製品名を「超猫」とします。 この状態で発行されたパッケージをインストールすると、上図のようになります。 配置マニフェストにマシン名とユーザー名が記載されるのを防ぐ ここでは、デフォルトの状態で配布するパッケージにはパッケージを作ったマシン名と、ユーザー名が含まれている問題を解決する方法を紹介します。これでも構わないと言う人は読み飛ばして下さい。 アプリケーションを発行すると、発行先のフォルダにはアプリケーション名.applicationという配置マニフェストファイルが生成されます。このファイルはXMLファイルで中には発行者の情報が書かれおり、デフォルトの状態では発行者の情報はマシン名/ユーザー名のようになります。 なぜこうなっているかを簡単に説明すると、ClickOnceは発行者が発行したアプリケーションが第三者によって発行者の意図しない変更がされるのを防ぐために電子署名をするようになっていて、配置マニフェストには署名に使われた証明書の発行者名が記載されるようになっているからです。 デフォルトでは自動的に電子署名が作られ、上図のようにプロジェクトにテンポラリ証明書が追加されます。   この証明書の詳細は、プロジェクトプロパティの署名タブで見ることができます。上図では、私がテストに使っているノートブックのマシン名とユーザー名が発行者情報になってしまっています。 殆どの場合は問題ないのですが、個人的な情報、例えば彼女やお嫁さん(現実、非現実含む)の名前とかをマシン名やユーザー名に使ってい場合には、その情報をネットに流出するといろいろと問題があるという人も居ると思うのでここでは電子証明書の生成のしかたを紹介します。 個人でゲーム制作をしている場合、電子証明書を取得するには以下の二種類が考えられます。 VeriSignなどの電子証明書発行サービスを利用する(有料) 自己署名証明書を作る 作ったゲームを商品として販売するには1にするべきですが、ここでは自己署名証明書の作り方を紹介します。ただし、この証明書は誰にでも作ることができるので信頼できる証明書では無いことに注意して下さい。 証明書を作るにはmakecert.exeを使います。このツールは.Net Framework SDKやWindows SDKに付属しています。SDKのコマンドプロンプトを開いて、以下のコマンドを実行します。 makecert -r -n “CN=John Smith” -b 01/01/2008 -e 12/31/2008 -sky exchange -ss my それぞれのオプションの意味は以下のようになっています。 -r 自己署名証明書を作成 -n X.500 標準に準拠した証書名、ここでは発行者名を”John Smith”としている。 -b 証明書の有効期間開始日 月/日/西暦で表される -e 証明書の有効期間終了日 月/日/西暦で表される -sky サブジェクトのキーの種類 -ss 作成した証明書を格納するストア名 ここでは、発行者名を”John Smith”としましたが、自分の好きな名前に変更することができます。また、Windows…

1