あいてぃーとふぼふ

DroidForKinectSample限定公開!

以前の記事で作成したKinectアプリのサンプル「DroidForKinectSample」を、夏コミで配布しようと思っていたのですが、バージョンアップしたKinectのSDKに同様のサンプルが同梱されるようになったため、もうモチベーションが下がりニーズはないだろうと思い、公開を見送っておりました…(T△T)

ですが、ありがたいことに沢山のお問い合わせをいただいておりますので、同人誌をご購入いただいた方々を対象に、本サンプルのソースコードを公開させていただきます!ということで、まずは本サンプルのポイントから解説させていただきます~(≧▽≦)/

プロジェクトの構成は?

まずは、KinectのSDKに付属している純正のサンプルコード「Avateering-XNA」の構成をご覧ください(右図)。たくさんのソースコードがあって、何やらとても高度であろう印象を受けますが、私個人としては、こういうサンプルは読む気がしません。色々と機能を付加するのもいいですが、サンプルである以上、やはり理解しやすいことが大切だと思うのです…。

そこで、今回公開するサンプル「DroidForKinectSample」は、理解しやすいようにシンプルな構成にしています(左図)。とはいえ、膨大な行数のコードを無理やり集約しているわけではなく、余計な機能を極力省き、キネクトで3Dモデルを動かすために必要な処理のみを簡潔に実装しています。ちなみに、このサンプルは「Avateering-XNA」が公開される前に作成したものですので、アルゴリズムは異なるものの、プロジェクトの構成は偶然にもほとんど同一となっています。

まず「SkinnedModelPipeline」と「SkinnedModelWindows」は、純正のサンプルにも含まれているプロジェクトです。これらはもともと「スキニングモデル」というサンプルのソースコードを流用したものであり、人体の様に繋ぎ目のない関節を持つ3DモデルをXNAに取り込めるようにするためのプロジェクトです。今回利用するドロイド君の3Dモデルも、一部の関節に繋ぎ目がありませんので、これらのプロジェクトを利用します。

次に「DroidForKinectSampleContent」は、ドロイド君の3Dモデルを格納しています。この際、3Dモデルのプロパティから、先のプロジェクトで定義した「SkinnedModelProcessor」を指定します。

ということで、残る「DroidForKinectSample」がメインプロジェクトです。

DroidForKinectSampleプロジェクトの内容は?

まず「Program.cs」は、エントリーポイントを保持するだけのクラスです。次に「MainGame.cs」は、XNA経験者であればお馴染みのUpdateメソッドとDrawメソッドを定義したクラスです。この際に特筆すべきは、90行目付近で3Dモデルが持つボーンの番号を列挙体にマッピングしている点です。ボーンとは、3Dモデルを動かすために定義する骨の事であり、3Dモデルごとに異なるボーンの番号をここでマッピングすることで差異を吸収しています。

他にも「CameraHandler.cs」は、キーボードで視点を操作するためのクラスですので、不要なら削除しても問題ありません。また「SkeletonHelper.cs」は、キネクトの骨格データを左右反転させる(鏡で映したようにする)ためのクラスですので、削除したところでモデルの動きが左右逆になるだけの些細なクラスです。

ということで、肝となるのは「AvateerHandler.cs」です。

AvateerHandlerクラスの内容は?

AvateerHandlerクラスのAPIはシンプルで、UpdateメソッドとDrawメソッドがMainGameクラスから呼び出されるようになっています。この中で、キネクトの骨格追跡機能から得られる20個の「関節」の3次元座標を、3Dモデルの「ボーン」にマッピングして動かします。具体的には、隣接する2つの関節(例えば肩と肘、肘と手首など)とボーン(例えば上腕、前腕など)をswitch構文で関連付けて、ボーンの初期ポーズに関節の移動量を合成することで3Dモデルを動かします。マトリックスやクォータニオンなど、若干難しい技術を利用してはいるものの、コメントを含めても250行程度ですし、その内の100行くらいはswitch構文ですので、比較的読みやすいソースコードになっていると思います。

