メタセコイア 4.2がリリースされました。4.2では作業中のサムネイル画像をMQOファイルにThumbnailチャンクとして保存できるようになりました。

そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.3を公開します。

メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む)
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-sample.zip

メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-bin.zip

メタセコイア・パイプライン: ソースコードとプロジェクト
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-src.zip

例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

メタセコイア 4.0がリリース

メタセコイア 4.0がリリースされました。4.0でセーブされたMQOファイルではバージョン番号が1.1になり、tripatchチャンクが追加されていることを確認しました。

そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.2を公開します。

メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む)
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-sample.zip

メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-bin.zip

メタセコイア・パイプライン: ソースコードとプロジェクト
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-src.zip

例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

最初の投稿はPowerShell Advent Calendar 2012への記事になります。

大規模ゲーム開発の見えづらい問題点

個人的にPowerShellが大好きで、Advent Calendar 2012投稿へのお誘いを受けたのは嬉しいことなんですが、まだまだ周りの人達から教えてもらうことの方が多く、既に知られている記事になってしまいそうだなぁということで、今回は100人を超える大規模ゲーム開発現場でPowerShellがどのように使われているのか紹介します。

現在、私が携わっているゲーム開発ではシアトルを本拠地として、世界の数ヶ所に開発拠点があり、約150人がゲーム開発に関わっています。つまり、実質1日24時間体制でゲーム開発が行われています。1日24時間といっても土日は休みになるので年中無休ではありません(少なくとも現状ではw)

これだけの大人数での開発を支える為に120台程のサーバーがあり、その役割として、100近いVisual Studioのプロジェクをはじめとしたソースコードのバージョン管理ソフト用サーバーや、数百GBに達するコンテント処理をして最終的なメディアに変換するためのビルドサーバー等があります。

大規模プロジェクトでは、ゲーム開発に直接関わる作業以外の見えずらいコストが問題になってきます。

• 数百台あるPCのプログラマーやアーティスト、そしてサーバーの初期設定や更新コスト

• ツールやスクリプトの学習コスト

開発環境を整える

大規模ゲーム開発で、チームメンバー数の増減はプロジェクトの最中でも頻繁に起こります。それに加えて開発環境に必要なものも多くあり、プログラマーにはVisual Studio、TFS、.Net Framework、Xbox 360 SDK、各ミドルウェアSDK、アーティストには3D Studio Max、Photoshop、内製のツール群、そしてバグ追跡用ツールなどのプログラマーとアーティストの両方に必要なツールなどを新しいチームメンバのPC初期設定、そして常に最新の状態にしておく必要があります。

その為に"setup.exe"という名前のシンプルなGUIベースのツールがあり、ずらーっと並んだチェックボックスやコンボボックスからインストールする物や設定する項目を選択できるようになっています。選択項目は沢山ありますが、基本的にはプログラマーかアーティストかを選択して「Go」ボタンを押すだけで済むようになっています。

「Go」ボタンを押すとPowerShellが起動され、選択した項目を自動的にインストールまたは設定するスクリプトが実行されるようになっています。私がチームに入った当日、朝に「Go」ボタンを押し、待っている間に必要なドキュメントを読み、ランチから帰ってきた時にはゲーム開発の準備が整っていました。この理由から開発用PCにはWindows Serverを使用しています。

このツールは開発PCの初期設定の他にも自動更新等にも使用されています。例えばレジストリキーを変更する必要があった時、PowerShellスクリプトに数行の変更を加えるだけで全ての開発PCに同じ変更を適用することができました。同様のPowerShellスクリプトは100台以上あるビルドサーバーの設定を変更する時にも使用されています。

プログラマーの場合、開発用のPowerShellウインドウが用意されていて、開発に有用なモジュール、スクリプト、エリアスなどを使うことができるようになっています。

このPowerShellウインドウから、"vs"エリアスでカスタム環境設定を適用したVisual Studioを起動したり、"Set-DebugConfigs" スクリプトでデバッグ用パラメーターを設定したり、"Prop-Build" スクリプトでXbox 360上でゲームを実行するのにテスト設定ファイルを含む必要なコンテントファイルや実行ファイルをXbox 360開発機へと転送したりするといった毎日の作業に役立つスクリプトなどを使用することができます。

