XSI 6 Mod Tool - XNA 連携チュートリアル

風邪を引いて休んでいた間に、CARRARA 6関連の情報が結構出てたりと少し浦島な感じ。

XSI 6 Mod Tool を起動したらバージョンアップがかかるなど、世間は私が止まっていても動き続けていた…。

そんで待望（？）のNoesisのXSI 6 Mod Tool と XNA との連携チュートリアルビデオがついに公開。

http://www.softimage.com/products/modtool/learn.aspx

…んだが、内容は私が調べたものとたいして変わりがなかった。
まぁ、私が調べた内容が公式とかけ離れたものではなかったと確認できたということで良しとしよう。

今回のチュートリアルは「N」のロゴモデルをXNAViewerで表示するまでの紹介。
最初今となっては結構余計な部分（VC#2005ExpressやXNAのインストールなど）があるかもしれないが、シェーダーファイルをモデルにドラッグアンドドロップすることでマテリアル設定できるなど、細かい点で「へぇ～」と思う点は結構あった。

今後、もっと濃い内容の続編チュートリアルが出ることを祈って今回はここまでとする。

Diablo

いろいろありすぎてここ２日ようわけがわからんくらいいろいろ何かしてる。
…けどコンピュータ（XBOX360)の前から離れない。
世の中（外）はいったい晴れなのか、曇りなのか、雨が降ってるのか、明るいのか暗いのかさえわからない…。
コンピュータ(XBOX360)関連でやらなくちゃいけない（やりたい）ことが多すぎるんだよ…。

1.
日本のXNA デベロッパー センター(MSDN)にてXNA GSE HELP の基礎を翻訳
…ということで公開されています。
英語が苦手で内容があやふやだった方は一読しておくべきかと。