ただし、今回のサンプルはドロイド君の3Dモデルの初期ポーズ(両手両足を垂直に下した状態)を前提に作成しています。このため、各ボーンの初期ベクトルをVector3.Downに決め打ちで実装していますので、初期ポーズがドロイド君と異なる3Dモデルを利用する場合は、この初期ベクトルを修正する必要がある点に留意してください。

ドロイド君の3Dモデルは?

なお今回は、ソースコードの他にも、ドロイド君のボーン入り3Dモデルを同梱しています。3Dモデルは、「メタセコイア」というモデリングソフトで作成しており、Metasequoia専用のプラグインである「Keynote」を用いてボーンを設定しています。また、「FBXエクスポーター」 というプラグインにより、ボーン入りのFBXファイルに変換してXNAで利用します。ただし、これらのプラグインを利用するためには、有償のメタセコイア (5000円)を使用する必要があります。なお、キネクトから得られる関節の座標は20個となっていますので、キネクトで動かす3Dモデルを作成する場合は、このドロイド君の様に15本のボーン(=20個の関節)で構成するとマッピングしやすいです。

ダウンロードはこちらから!

ということで、同人誌をご購入いただいた方への感謝の気持ちを込めて、ソースコードと3Dモデルを公開させていただきます。ダウンロードしたファイルは自己解凍形式のEXEファイルで、パスワードを入力することで解凍できます。パスワードは、「デベロッパーズハウツー3」の最後が「何オチ」であったかを、漢字二文字で入力してください(最後のコマを参照)。なお、ソースコードを利用したことによる一切の責任は負いかねますので、あらかじめご了承ください。

DroidForKinectSampleをダウンロード

それでは、この度は同人誌をご購入いただき、誠にありがとうございました~!。゚(゚ノД`゚)゚。

Visual Studio 2012 Express!

いよいよ、待ちに待った「Windows8」と「Visual Studio 2012」のRTM(製品版)が、MSDN会員向けにリリースされました~!…が、私はSubscriptionが切れていたことをすっかり忘れていたため、この恩恵にあやかることが出来ず…(T▽T)

ですが!そこは天下のMSさん!なんと無償で評価用のRTM版Windows8Windows 8 evaluation for developers」と、これまた無償のVisual Studio 2012Visual Studio 2012 Express」を同時に公開してくれました!ということで、私はこれらを用いて、取り急ぎVisual Studio 2012 Expressを触ってみた感想をご報告します~!(*≧▽≦*)

RTMはRTMで!

ちなみに、Windows8のReleasePreviewに、RTM版のVS2012Expressをインストールしようとすると、「このコンピューターにインストールされている.NET Frameworkは、最低限必要なバージョンを満たしていません」エラーが発生します。これを回避しようとして、同じくRTM版の.NET Framework 4.5を単体で入れようとしても、「Microsoft .NET Framework 4.5は、既にこのオペレーティング システムにインストールされています」エラーが発生してインストールできません。このため、RTM版のVS2012Expressは、RTM版Windows8にインストールしましょう!

インストーラーはびろーんでぴかぴか!

まずはVisual Studio 2012 Expressのインストーラ-について一言。インストーラーのUIデザインは、その時々のトレンドが反映されていたりして、個人的に色々と参考にしていたりします。ですが、今回ばかりはそうもいきません。だって、インストーラーの同意チェックをオンにすると、インストールボタンがびろーんって出てくるんですよ。

なんですか、このびろーんって?しかも、インストールが完了した後に至っては、起動ボタンがピカピカしてるし。なんだか昔のアングラサイトを思い出します。一回りして新しい?なんだかちょっと、やだな。(´・ω・`)

デフォルトはまっくろ!