学習コストの削減

PowerShellスクリプトの素晴らしい点は、スクリプトのパラメーターを扱う機能やUsageを表示する機能などが標準で提供されていることです。大規模なプロジェクトでは、その全てを詳細まで把握できる人は存在せず、開発期間中に今まで一度も触ったことのないツールやスクリプトを使う必要に迫られるケースもあります。そういう時、使い方を学ぶ必要がありますが、その時間は極力少なく、もしくは使い慣れていないツールを学ぶ時間を取ることができないことも少なくはありません。

PowerShell導入以前は小さなツールやスクリプトは複数の方法で作られていました。メイン処理の行数よりもコマンドラインオプションを処理する行数が多くなってしまうDOSのバッチファイル、コンパイルする必要のあるC#で書かれたプログラム、更に今ではすっかり読める人が少なくなってしまったPerlスクリプトまでありました。

複数の方法で作られた多数の小さなツールやスクリプトは使うのもメンテナンスするのも困難です。あるツールは「/」をオプション指定の接頭文字に使い、他のツールは「-」を使う。また、あるツールは接頭文字を指定する必要がないものもあります。複数のファイルの指定の仕方は？Usage表示の仕方やそのフォーマットは？それぞれの差異は小さくてもその量が多いと把握するのは難しくなり、個々の小さなツールを使うのに時間が掛かってしまいます。１人がそれぞれのツールを使うのに掛かる時間自体は多くなくても、全体で見ると無視できない量のコストとなってしまいます。

これがPowerShellだとParameterアトリビュートによる各パラメーターの検証、説明の記述ができるので「help スクリプト名」という共通のコマンドで全スクリプトの使用方法を即座に把握でき、タブキーによる自動補完機能を前提としてパラメーター名は多少冗長になっても理解しやすさを重視しています。これらの機能による学習コストや些細なミスを未然に防ぐことによる生産性向上は決して少なくはありません

モダンシェル

その他にも、PowerShellには単純な違いに思えるけど非常に有益な機能の一つに、テキストの代わりにオブジェクトベースのパイプ処理になっていることです。

多くの小さなツールがある状況で毎日の作業効率を上げる為に、それらのツールを組み合わせたツールやスクリプトを作るのは自然なことです。例えば「指定したXbox 360開発機に幾つかのファイルを配置したいけど、それらはユーザー毎の設定ファイルによってコントロールしたい」という要求があった場合、既にある「指定したファイルをXbox 360開発機へ配置するスクリプト」と「ユーザー設定を表示するスクリプト」、そして配置したいファイルリストを組み合わせます。ポイントとして「ユーザー設定を表示するスクリプト」がテキストを返す場合、そのテキストの受け取り側のスクリプトで受け取ったテキストの中から欲しい情報を抽出処理する必要があります。対照的にPowerShellはオブジェクトを返すので、受け取り側で単に「$_.プロパティ名」と指定するだけで済みます。つまり、他のスクリプトへの依存関係を少なくすることができるということです。

これらのスクリプトを組み合わせる時に非常に有用なのがデバッグ機能です。初めて使うスクリプトでもデバッガを使ってその流れを追うことで短時間で理解することができ、複雑なスクリプトでもその問題点を見つけ出すのに他のスクリプトでは定番になっている「Printfデバッグ」に比べて遥かに短時間で問題点を洗い出すことができます。

最後に、最も重要なPowerShellの機能として.Net Frameworkとの連携があります。今携わっているプロジェクトではWPFで作られたゲームエディタを初めとし、.Netベースのツールが数多くあり、その多くの機能はエディタ以外にもコンテントビルド中に使われます。

例えばテクスチャコンパイラーと呼ばれるツールがありますが、このツールはC++/CLIで作られていて、ゲームエンジンの機能を流用すると同時に.Netアセンブリとして使いやすいインターフェースを提供しています。このアセンブリはWPFツールから参照され、エディター上でコンパイルされたテクスチャの表示やサムネイルの生成機能などを提供し、MSBuildのプロジェクトから参照され、ビルドサーバー上でテクスャをコンパイルする為の機能を提供、そしてもろちんPowerShellスクリプトからも参照され、コンパイルされたテクスャ情報のデータマイニング、ゲーム中UIで使われるテクスチャーを別途処理するのに使われています。