2.
2007年9月6日と7日に「Gamefest Japan 2007」 を開催
http://www.microsoft.com/japan/msdn/xna/gamefest2007j.aspx
一般の方も参加可(申し込み手続きは必要）で、XNA関連についても説明会があります。
私も参加しようとしたのですが、XNAの2.0についての説明会はすでに満員。
けど他にもXNA関連の説明会がありますので参加してみては？
（※良く考えたら普通に講義ある日じゃん…）

続きを読む "Diablo"

SOFTIMAGE_XNAViewer

さて XSI 6 Mod Tool がもんのすげー使える（使えそうだな）とわかってきた気がする。
期待するのは当然 XNA との連携なのだが、XSIのラーニングを請け負っているNoesisのXNAとの連携チュートリアルは（おそらく）まだ公開されていない。

前回の記事でXSIのチュートリアルで作った時限爆弾をポリゴン数を手動（といっても普通行なうであろう作業なんかよりよっぽど楽なのだが…）で少なくする作業をほどこした後、ＦＢＸで出力してＸＮＡのBasicEffectにて表示することは難なくできた。

しかし、本来の目玉はXSI 6 Mod Tool上でマテリアルごとにシェーダーを設定して、それをそのまま表示することが（データにどのシェーダーが使われているか？等の情報を入れることが）可能なはずなのだ。

今回はCrossworkのその仲間たちとそのＸＮＡで使用するサンプルであるSOFTIMAGE_XNAViewerを使ってマテリアルにシェーダーを設定したモデルを表示しようと思う。

続きを読む "SOFTIMAGE_XNAViewer"

TimeBomb（ゲームデータ化？）

Noesisの時限爆弾作成チュートリアルを最後まで完了いたしました。

ただ、チュートリアルそのままだと、あまりにもしょぼーんなデータができあがってしまったので、少し工夫してみました。

続きを読む "TimeBomb（ゲームデータ化？）"

[XNA]:XSI 6 Mod Tool

　そろそろXNAで3Dグラフィックあたりを触ろうかな…と思ってサンプルモデルどーしよ？と思っていた矢先…XNA Creators Club Onlineのトップページにこんなニュースがありました。
　SOFTIMAGE|XSI Mod Tool Now Plugs In To XNA Game Studio Express　…お、XSI Mod Tool用のXNAプラグインでもできたかな…？そりゃーうれしい…と内容も読まずにそのプラグインとやらを探すこと数分間…。ない。そんなものない。

　…しかし、XSI の（英語の方ね）XSI Mod Tool のページが以前より華やかになっている気がする…。 　それとNoesis（メーカーか何かの名前なのかな？）のチュートリアルでXSI Mod Tool の使い方を覚えよう…といった内容がちらほら。

　…うーん、XSI Mod Tool ごとまたダウンロードしなきゃいけないのかなぁ…以前すでにダウンロードしてインストールしてあったので気が重い。

　まぁそれでもとダウンロードしようとダウンロードページまでたどり着いてアンケートみたいなのに答えていくと、その中に「ちみは どのゲーム環境で Mod Tool を使う予定だい？」という答えの選択肢の中に

　XNA -> PC
　XNA -> XBox

という欄が…。（以前からあったっけ？）

　ちょっとだけ期待してダウンロード後、インストール。
　ツールが立ち上がった後（しまった、内容覚えてないや）、ダイアログが出てくるので、ＯＫを押す…。（多分これであってる。）

　何かをダウンロードかインストールしている内容のプログレスバーが出たあと、無事終了っぽい。

　ディスクトップに作られたショートカットアイコンを見てみると XSI 6 Mod Tool と…あ、バージョンアップ？ＵＩフェースも昔のものと比べて全然違うし、メニューバーに XNA Game Studio の欄が。

　後で調べてわかったことだけど、FBXとかシェーダーとかそういったものをサポートするようになったっぽい。
　吐き出せるのは64000ポリゴン（三角形）までで、商用利用不可。
　あとレンダリングについての制約がちょこっと。
　法線マップとかの解像度が512x512まで（ＵＶしっかり吐いてるんだろうから、XNAで使うときに高解像度のやつに差し替えればいいんじゃ…？）。

----------
　8/18 12:19 追記 - 日本のXSIサイトできちんと英語だった XSI 6 Mod Tool の紹介ページが日本語訳されて掲載されてた。
　そこにはこうある。
　Ultimapper を使って作成するマップの最大解像度は512x512です。
　ハードウェアレンダラを使った画像出力の最大解像度は512x512に制限されています。
----------

　それとXSIファイル自体をXNAのコンポーネントとして登録して描画できるらしい。

　…ちょっとすごくねーか？やるなーXSI。M○○aの使えん試用版とは大違いじゃ（勉強する分にはいいんですが）。

　さて、いろいろ"XSI Mod Tool XNA"で検索して調べているとLAGさんのブログでSOFTIMAGE_XNAViewerというものについて知った。
　これついて記載しておく。

　これは私の感じたところXNAでXSIファイルのインポートと描画のサンプルプロジェクトっぽい。
　試すにあたってちょこっと改変した。

　まず、原本をいじるのはいやなので、フォルダごとコピーします。
　フォルダは XSI 6 Mod Tool をインストールしたフォルダ以下のAddons\XNAGSE\Dataの中にあるXNA_SAMPLESってやつです。

　どっか適当な場所にコピーしたら（私は念のため日本語を使わない場所にいつもしています）フォルダの中にあるソリューションファイル（SOFTIMAGE_XNAViewer.sln）をダブルクリックしてXNA環境を立ち上げましょう。

　すでにコンテントの中にはサンプルのXSIモデルが入っているのですが、このままビルドすると参照しているシェーダーファイルが無いよんとコンテント・パイプラインのエラーで止まります。
　どうもファイルの中の外部ファイルへの参照パスがT:\\Storm\\src\\XNA\\SOFTIMAGE_XNAViewer\\Content......とかになっているのが原因のようです。

　なので xsi_logo.xsi ファイルを開いて"T:\\Storm\\src\\XNA\\SOFTIMAGE_XNAViewer\\Content"という文字列を".."で全置換してしまいましょう。

　次にソリューションプラットフォームがMixed Platformsになっているので、お好きな環境にセットします。

　

　そしたらいつもどおり、ビルドして実行しましょう。
　XSIのロゴ（？）の丸い球体が出たら成功です。（たぶん）

　ただ私の環境だとアスペクト比が変です。
　なのでこの部分

// - Game1.cs 471行目あたり -
// float aspectRatio = 1.3333333f; // graphics.GraphicsDevice.Viewport.Width / graphics.GraphicsDevice.Viewport.Height;
float aspectRatio = (float)graphics.GraphicsDevice.Viewport.Width / graphics.GraphicsDevice.Viewport.Height;

と変更します。（コメントアウト部分をそのまま使うのではなく、floatでキャストするのをお忘れなく）

　それともっと高解像度にしたければ

// - Game1.cs 44行目あたり -
// use this for 720P
graphics.PreferredBackBufferWidth = 1280;
graphics.PreferredBackBufferHeight = 720;

// for NTSC, use a 4:3 ratio
//graphics.PreferredBackBufferWidth = 720;
//graphics.PreferredBackBufferHeight = 480;

なんて変えればＯＫです。
※どっちもコメントアウトで用意されてた…

　あと操作方法ですが、UpdateGamePad() メソッドを見ればわかると思いますが

　START + BACK … 終了
　START … アニメーション再生・停止
　BACK … アニメーションのリセット
　左スティック押し込み … カメラのリセット
　十字キー右 … アニメーションの切り替え
　Lトリガー … ズームアップ
　Rトリガー … ズームダウン
　Lボタン … カメラの移動（前）
　Rボタン … カメラの移動（後）
　左スティック … 視点を中心に回転移動（始点を向いたまま）
　【↑これちょっと自信ない】
　右スティック … カメラの移動（上下左右）

です。
　ぱっと見、フォンシェーディングと法線マップによるバンプマップが確認できます。
　それとソースコード見てみると…アニメーションのブレンドしてるかも。

　自分のモデルとか表示できるように、XSI 6 Mod Tool 勉強しますかね。
　今のところ、XNAのプラグインで発見した内容に、モデルの診断機能があるらしく

　１つのモデルの最大ボーン数 … ５８
　１つの頂点に対して影響するボーンの最大数 … ４

と設定されていました。
　１つのモデルの最大ボーン数の５８っていうのは、なんとなく見に覚えがあって、たしかシェーダーのレジストリにのっけられる変換マトリクスの配列数の最大がそれくらいだった気がする。

　以前大蛇のような蛇のモデルとかスカートふりふりの女の子のモデルを（両方ともアニメーション付き）ＸＮＡで表示しようとしたら、その制約にひっかかって表示できなかったんだよね…。

　その制約はずすためには、どうしたらいいんだろう？
　ＣＰＵ側でマトリクスの変換してからシェーダーにデータ渡せばいいのかな？
　…あぁ、頭がまわらん…歳のせいかしら？？？

[XNA]:文字列描画 その４

　まず、設定ファイルであるXMLだけど、正直XMLから作ることがボクにはできない。

　XMLがまったくわからない…というわけではないが、苦手。

　なのでシリアライズして出力してしまおう。

　幸いにもひにけにさんのサンプルにもシリアライズ用のメソッドが用意してある。
　※TextMessageDescriptionクラスのTestWriteメソッド

　では先にTextMessageDescriptionクラスを改変してしまおう。

　今回、.spritefontファイルは廃棄して、設定用のXMLファイルに統合する。
　なので.spritefontに記載されていた内容と同等のデータの受け口を用意しなくてはいけない。

　それと、私はどうもサンプルのXMLで一番好きになれないのは【ExternalReference】がごちゃごちゃ感をかもしだしている部分だと思った。
　そこで、ExternalReferenceという記述をXMLから廃棄したいのだが、ひにけにXNAさんにも書かれているようにファイルの依存関係がらみで必要なようなのだ。
　…ようなのだ…というのは…実はいろいろ調べたがExternalReferenceというやつがイマイチ理解できなかった。

　そこでTextMessageProcessor内でファイル名を素直に受け取って、ExternalReferenceのインスタンスを生成して、受け取ったContentProcessorContextクラスオブジェクトのBuildAndLoadAssetメソッドを呼ぶ流れに持っていこう。

　TextMessageDescriptionクラスが思惑どおりに改変（当然TestWriteメソッドも含む）できたら、TestWriteメソッドを使って、サンプルXMLを出力しよう。

　私の場合、めんどくさかったので(1)SampleWinプロジェクトの参照設定にPipelineプロジェクトを入れる。(2)いちばーん始めに実行されるであろうProgram.cs内のMainメソッド内に

TextMessageDescription.TestWrite("test.xml");

とファイルの先頭あたりに

using Sample.Pipeline;

と記述する。

　おそらく、プログラムを実行するとエラーになるだろうが、この部分がとにかく実行されれば【\Sample\bin\x86\Debug（\Release)】あたりにXMLファイルが出力されているはずだ。
　出力されたXMLを元に実験用の設定を書いてコンテントとして登録しておく。
　※Content Importer は XML Content　Content Processorはテキストメッセージプロセッサ
　※XNA Framework ContentをTrueにしないと上記の設定は出来ないので注意しよう。