そんなこんなで、インストールしたVS2012Expressを起動するとデフォルトで画面が真っ黒です!一瞬、Blendを起動したのかと思ってしまいます。どうやら、オプションから設定できる配色テーマがデフォルトで”濃色”になっているようですので、これを”淡色”に変更すれば、白を基調としたいつもの見慣れた配色に戻ります。でも、メニューやウインドウに関して言えば、濃色の方が若干見やすいような気もしますが…。ともあれ、MSさん的に、これからはCUIチックなのがタイポグラフィだぜ!ってことでしょうか?(´-ω-`)

私上最悪のプロジェクトテンプレートェ…

個人的に、RTMに期待していた事柄のひとつに、プロジェクトテンプレートの修正があります。RC版のVS2012Expressに用意されたプロジェクトテンプレート(GridAddとかSplitAppなど)は、そりゃもう本当にヒドイ構成で、出会いがしらに開発意欲をへし折られます。

具体的には、プロジェクトテンプレートが生成するクラスにVS自身がベッタリネッチョリ依存しています。どういうことかと言いますと、テンプレートからプロジェクトを生成すると、やたらたくさんのクラス(Commonフォルダ)が生成されるんですが、その状態ですでに各ページクラスが上記フォルダ内の独自の基底クラス(LayoutAwarePage)を継承していたりします。さらに、休止中の状態を管理する、これまたCommonの独自クラス(SuspensionManager)を内部で参照していたり何だり…。とにかくもう混沌(ニャル子)です!

しかも挙句の果てに、それらのクラスを削除したり名前を変更しようものなら、VSから新規にページを追加しようとした際に「テンプレート君が用意してくれているはずのCommonなクラスが見当たらないけど、僕が追加してあげようか?断るならビルドが通らなくなるけど、名前空間とか自分で解決してよね?ぷぎゃー!m9(^Д^)」的なメッセージ!お前らどんだけベッタリなんだよっ!orz

他にも、なんか中途半端にMVVMだし、ビューモデルがObservableDictionaryクラスだし、不満を上げたらキリがないです。プロジェクトテンプレートは、あくまで”テンプレート”なのであって、決して”サンプル”じゃないはずです。それなのに、VS2012とプロジェクトテンプレートがグルになって、オレオレクラスを使わせようとするこの感じ。まぁ確かに、これらのクラスは便利です。けれど、だったら最初からBCL(ベースクラスライブラリ)に組み込んでおいてくださいよ!って話ですよ(○`з´○)

ということことで、RTM版で修正されることを期待していたのですが、願いかなわず。トホホ。。。…とまぁ、何だかグチっぽくなってしまいましたが、もちろんVS2012Expressにはグッジョブなポイントもあります。例えば、自動単体テストがExpress版でもサポートされたことなどは、本当にグッジョブです!

…ところでMetroは?

ところで、「Metro」という名称をやめるという話を聞いてはいるのですが、ヘルプやMSDNライブラリなどで未だに「Metro」を見かけます。結局やめるの?やめないの?(T△T)

Kinectでドロイド君を動かそう!(その2)