PowerShellを使おう

北米のゲーム開発現場では「スピード・バンプ(Speed Bump)」という言葉が良く使われます。これは駐車場等で車の速度制限する為に必要なものですが、ゲーム開発においての「スピード・バンプ」とは開発速度を落とす、取り去るべきものとして扱われています。PowerShellはこのスピード・バンプの多くを取り除き、開発速度の平均速度向上に非常に役立っています。

PowerShellを実際のプロジェクトで毎日のように使ってみて「PowerShellは大規模ゲーム開発でも使用可能」と、考えるようになり、今では「大規模ゲーム開発にPowerShellは必要不可欠なもの」と考えるようになりました。

今までPowerShellを触ったことのない人も、これを機にPowerShellを使ってみてはどうでしょうか？

去年の10月にXNA Game Studio 4.0 Refreshが公開されました。これは、Windows Phone SDK 7.1の中に含まれる形でリリースされ、内容もWindows Phone 7.1の新機能追加が主だったので私もツイッターの方でつぶやく程度で済ませてました。

ですが、Windows Phone向けの新機能以外にもVisual Basic対応やバグフィクスが含まれているので、WindowsやXbox 360で開発している人でも更新する価値は十分にあると思うのでここでも紹介します。

まず、新機能としてVisual Basicに正式に対応したこと、これはWindows Phoneはもちろん、Xbox 360やWindowsでもXNA Game StudioをVisual Basicを使って開発できるようになりました。

そして、バグフィクスの中で比較的重要だと思われるのが「固定更新時、速いPCやフレーム内の処理量が少ない時に更新時間計算の誤差が大きくなり、見かけのフレームレートが下がってしまう」という問題が修正されていることです。

また、Refreshという名前の通り、既存APIからの変更は無くバイナリ互換となっているので3.1から4.0へ更新の時とは違って既存のプロジェクトやコードはそのままコンパイル、実行することができるので現在4.0で開発中の人でも安心して更新することができます。

XNA Game Studio 4.0 Refreshへ更新する

幾つかのケースがあると思うので、それぞれのケースでXNA Game Studio 4.0 Refreshをインストールする方法を紹介します。

1. Windows Phone SDK 7.1をインストールしている
   
   なにもする必要はありません。前述のようにXNA Game Studio 4.0 RefreshはWindows Phone SDK 7.1に含まれています。
   
2. Windows Phone Developer Tools (7.0)をインストールしている
   
   Windows Phone Developer Toolsをアンインストールし、Windows Phone SDK 7.1(日本語)をインストールします。
   
3. XNA Game Studio 4.0 + Language Pack(日本語)をインストールしている
   
   XNA Game Studio 4.0 Refreshをインストールします。Refreshは更新プログラムなのでXNA Game Studio 4.0やLanguage Packをアンインストールする必要はありません。
   
4. XNA Game Studio 4.0のみをインストールしている
   
   XNA Game Studio 4.0 Refreshをインストールします。必要であればXNA Game Studio 4.0 Language Pack(日本語)をインストールします。

では、テクスチャを動的頂点バッファのように扱うにはどうしたら良いでしょうか？そもそもDynamicTexture2Dというクラスもないし、Texture2D.SetDataにSetDataOptionsを受け取るメソッドもない……。

その答えは

XNA Game Studio 4.0でのTexture.SetDataメソッドはSetDataOptions.Discardを指定した時と同じ振る舞いをする(但し注意点あり)

となります。

振る舞い的にはTexture2D/Texture3D/TextureCube、それぞれDiscardオプションを指定した時と同じように、指定したテクスチャがGPUで使われていた場合、内部で自動的に同じサイズ、フォーマットのテクスチャを生成し、その新しいテクスチャへデータを書き込むようになっています。