　あとはTextMessageDescriptionクラスにあわせてTextMessageProcessorの内容を書き換えればいい。

　ちなみに私はC#なんかぜーんぜん書いたことがないのでフィーリングで改変している。あしからず。

　やはり、XMLの内容は断然すっきりした。勝因はやはりExternalReferenceをXMLに書かないことにある。
　XMLファイルに記載しないで、今回のようにソースコード（プロセッサ内）に書くことによってどんな弊害がでるのか？（それとも弊害がないのか？）は、今のところさっぱりわからない。
　改変が完了した状態で実験したが、ファイルの依存関係はばっちりで、登録されたテキストファイル・ソースコード・設定ファイルのXMLのいずれかが改変さた状態でビルドすると、きちんとXNBファイルを作り直してくれる。

　今回の実験のおかげでコンテント・パイプラインの流れが、もう少し詳細にイメージできるようになったかな…と思う。

　そろそろ、フォントまわり（コンテント・パイプライン）あたりから離れて、楽しそうな３Ｄ表示あたりをいじってみようかな。

今回のサンプルはこちらから↓
「TextMessageSampleNext.zip」をダウンロード

※今回のサンプルは「ひにけにXNA」さんのサンプルを改変したものです。

[XNA]:文字列描画 その３

■ファイルの外部参照を極力やめたい。
■ＸＭＬがごちゃごちゃしていて生理的にイヤ。
■複数のファイルを読み込みたいときは？