前回からはじめたこのシリーズも、いよいよ今回が最終回です!∑(´゚Д゚`;)
ということで、こんな感じのサンプルになりました~(*≧∀≦)ノ

普通に扱いやすいです!

本当はもう少し続く予定だったんですが、とりたてて問題もなく完成してしまいました(汗 もちろん、ご覧のように紆余曲折はあったんですが、原因はどれも計算ミスによるものだったので、割愛させていただきます。キネクト自体は驚くほど扱いやすく、それは「Kinect for Windows SDK」のAPIが扱いやすいということでもあります。ただ、まだまだ機能が少ないために全体像を把握しやすかったというのが一番の理由かもですね。APIの少ない今が習得のチャンスです♪

多少の不満はあるけれど!

それでも、キネクトに抱いた不満はいくつかあります。1つめは骨格情報のミラーリングがサポートされていないということです。ただし、これは実装側でデータを変換すれば(X座標を入れ替えれば)よいだけなので、大きな問題ではありません。2つめは、関節の情報が三次元座標だけということです。これも、関節の角度を実装側で割り出せばいいだけなので、やっぱり大きな問題ではありませんでした。けれど、欲を言えば関節の向きも取得できたら嬉しいです。この向きが取得できないと、前向きか後ろ向きかはもちろん、身体をくるりと一回転するような動きをトレースできません。もちろん、実装側で顔認識とか関節座標の履歴を保持すればどうにかできなくもなさそうですが、実装がカオスになりそうなので…(汗 3つめは、デバッグがしにくいことで、確認のたびにポーズをとるのは大変でした。でもこれは、今月末に公開予定のSDK v1.5で改善されるというお話ですので、今から楽しみにしています~(o*゚ー゚)o

それでもここまでできちゃいます!

自分の動きに合わせて、リアルタイムに3Dモデルが動くというのは、個人的にとても新鮮な感動です!惜しむらくはこれが…ドロイド君であって窓辺さんではないことですが…。このように、一見するとおぉ~な感じ(?)のキネクトアプリも、実装自体は大したことありません。これからリファクタリングを行いますが、コメントをふんだんに盛り込んだとしても500行には満たないかなと。リファクタリング中に気付いたことや思い出したことがあれば、またブログに書いていきたいと思います。とにかくもう、キネクトは本当に簡単で面白いです!
ネタに選んで大正解でした♪(。´ゝω・)

ソースコードは夏コミで!

このサンプルの3Dモデルとソースコードは夏コミの同人誌のオマケとして配布する予定(当選すれば)です。ぜひとも在庫の撲滅にご協力ください!他にもサンプルを作成したら、併せて配布しちゃいます。時間があれば、次は3Dスキャナーモドキを作ったり、音声認識を検証してみたいですね。

Kinectでドロイド君を動かそう!(その1)

今回からしばらくの間、「Kinect for Windows」を利用して、思い通りに3Dモデルを動かすサンプルの開発に挑戦してみたいと思います。いわゆるひとつの「モーションキャプチャー」的なサンプルです。できればホントは「窓辺さんの3Dモデル」を動かしたかったんですが…お高いので代わりのモデルを用意することにしました(´・ω・`)

ハイエンド・ドロイド!

ということで今回は、窓辺さんの代わりに「ドロイド君」の3Dモデルを動かすことにします!(*`Д´*)ノ でも、どうせなら普通のドロイド君では物足りません。そこで今回は、驚異の7000ポリゴンオーバーで作成したハイエンドなドロイド君…つまり「ハイエンド・ドロイド」を利用します~!なんということでしょう!曲面やエッジの成形にポリゴンを贅沢に使用しています。しかもこのドロイド君…スゴイのはポリゴン数だけではありませんよ?( ̄ー ̄)

スキニング・ドロイド!

何と!こいつ…動くぞKinectから取得できる骨格情報を参考に、ボーンを仕込んで動くようにしてみました。個人的なこだわりポイントは、頭と胴体の間に「首」となるポリゴンを仕込んだことです。これによって頭を動かすと首が口のように見えるので、なんだかとってもチャーミング♪最終的にKinectでこのポーズが取れれば目標達成です!

使えるものは流用すべし!

ご覧のようにこのドロイド君は、肘や膝が人間の肌みたいに「グニャリ」と動きます。こういう3Dモデルのことを「スキニングモデル」というんです。C#でスキニングモデルを扱う場合は、AppHubで公開されているXNAの「スキニング モデル」というサンプルを参考にすると便利です。今回もこのサンプルを一部参考にして、Kinectで3Dモデルを動かすサンプルを開発していきたいと思います。

意外と情報が少ない?

しかし…この手のサンプルってネットで全然公開されていないんですね。ネタがありきたりすぎるかと思っていましたが、意外とそうでもないみたいです。単純に骨格を描画しているサンプルはよく見かけるんですが、あれってあくまで2D画像として骨格を描画しているので、実はとっても簡単なんです。SDKのAPIには、骨格と画像をマッピングするAPIも用意されていますしね。けれど、骨格を3Dモデルにマッピングさせようとすると、一筋縄ではいきません。行列とか行列とか行列とか…考えただけでも面倒くさそうです…ノ乙(、ン、;)

なお、サンプルが完成した暁には、3Dモデルとソースコードを同人誌のオマケとして配布する予定ですので、在庫の撲滅にご協力ください♪

Kinect for Windowsを購入しました!

今度の夏コミ(当選すればですが…)のネタ用に「Kinect for Windows」を購入しちゃいました~♪(*≧∀≦)ノ

話題のNUIデバイス

Kinectは、マイクロソフトが開発したセンサータイプの入力デバイスです。手を触れずに、身振りや音声で操作することのできる「NUI(ナチュラル・ユーザ・インタフェース)」と呼ばれるタイプのアプリケーション開発に利用できます。Xbox360用のKinectが発売されたのは2010年11月なので、ずいぶん遅めのデビューになってしまいましたが、しばらくはこのKinectを検証していきたいと思います。

実売価格は2万円弱

「Kinect for Windows」の希望小売価格は2万4千800円です。ただし、発売から3か月ほど経過した現在は実売価格が2万円を下回るようになってきました。なにやら最近は「Kinect for Windowsスペシャルパック」といった、窓辺ななみさんとクラウディアさんの3Dモデルが同梱されているパックも発売されているみたいです。…が、ついでにDSP版のWindows7までついてくるので、お値段もお高いんですよねぇ。できれば上記の3Dモデルを検証に利用していきたかったのですが…さすがに趣味で出せる値段ではありませんのでションボリです(´・ω・`)