但し、この時にSetDataに渡されるパラメーターがテクスチャの一部分を書き換える設定になっていると、以前のテクスチャからデータを新しいテクスチャへコピーするようになっています。コピーだけならそれ程時間が掛からないのですが、このコピーする際に以前のテクスチャをGPUが使い終わるまで待ってからコピーするようになっているので、結局はDiscardオプションをつけていない時と同じ状態になってしまいます。

私のところでテストしたところ、256x256のテクスチャの一部分を書き換えた時、以下のような結果になりました。

まとめると、

1. テクスチャ全体を書き換える場合は、パフォーマンス問題は発生しない
2. テクスチャの一部分を書き換える場合、複数のテクスチャを切り替えながら書き込むようにしないと遅くなる

となります。

テクスチャを切り替えながらSetDataを呼ぶ方法としては「頂点テクスチャでスキンアニメーション」の記事のサンプルコード内にあるFlipTexture2D.csが参考になるでしょう。

以前紹介したWPFフォントプロセッサーを使ってくれている人からツイッターの方で不具合報告がありました。

不具合報告は太いアウトライン描画をすると下図のような状態になるというものでした。

これはWPFのアウトライン描画時の使用するペンに線を繋げる時の方法を指定するPenLineJointというプロパティがあり、それがMiterになっていることが原因でした。これをBevel、もしくはRoundにすると問題は解決します。

また、アウトラインを描画するとフォントの上にラインを描画するので、小さなサイズのフォントでは1、2ピクセルの太さのアウトライン描画をすると下図のようにアウトラインが文字に覆いかぶさった状態になってしまいます。

今回、不具合を報告してくれた方がしていた方法として、アウトライン描画をした後にもう一度アウトライン無しで文字を描画することで、小さい文字でも綺麗に見えるようにしていました。同じ方法はAdobe After Effectのテキスト描画の時にアウトラインを先に描画するのか、後に描画するかを指定できるようになっています。

WPFフォントプロセッサーが更新される

この二つの機能は便利なので早速WPFフォントプロセッサーに取り入れることにしました。今回追加したのは以下の二つのプロセッサーパラメーターです。

• アウトライン形状
• アウトライン描画方法

アウトライン形状には、Miter(鋭角)、Bevel(ベベル)、そしてRound(円形)のいずれかを設定できるようになっています。それぞの違いは下図の、特に「W」の文字で違いが分かると思います。

そして、アウトライン描画方法には以下の３つの方法を指定することができます。

• StrokeOverFill 文字本体描画の後にアウトラインを描画する
• FillOverStroke アウトラインを描画した後に文字本体描画する
• StrokeOnly アウトラインのみを描画する

WPFフォントプロセッサー サンプル

いつものように、今回もサンプルプログラムとWPFフォントプロセッサーのソースコードを公開します。

サンプルプログラムはWindows, Xbox 360,そしてWindows Phone 7 (7.1)のプロジェクトが用意されています。このサンプルプログラムでは複数のフォントを使った文字描画をしています。Xbox 360コントローラーのスティック、キーボードの上下キー、マウスのホイールスクロール、そしてタッチとフリック操作で文字をスクロールさせることができます。

サンプルは以下のURLからダウンロードできます。

https://higeneko.net/hinikeni/sample/xna40/WpfFont20120604.zip

XNA 4.0で用のWpfFontPiepline.dllは以下のURLからダウンロードできます。

https://higeneko.net/hinikeni/sample/xna40/WpfFontPipeline20120604.zip

ネットワーク その1 レイテンシ
ネットワーク その2 パケットロス
ネットワーク その3 帯域
ネットワーク その４ 帯域 ボイスチャットについて
ネットワーク その５ 圧縮
ネットワーク その６ 量子化で圧縮
ネットワーク その７ ビットフィールドで圧縮
ネットワーク その８ 算術符号化圧縮
ネットワーク その９ 究極の圧縮方法
ネットワーク その１０ オブジェクト所有権

また、AppHubの方にあるネットワーク関連のサンプルへのリンクもまとめてみました。