　残りのこれらをやっつけていくにはもう少し考察が必要だと思うので書いてみた。
　お付き合い願いたい。

　経験からいって、設定ファイルだの、データファイルだのというのは、極力まとめられるものはまとめた方がいい。
　外部参照するにしろ、それは必要があってのことだし、ソースコードではない…つまり切り分けた外部ファイルっていうのはプログラマ以外の役職の人が触ることが多い。
　たとえ一人でゲームを作っているにしろ、ファイルを作る手間は少ない方がいいし、管理のしやすさとか、シンプルさはある程度必要だろう。

　切り分けるか、分けないか、悩んだときはコストの安い方を選ぶ。

　そんなとき、ＸＮＡでは「すでにXMLインポーターがあって、これくらいのデータ読むならXMLの方がいい」っていうのは判断材料の１つ。

　正直、多くの人はおそらく『XMLはきらい』ではないか？

　理由はたくさんあるけど、ごちゃごちゃカッコだのスラッシュだのと少しくらいならいいが、あんなに多く書きたくはない（よね？）。

　たとえばこんな内容の設定ファイルはどうだろう？

[Font]
FontName = "MS Gothic";
Size = 26;
Spacing = 4;
Style = Regular;

[Files]
MessageText.txt : shift-jis;
test1.txt : utf-8;
SampleGame.cs : shift-jis;

[Data]
DiscardMessage = No;

　もっといい書き方もあるだろうが、普通これくらいでいいじゃないか。

　では、何が悲しくてXMLなのか？それはやはりプログラムを組むコストの問題である。

　プレーンのテキストにオリジナルのルール（フォーマット）にのっとって設定を書いた場合、そのフォーマットを読み取るプログラムを組まなくてはいけない。
　それは文字列の解析から始まって分割、そしてフォーマットからデータに落とす（詰める）という機構すべてを書かなくてはいけなくなるだろう。
　その上、設定ファイルが必要になるたびに新しいフォーマットを考えたり、またそのために解析部分を書いたりと、たとえ流用部分があったとしても、結構コストがかかる作業になるのではないか？