Kinectを夏コミのテーマに選んだ理由は…また別途お話しするとして、まずは開発環境の構築から始めて行きたいと思います!(ゝω・`)

GWの終わりから始まるモノ

ゴールデン・ウィークが終わった後から始まるものって…何だと思いますか?もちろん、仕事もそうですね~(T△T)でも、二次元と三次元の狭間に生きる我々にとって、もっと大切なことがあるはずです。それは…

今までの経験を活かして…

そうです、答えは夏コミの準備です。ご存じの通り、コミケにサークル(売り手)として参加できるかどうかは、抽選式になっています。夏コミの場合、当落が発表されるのは6月なので、まだ半月以上も先なのです。ですが、当落発表を待ってから動き始めると…たいがい痛い目を見ます。そこで今年は、GW明けから早々に夏コミの準備を始めることにしました!(`・ω・´)b

ネタはいろいろあるけれど…

ということで、現在は「ネタ」を思案中です。今年こそはしっかりと、開発者向けの同人誌を作成するのが目標です!幸いなことに、最近は色々な話題がありますので、ネタには全く事欠きません。例えば「Windows 8」と「Visual Studio 11」による「Metro style apps」あたりは旬なネタですよね~!ところが、私はスレートPCを持っていないので、これらの真価を検証することができません。

Windows 8の解像度って…

もちろん、スレートPCの中には安価なものもあるわけですが、Windows 8 でMetroアプリを利用する場合、選択肢は極端に限られます。そもそも、Windows 8における解像度の最低要件は「1024×768 (XGA)」だそうなので、比較的安価なスレートPCではこの要件を満たせません。さらに、Windows 8をタブレットとして使用する場合、上記の解像度にタブレット機能用のスナップ領域(?)を加算した「1366×768(FWXGA)」が最低要件となります。はふん。この条件を満たすスレートPCって、現状ではオイソレと買える値段じゃない(10万前後)んですよねぇ…。かといって、マルチタッチ対応ディスプレイとかで代用するのは、Windows 8やMetroアプリの方向性と少し違う気がしますし。

結局ふりだし!

ということで、これらのネタは引き続きアンテナを張りつつ、夏コミのネタには別の何かを考えないとマズそうです…orz

Windows Phone!そういうのもあるのか!

第77回codeseek勉強会&第17回日本C#ユーザー会 勉強会」に参加された皆様、お疲れ様でした~!(*≧∀≦)ノ

勉強会はいいものですね!