ネットワーク予測
ネットワーク アーキテクチャー: クライアント/サーバー
ネットワーク ゲームの状態管理
ネットワーク アーキテクチャー: ピア ツー ピア
招待
ネットワーク ロビーおよびチャット用アイコン
Net Rumble (英語版)
HTTP マルチプレイヤー: Tic Tac Toe (Windows Phone用)
Yacht (Windows Phone用)

メタセコイア 4.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.2」を公開しました

メタセコイア 3.0がリリース

メタセコイア 3.0がリリースされたので、早速ダウンロードして軽く以前紹介したメタセコイアサンプルプログラムの動作テストをしてみました。

Mkxエクスポーターはそのまま使えるのを確認しましたが、MQOファイルを直接読み込むメタセコイア・パイプラインはそのままでは3.0から出力したMQOファイルを読み込めませんでした。これは、2.2の時には無かったチャンクが3.0で出力したMQOファイルに存在するのが原因でした

そこで、3.0で出力したMQOファイルも読み込めるように修正したバージョン1.1を公開します。

メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む)
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-sample.zip

メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-bin.zip

メタセコイア・パイプライン: ソースコードとプロジェクト
https://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-src.zip

メタセコイア 3.0の新機能として彫刻機能があります。下図は球体に1分くらいで適当に彫刻したモデルをメタセコイア・パイプライン Ver. 1.1を使ってXNAで表示したものです。こういった複雑な形状のモデルが直ぐに作ることができ、そのままXNA上で表示できるというのはゲーム制作に大いに役立つことでしょう。

まだメタセコイア3.0はリリースされたばかりなので、これ以外にもパイプラインに不具合があるかもしれないので、もし見つけたら気軽に連絡ください。

 いままで、ひにけにXNAではXNAで日本語表示する為の投稿を複数回してきました。

1. 続・簡単(かもしれない)日本語表示: ツールによる日本語文字の追加
2. 簡単(かもしれない)日本語表示: プロセッサー・パラメーターを使った日本語文字の追加
3. Content Pipeline その３ そのカスタマイズ: XNA 1.0時代のコンテント・パイプラインのカスタマイズの例として紹介

こうやって見返すと、今までの投稿ではいかにして簡単に日本語文字を追加するのかということを紹介してきました。

XNA標準のフォントプロセッサーでは、これ以外にも以下の基本的な問題があります。

1. OpenTypeフォントが使えない
2. 大量の文字を処理させると時間が掛かる

これらの問題を解決するには新しいフォントプロセッサーを作ることですが、独自のフォントプロセッサーを作ってしまうと、それに伴って独自の表示プログラムも用意しないといけません。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で測定した結果です。

このように処理速度の劇的な高速化ができたので、大量の文字を必要とするゲームも手軽に作れるようになりました。これだけ速くなると、今までは処理速度の関係で使うのを躊躇していたJIS基本漢字も使いたいところです。そこでWPFフォントプロセッサーではプロセッサー・パラメーターでJIS基本漢字を簡単に追加できるようになっています。

WPFの文字描画では色々な装飾を施すことができるようになっています。WPFフォントプロセッサーでは、グラデーション文字、アウトライン文字をプロセッサー・パラメーターで指定できるようになっています。以下の画像はグラデーション、アウトライン、そしてそれらを組み合わせた文字の例です。

WPFではこれ以外にも様々な文字描画カスタマイズができるようになっています。WPFフォントプロセッサーでは、文字描画部分が仮想メソッドとなっているので、カスタム・コンテント・プロセッサーをWPFフォントプロセッサーのクラスから派生させることにより自分の好きな描画に差し替えることができるようになっています。

WPF フォントプロセッサーの使い方(基本編)

WPFフォントプロセッサーを使うのは以下の２つのステップで完了します。

1. WpfFontPipeline.dll(ダウンロードURLはページの最後)をコンテント・プロジェクトの参照設定に追加する
2. Spritefontファイルのコンテンツ プロセッサに「WPF フォントプロセッサー」を選択する

WPFフォントプロセッサーは、既存のXNAのSpritefontファイルをそのまま使うことができます。また、プロセッサー自体(WpfFontDescriptionProcessor)もXNA標準のプロセッサー(FontDescriptionProcessor)と互換なので、FontDescriptionProcessorから派生したカスタムプロセッサーの派生元をWpfFontDescriptionProcessor、つまり派生元クラス名の頭に「Wpf」と三文字追加するだけで、そのまま動作します。