　その点、XMLはもう全世界共通のフォーマットである上に、XNA(C#?)にはすでに解析（パース）する機構が存在しているのだから、利用しない手はない…というわけだ。

　その仕組みはこうだ。

　SampleMessage.xmlの内容はTextMessageDescriptionクラスの内容をシリアライズしたものだ。

　なので、予想ばっかりで申し訳けないのだが、XMLインポーターとはXMLの内容を設定されたクラス型のオブジェクトへデシリアライズするものなのだと思う。

　プロジェクトに登録されたContent内のSampleMessage.xmlのプロパティを見てみればわかるが、このファイルをXMLインポーターでインポートした後、そのデシリアライズされたオブジェクトはTextMessageProcessorへ送られる。

　TextMessageProcessorは受け取った（TextMessageDescriptionクラス型の）オブジェクトのデータを元に、TextMessageContentクラス型のオブジェクトへ一生懸命データを詰める作業をする…といった流れだ。

　ちなみに、データの詰め終わったTextMessageContentクラス型のオブジェクトはオーバーライドされたWriteメソッドが呼ばれ、ContentWriterクラス型オブジェクトのメソッド（WriteObject）を使ってファイルに出力する。

　それが今回のXNBファイルというわけだ。（…なんじゃないかと…思う。しっかり調べないで憶測ばかりでごめん）

　これらの考察から今回の実験では読み込む設定ファイルはXMLとし、「.spritefont」ファイルの内容と、どのファイルの内容をフォント化するか？のファイルリスト（つまり複数ファイルに対応）とDiscardMessageのフラグにもきちんとそのまま対応できるように作ろうと思う。

　あと、できれば、もう少しXMLファイルをシンプルにしょう。

《その４につづく…》

[XNA]:文字列描画 その２

　ひにけにさんの【Content Pipeline その３ そのカスタマイズ】はフォントの取り扱いについてもコンテント・パイプラインってなんぞや？といった点についても、とてもすばらしい記事・サンプルだった。

　しかし、実際実用的に使うことを想定すると疑問やこだわりも出てくる。

1. ファイルの外部参照を極力やめたい。
2. ＸＭＬがごちゃごちゃしていて生理的にイヤ。
3. ソースコードを実際に読み込んでデバック文字として使えるのか？
4. 複数のファイルを読み込みたいときは？

　とりあえず、上記についてひにけにさんのサンプルコードをちょこちょこといじってみよう。

■ソースコードを読み込んでデバック文字として使えるのか？

　ためしにやってみりゃいい…とサンプルの中にあるSampleMessage.xmlを編集する。

<ExternalReference ID="#External2" TargetType="string[]">MessageText.txt</ExternalReference>

　この部分がMessageText.txtを指定している部分だと容易に想像できる。
　MessageText.txtはContentフォルダに入っているので、おそらくContentフォルダからの相対パスで問題ないはずだと予想してこうしてみる。

<ExternalReference ID="#External2" TargetType="string[]">../SampleGame.cs</ExternalReference>

　それとTextMessageProcessorでは外部参照しているファイルをどのインポーターにかませるかを判断するのに拡張子とインポート後の型から判断している（と思う）。
　TextMessageProcessor内で強制的にTextImporterを使う設定にすることもおそらく可能だが、はやく確認しちゃいたいのでTextImporter.csの拡張子を設定している部分を変更。

// - TextImporter.cs 15行目くらい -
// [ContentImporter(".txt", DisplayName="UTF-8 テキストファイルインポーター")]
[ContentImporter(".cs", DisplayName="ソースコードインポーター")]

実行結果

　ありぃ？日本語がでにゃい…？？？
　もしやと思い、ソースコードの文字コードを確認してみる。
　shift-jis…Unicodeじゃないの？このサンプルコードだけ？…ってわけでもなさそう。
　そうかぁ、ソースコードはshift-jisで編集・保存されてるんだに…。

　じゃー shift-jis から Unicode にどっかで変換してあげなくちゃいけない…
　変換とくれば当然インポーターだろうか。
　サンプルのパイプラインの流れはインポーターで変換対象であるファイルの文章を文字列型の配列に変換してそれを空白行単位の文字列型配列に変換するのと、FontDescriptionProcessorにくわせるためにFontDescriptionの中の文字リストへ文字コードをつめる作業の２つに分かれる。
　どちらもUnicodeで取り扱うべきものなので、ファイルを読み込み時すぐにUnicodeに変換しちゃうのが効率いい。

// - TextImporter.cs 31行目くらい -
// using (StreamReader sr = File.OpenText(filename))
using (StreamReader sr = new StreamReader(filename, System.Text.Encoding.GetEncoding("shift_jis")))

実行結果その２

　もし実際にこのままデバック用文字フォントを生成するなら、サンプルそのままのTextImporter.cs とは別に、上記のようなソースコード用の…たとえば SourceCodeImporter.cs とでもしたインポーターを作るだけで、拡張子からそれがソースコードかテキストか自動で判定して上手い具合に通るだろう。

　ちなみにその際、TextMessageProcessorにくわせるxmlファイルには

<DiscardMessage>true</DiscardMessage>

とDiscardMessageフラグを立ててあげれば、文字列データに含まれることなくフォントデータを生成することができる。

　これで無事ソースコードをくわせてデバック用文字フォントを生成することができた。

《その３につづく…》

[XNA]:文字列描画

さて、ゲームプログラムにしろ別のプログラムにしろ、デバックしたりなんだりで便利なのは文字列の描画だ。

どのXNA関連のブログやらHPやらではXNA Game Studio Express (以後GSE）1.0 Refreshで文字列描画の機能が追加されたとある。

特にXNA愛好家が愛読している（であろう）「ひにけにXNA」さんには日本語等の取り扱いを便利にするコンテント・パイプライン（カスタムインポーター・カスタムプロセッサ）についての解説がなされている。

このコンテント・パイプラインというやつは、おそらく私たち開発者が日ごろ行なっているmake作業のリソース部分を表しているようだ。
代表するならプログラムをビルド（コンパイル・リンク）するときにmakeやantを使うとしよう。
その中によくリソースのデータコンバート部分を含めることが多い。
その主な内容はコンバータやシェルスクリプト等の起動だったりするわけだが、それに近いことをC#で書いてやってしまおうといった感じに受け取れた。
最終的なコンバート作業をインポーター・プロセッサといったもので実行し、XNBというファイルにすることでどんなリソース（コンテント）も共通した方法（アセット）で取り扱いましょうということらしい。

おそらくサウンドだろうが３Ｄモデルやそのアニメーションだろうが、テクスチャだろうが、ゲームスクリプトだろうがこのXNB（※たぶんこれがアセット？）ってやつにして取り扱うんだろう。
そんで独自のフォーマット等を取り扱いたいときにインポーターやプロセッサ部分を書いてねん…ってことなんだな…きっと。
※不便なようで便利な…けど、ある程度の制約がある方がやれることが多くて自滅するよりかはいいか？と思う。

さて、いきなり「ひにけにXNA」さんのようなカスタムインポーターやプロセッサ部分を書いてしまうのもありだけど、文字列描画の基本を知ってからのほうが、きっと問題点やその理由をきっと理解しやすいだろう。

文字列描画の基本については「ん・ぱか工房」さんの「XNA Game Studio メモ」の「はじめてのXNAアプリの作成」にすでにあったので、「どうしたらいいのかもわかんね～」という方はそれを参照しながらならなんとかいけると思う。

私もWindows版のサンプルを作成してみた。

「FontSample4Win.zip」をダウンロード

一応２種類のフォントを取り扱ってみた。

それとまぁフォントを取り扱うクラスでよくあるんだけど、LineSpacingというSpriteFontクラスのメンバ変数はフォントを描画する上での行の高さらしい。結構行間も空くので、おそらくそれも含まれた高さなんだろう。

ビルドしてみて、できあがった.xnbというファイルにも注目してもらいたい。
アルファベット＋日本語カタカナのMS UI Minchoの方はだいたい264KB。
フォントのサイズも14ポイントと結構小さめなのだが、これでひらがなや漢字を追加するとなるとかなり大きくなるのではないかと予想する。
もっと大きなフォントを使いたいときはポイント数を上げるという方法もあるが、ためしに92ポイントという大きさのフォントを設定して.xnbを作成してみると約8MBのファイルが出来上がる。
小さいフォントを作成してSpriteBatchクラスの拡大で画像的に耐えられるなら、そっちの方がファイルサイズとメモリの節約になるだろう。
※私がいままでWindowsのゲームを作成するときのフォントは必要な文字列を抽出して、16階調のαデータ（つまり１ピクセル4ビット）を１バイト２ピクセル分につめてデータ化したものを必要なときにテクスチャに展開して使用していた。
そのデータを使えるようにするのも楽しそうだが、良く考えてみるとフルＨＤとか騒がれている昨今、１６階調のアンチの効いたフォントくらいじゃ、もしかしたら粗が目立つのかもしれない。
この.xnbにはおそらくフォントがBMP化されたものとその他もろもろのものが入っている（と思う）。
このSpriteFontのロードとアンロードは好きなときにできるようだから、必要なシーンでローディングをはさめば、テクスチャメモリの方はなんとかなる…よね。※この仕組みでか○い○ち級のノベル系アドベンチャーの時は心配かも

おそらく問題となるのはディスク格納領域…つまりゲーム自体の容量の問題につながる。
ゲーム自体の容量制限については調べてないのでわからないが、XBOX360に転送する過程を考えると小さいにこしたことはないだろう。
それに学生たちがコンテストなんかに参加しようとすると、コンテストの規約で「インストールされた状態で２００ＭＢ以内ね」とちゃんと制限されていたりする。
フォントの他にもサウンドだってグラフィックだってあるし、それらのデータ量は大きい。
なんで、ぽんぽこSpriteFont用の.xnbを作成するわけにはいかない。
最終的には圧縮かな…と思っていたらこんな方がいらっしゃった。
まぁ、まだまだ気にするレベルにも達していないので、もし容量でなんかあったら参考にさせてもらおう。（学生は容量に関しては無頓着なもの）

ここまでで、「ひにけにXNA」さんのような方式を導入する前に自分で感じる部分をまとめると
・.spritefontファイルの作成は自動化すべき
・使い方はそんなに難しくない
・出来上がる.xnbファイルは容量がデカイ（きがする）
・ロード・アンロードは容易。

自動化の部分は
・ソースコードで使われているデバック文字を.spritefontファイルにする。
・たとえばシナリオスクリプトから文字を抽出して.spritefontファイルにする。
とかできればいいのかな。

[XNA]:XBOX360での実行

突然だが、職業上逃げることができなくなったXNA。
けど本当に良くできていて、CやC++でDirectXなプログラムをゴリゴリ書いていた自分が数日むなしくなるような…。※いや、必要なんだけどね。

ってなもんで、XNAを真面目にやろうと、面白いし、久しぶりにワクワクしたし。

今はまだ別件の外注作業の方が優先なのだが、これの研究開発にもお金が出ているので、平行して２０％くらいはこれをやらなきゃいかん。※私のＣＰＵはいっぱいいっぱいの気が…。これ以上スレッド立てたらパンクですわ。２スレッドが限界か？しょぼ…。

とりあえずサンプルは充実しているし、こぞって色々な人が参戦模様をブログ等で公開してくれているので、情報には困らない。

さて、ある日のこと。※って昨日じゃん
研究開発要請元から「XNA Creators Club」なるものの年間メンバーシッププリペードコードが送られてきたので、今までＰＣ環境で実験していたサンプル等をXBOX360で実行してみることにした。

ちなみに開発環境は整えられ、XBOX360とPCはすでに繋がっているものとする。
ＰＣとデータを共有して音楽やムービーが見れる状態がそれだ。
Windows Media ConnectってやつがＰＣ側にインストールされていることが条件に入るが、私の場合はWindows Media Player 11(以後WMP11) の共有機能がそれにあたるらしいので、WMP11のオプションを開き、「ライブラリ」タブの「共有の構成」あたりを設定したと思う。
それと、たしかWindows Live IDやXBOX Liveのメンバーシップの登録等、XBOX360側のアカウントがしっかりしていないとダメだったと思う。
詳しくはＸＮＡ関連の正式なホームページや他の方々の書き込みを読んで欲しい。

まずはXBOX360側をいじる。※内容は2007/5/23現在
XBOX360の電源を入れてダッシュボードを表示する状態にする。
マーケットプレースというタブ（？）のゲームを選択。
ジャンル→その他と選択して行くと「XNA Creators Club」という項目があるので選択。
あとは、XNA Game Launcherを選択してダウンロード＆インストールしよう。

ここで「XNA Creators Clubメンバーシップ」を購入することもできるので必要がある人はXNA Game Launcherを入れる前に、購入・登録しておくべし。
※私の場合はすでにプリペードコードを研究開発要請元からもらっていた。
ちなみに、私と同じようにプリペードコードをいただいて始める方は、同じくマーケットプレースの右下あたりに「ご利用コードを使う」という項目があるので、そこを選択し、プリペードコードを入れれば、めでたくアカウントにXNA Creators Clubメンバーシップが追加される。

XNA Game Launcherがインストールされたら、ダッシュボードの「ゲーム」タブ（？）の「デモなど」という項目を選択。
ここにXNA Game Launcherの項目があるはずなので選択して、次に「始める」を選択する。
これでXNA Game Launcherが立ち上がるはず。
私の場合は立ち上がった初回、選択できるのはSettingsの項目だけだった。
なのでSettingsを選択する。
「Generate Connection Key」を選択して表示されたkeyをメモする。
XNA Game Launcherの先頭に戻って、「Connect to Computer」を選択して、ＰＣからの待ちうけ状態にする。
これでXBOX360側の準備はOKのはずだ。

次にPC側。
動く、XBOX360版（くれぐれもWindows版ではない）のXNAプロジェクトをなんでもいいのでXNA Game Studio Express(Microsoft Visual C# 2005 Express Edition)で立ち上げる。
ツール→オプション→「XNA Game Studio Express Xbox 360」を選択して「add」ボタンを押す。
するとダイアログボックスが立ち上がるのでConnection Keyのところに先ほどメモしたものを入れる。
このとき「Xbox 360 Name」という項目があって、私は？だったが、とりあえずXBOX360で遊ぶときのサインインするときのアカウント名（ゲーマータグ名？）を入力した。
そして「Test Connection」ボタンを押す。
すると接続に不具合があった場合Statusの部分に英語で色々言ってくるので、読みながら設定して行く。
私の場合は最初「つながんねーよ」みたいなわけわからん内容だったので再度Test Connectionボタンを押したらきちんとXBOX360をローカルネットワークから発見してくれて、Status部分に「TCPのポート1001あけてちょ」と英語で書いてあったので、Nortonのファイアウォールの設定でローカルIPでの通信に限りポート1001での通信を許可する設定をする。
その後、再度Test Connectionボタンを押すと無事繋がった。
無事繋がるとOKボタンが有効になるので、それを押して設定を終了する。

あとはプロジェクトをビルドして実行すればXBOX360と通信してデータをXBOX360側に送信完了後、めでたくXBOX360で動き始めるはずだ。

ちなみに、XNAで製作したものはパッケージにして配布することが可能で、その場合もXBOX360側を受け待ち状態にしてからunpacボタンを押せば、XBOX360側にデータが送られる。

プロジェクトで実行してもパッケージをインストールしても一度データが送られたものならXNA Game Launcherの「My Games」の項目を選択すれば、ＰＣと繋がっていなくても実行できるようになる。
不必要になったものも、ここから選択して削除しないと、どんどんXBOX360側のハードディスク容量が減っていくことになる。

私の場合はざっとこんなもんだった。
ゲーム機開発は散々やってきた私でも、実機で何か動くとうれしい気がする。
学生たちがこれを経験したとき、感動してもらえるんじゃないかと今から楽しみだ。
※あっ、これじゃー研究開発要請元がわかっちゃうね。