わたし自身、久しぶりの勉強会でしたので、色々な技術に触れられてとても楽しかったです!でも、色々な方々から刺激を受けられるということが、勉強会における一番の醍醐味ですよね~。スピーカーとしても、もっと笑えて楽しいお話ができるように今後とも精進致します。

資料はこちらから!

私のセッションで利用した資料は、以下のサイトから閲覧することが可能です。その他のスピーカーの方々の資料も閲覧することができるので必見です!

第77回codeseek勉強会&第17回日本C#ユーザー会 勉強会レポート

ソースコードはこちらから!

セッションで利用したアプリケーション(上記画像)のソースコード及び3Dモデルは、以下のリンクからダウンロードすることが可能です。ご覧いただけるとわかると思いますが、基本的にはプロジェクトテンプレートから生成される雛形に対して、3Dモデルを追加してGamePageに処理を実装しているだけです。これだけで3Dアプリが作れてしまうのは、Windows Phoneの強みですよね!
レッツ、パンチラ!

codeseek_csharp.zip

APP HUBにアプリの更新を申請する際の注意事項!

既存のアプリケーションをWindows Phone 7.5にアップグレードした後で、APP HUB(アップハブ)にアプリの更新を申請する際につまずいたポイントをご紹介します。

その1:NeutralResourcesLanguage属性は必須!

APP HUBから、更新する対象となるXAPファイルをアップロードした際に、右図のような「エントリ アセンブリに [NeutralResourcesLanguage] 属性が存在しません。」エラーが発生しました。どうやらXAPファイルにNeutralResourcesLanguage属性を付与する必要があるようです。方法は簡単でして、メインとなるプロジェクトの「AssemblyInfo.cs」に[assembly: NeutralResourcesLanguageAttribute("ja-JP")]と記述すればOKです(名前空間はSystem.Resources)。これで再度XAPファイルをアップロードすれば問題は解決…

…とはいきませんでした。今度は左図の「更新プログラムでサポートする言語の数は、更新前のアプリケーション インスタンスでサポートしていた数より少なくできません。」エラーが発生しました。要約すると、どうやら「前回はカルチャを英語で申請したんだから…今回も英語にしなさいよね!」ってことらしいです。ですので、先程の記述を[assembly: NeutralResourcesLanguageAttribute("en")]に変更して、再度XAPファイルをアップロードすることにより問題は解決しました。

なおこれは、アプリケーションをWP7.5用にアップグレードする際の問題です。このため、RC版のWPSDK7.1からプロジェクトを新規に作成した場合はあらかじめNeutralResourcesLanguage属性が定義されていますので、上記の問題には遭遇しないハズです。ただし、例によって「Windows Phone Silverlight/XNA アプリケーション」は少し詰めが甘く、なぜかNeutralResourcesLanguage属性が定義されていませんでした。このため、RC版のWPSDK7.1において作成したSL+XNAアプリケーションを申請される方は、上記のエラーにご注意ください。

その2:韓国とブラジルは面倒くさい!