WPF フォントプロセッサーの使い方(プロセッサー・パラメーター編)

WPFフォントプロセッサーには20のプロセッサー・パラメーターがあります。今まで紹介してきたプロセッサよりもパラメーターの数が多いですが、基本は以下の３つに分類されます

1. 追加文字の指定
2. 文字装飾の設定
3. 文字テクスチャーフォーマット指定

追加文字のプロセッサーパラメーターでは半角英数時であるASCII文字、JIS基準漢字で定義されている、記号、全角英数字、ひらがな、かたかな、ギリシャ文字、キリル文字、罫線、そして第1、第2水準漢字を指定することができます。前述の通り、これら全部の文字を含めて7千文字を追加しても数秒で生成できますが、これだけの文字数になるとテクスチャサイズがReachプロファイルの上限である2048x2048のテクスチャサイズに収まらなくなるので注意が必要です。

「追加文字 テキスト」パラメーターでは直接追加したい文字を指定することができます。追加文字処理では常に重複する文字を生成しないようになっているので「ああいいうう」という文字を指定しても、実際に生成されるのは「あいう」の３文字になるようになっています。

「追加文字 テキストファイル名」には以前紹介した方法のように指定されたテキストファイル内で使われている文字を追加することができます。今回は追加機能としてセミコロン(;)で区切って複数のファイル名を指定できるようになっています。サンプルでもメッセージが入ったソースコードファイルを指定するという小技を使っています。また、文字エンコーディングはOSデフォルト設定にしてあるので日本語版Windowsで使用していればSJISで書かれたテキストファイルをそのまま読むことができます。

文字装飾では文字の色、アウトラインの太さや色、グラデーションの開始色、終端色、角度などを指定することができます。アウトラインの太さには1.5といった小数点を指定することができます。

文字テクスチャフォーマットでは、フォーマットを自動選択するAuto、Bgra4444、そしてColorを選択することができます。Autoを選択すると、単色文字では独自の圧縮処理をするDXT3圧縮(1/4サイズ)、アウトラインを使用するとBgra4444(1/2サイズ)、そしてグラデーションを使用するとColorを使用するようになっています。今年になってXbox Live インディーズゲームに投稿できるゲームサイズ上限値が変更されたので、テクスチャサイズが大きくても綺麗な文字が使いたい場合などに変更すると良いでしょう。

WPFフォントプロセッサー サンプル

いつものように、今回もサンプルプログラムとWPFフォントプロセッサーのソースコードを公開します。

サンプルプログラムはWindows, Xbox 360,そしてWindows Phone 7 (7.1)のプロジェクトが用意されています。このサンプルプログラムでは複数のフォントを使った文字描画をしています。Xbox 360コントローラーのスティック、キーボードの上下キー、マウスのホイールスクロール、そしてタッチとフリック操作で文字をスクロールさせることができます。

2012年６月4日追記 新しい機能を追加したものを投稿しました

サンプルは以下のURLからダウンロードできます。

https://higeneko.net/hinikeni/sample/xna40/WpfFont.zip

XNA 4.0で用のWpfFontPiepline.dllは以下のURLからダウンロードできます。

https://higeneko.net/hinikeni/sample/xna40/WpfFontPipeline.zip

2012年も沢山の面白いゲームを登録していただけるように、皆様から要望の多かったゲームサイズや登録数の制限数を上げることとなりました。

CCGAMEファイルが最大500MBに

ゲームのサイズ上限はCCGAMEファイル(圧縮ファイル)のサイズによって決まりますが、この上限が以下のようになりました。

登録できるタイトル数は20タイトルに

また、登録できるゲームの数が以前は10タイトルまででしたが、この上限が20タイトルまでとなりました。

今年も沢山の面白いゲームを是非Xbox LIVE インディーズゲームへと是非登録してください！

公式発表(英文)
https://blogs.msdn.com/b/xna/archive/2012/01/04/happy-new-year-xbox-live-indie-games.aspx