どうせなら、日本だけでなく全世界にアプリケーションが公開されるように設定して申請を完了しようとしたところ、申請手順の最後に左図のような「DJCTQ評価と認定の少なくともどちらかがありません」エラーと「GRB評価と認定の少なくともどちらかがありません」エラーが発生しました。う~ん…パッと見だと何が悪いのかよくわかりません(汗。

APP HUBの申請手順において、左図のようにアプリを公開する国を選択する画面があるのですが、よくみると韓国(GRB)とブラジル(DJCTO)にのみアスタリスク(必須マーク)が付加されていました。しかも、何やらファイルをアップロードする欄が設けられています。つまり上記のエラーを要約すると、アプリケーションを韓国もしくはブラジルに公開する場合は、ファイル的な”何か”を指定する必要があるみたいです。その”何か”がなにかはよくわかりませんが…今回は韓国とブラジルへの公開は諦める(上記の画面からチェックを外す)ことにより妥協しました。そもそも「GRB」とか「DJCTO」って…なんだろう?(´・ω・`;)

残るは審査が通るか否か!

以上が、更新の申請時につまずいたポイントです。なお今回の更新では、色々と実験的な要素を盛り込んでいるため、一発で審査に通るかどうかは微妙です。

例えば、今回はSL+XNAという技術を利用してアプリケーションを再構築しており、SL+XNAが審査規約の4.2.5に抵触しないことを確認したいと思います。また今回は、意図的にアプリケーションを終了させる際にSilverlightからXNAのGame.Exitメソッドを利用しています。この方法は本来、審査規約の4.2.5に抵触する方法なのですが、仮にSL+XNAが上記の審査規約に抵触しないのであれば問題はないハズ…といったような実験を多数盛り込んでいます。

もし審査に落ちたとしても、それはそれで初めての経験ですので得るものは大きいのですが。…それでもやはり、願わくば一発で通ってほしいものです…|д ̄) …ということで「MetroGnome」の国内公開まで今しばらくお待ちいただけましたら幸いです!m(_ _;)m

Windows Phone 7.5 対応時の問題点!

今回は「Windows Phone 7.0」のアプリケーションを「Windows Phone 7.5」にアップグレードする際に遭遇した問題とその解決策をご紹介します。以前に作成した「MetroGnome」というアプリをアップグレードしたのですが、なかなかに一筋縄ではいきませんでした…orz。

その1:実行時にビヘイビアやトリガーが登録できない!

前回の投稿でご紹介した通り、Visual Studioの「Windows Phone 7.1 にアップグレード」機能を利用すると、既存のプロジェクトをアップグレードすることが可能です。ただしこの際、アプリケーションの実行時に「型 ‘Behavior’ の値は、型 ‘BehaviorCollection’ のコレクションまたはディクショナリに追加できません。」のような例外が発生する場合があります。わたしが実際にアップグレードしたプロジェクトは、自作のビヘイビアやトリガーアクションなどを格納したライブラリプロジェクトだったのですが、上記のエラーはこれらのビヘイビアやトリガーアクションがアプリ実行時に参照されたときに発生しました。

ということで、結論から申しますと「Microsoft.Expression.Interactions」や「System.Windows.Interactivity」などの参照を一旦削除してから再度登録すると、上記のエラーは解消されました。どうやら参照していたアセンブリが古かったみたいです。このようなケースでは、ビルドエラーにならず、実行時にエラーが発生するようですね。根本的な原因は調べていませんが、おそらくSilverlightのバージョンが4になったことによる弊害か、あるいはWPSDK7.1のインストール前にExpression関連のモジュールをすべてアンインストールしたためだと思います (=`ェ´=;)ゞ

その2:SL+XNAプロジェクトがBlendで編集できない!

以前の投稿で「Windows Phone Silverlight/XNA アプリケーション」を利用する場合、XNAカテゴリから生成すると日本語のコメントが付加される旨をご紹介しました。しかしながら、このプロジェクトをExpression Blendで編集しようとした場合、「App.xaml」や「Game.xaml」で左図のように「XML タグ’Application’ に対応する終了タグがありません。」のようなエラーが多数発生します。まぁ日本語が文字化けしていることを見ると、文字コードが怪しいであろうことはすぐにお判りいただけると思います。

ということで調べてみたところ、上記のプロジェクトでは、日本語でコメントが記載されているファイルがことごとく「UTF-8N」で記述されていました。つまりファイルの先頭にBOMが付加されていないわけです。ちなみにBOMとは、エンディアンや文字コードの種別に利用される情報のことで、Expression BlendはこのBOMがないとファイルの文字コードを「UTF-8」であると識別できないようです。これにより、日本語のコメントがタグごと文字化けしてしまい、今回のエラーが発生してしまいます。このため、サクラエディタなどで「App.xaml」や「Game.xaml」を「BOM付きのUTF-8」で保存してあげれば問題は解決です。それにしても、RC版にしてはちょっと詰めが甘いかも…(ノω<;)

その3:既存のスタイルを上書きできない!

Silverlightアプリを開発する場合、「App.xaml」や「Generic.xaml」でスタイルを管理するのが一般的です。「MetroGnome」でも「PhoneTextTitle1Style」や「PhoneTextNormalStyle」などの既存のスタイルを、「App.xaml」内で再定義(同一名のスタイルを定義)したりしています。こうすると、開発時には既存のスタイルを利用し、開発が完了した後に一括してスタイルを変更できるので便利なんですよね~。しかしながら、Silverlight4ではどうやら既存のスタイルを再定義することができないようです。

Visual StudioやExpression Blendのデザイナではきちんと再定義したスタイルが反映されているのですが、いざアプリを実行すると既定のスタイルが反映されてしまいます。多分ソースコードでガリガリやれば回避できそうではありますが、今回は時間が惜しかったので、自作したスタイルの名前を変更して対応しました。う~ん…泥臭い(´・ω・`)

残すは不具合修正と公開作業!

ということで、あとは細かな不具合を修正して公開するのみです!できれば曲の追加とかもしたいのですが…しばらくはちょっと無理そうかもです(T△T)。1日まるまる時間が取れれば可能だと思うんですが…なかなかどうして…orz

MetroGnome国内公開準備中!

以前に「MetroGnome」というWindows Phone 7のゲームアプリケーションを公開したのですが、これは現在、日本のMarketplaceからダウンロードすることができません。どうやら再度、アプリケーションの申請を行わないと公開されないらしいのです。そこで遅ればせながら、MetroGnomeを国内公開するべく現在作業を実施中です!どうせ日本のMarketplaceに申請するのなら、併せてWindows Phone 7.5への対応も実施したいと思います。

ちょっぴり冒険!

ついでに今回は、SilverlightとXNAを同時に利用できるWP7.5の新機能である「Windows Phone Silverlight/XNA アプリケーション」として、プロジェクトを再構築してみたいと思います。なぜかというと、かねてよりの疑問を解消したかったからなのです。具体的にどういうことかと申しますと、審査規約の4.2.5には以下のような規約が定義されているのですが…

The application must not call any APIs in the Microsoft.Xna.Framework.Game assembly or the Microsoft.Xna.Framework.Graphics assembly when using any methods from the System.Windows.Controls namespace.

これは要約すると「SilverlightのControlsを使う場合はXNAのGameやGraphicsは使っちゃダメ!」という内容なのです…たぶん。しかしながら、SilverlightとXNAを同時に利用する「Windows Phone Silverlight/XNA アプリケーション」を作成する場合、どうやったってこの規約に違反しちゃいますよね?そこでこの機会に、この疑問をクリアにしておきたいと思った次第です。それにしても…審査規約ってまだ日本語化されていないんですねぇ…(´・ω・`)

アップグレードは簡単?

ということで、今回のアップグレード作業では、メインのプロジェクトを「Windows Phone Silverlight/XNA アプリケーション」として作成しなおすわけですが、その他の自作ライブラリなどはコンバートで対応することにしました。コンバートは、Visual Studioの「Windows Phone 7.1 にアップグレード」を利用することにより簡単に実行可能です。どうでもいいですが、ソフトウェア(7.5)とOS(7.10)のバージョン表記は統一してほしかったです…(´д`;)。ということで、この状態でビルドを実行すると、ビルドエラーは一切なし!これにてアップグレード作業は完了…

問題のオンパレード!

…かと思いきや、さすがに一筋縄ではいきません!ビルドこそ通るものの、実行時に「型 ‘Behavior’ の値は、型 ‘BehaviorCollection’ のコレクションまたはディクショナリに追加できません」なんて例外が発生したり、Expression Blendで編集しようとすると「XML タグ’Application’ に対応する終了タグがありません。」なんてエラーが発生したり、挙句の果てには画面のスタイルが崩れたり…(T△T)

…ということで次回の投稿では、WP7.0アプリを7.5にアップグレードする際に、わたしが遭遇した各現象の解決策をご紹介する予定です。…解決できれば…。「MetroGnome」の国内公開まで、今しばらくお待ちいただけましたら幸いです!m(_ _;)m