菊池 Blog

移転しました 続・菊池 和彦の足跡

AILight Banner
AILight Blog

プロフィール

菊池 Blog

目次

Blog 利用状況

記事分類

過去の記事

タグ

XNA Frameworkにかなりむかつきを覚えた

まず、csprojのとある一行が原因で Visual Studio の上位エディションでは開けません。

これは Express でプロジェクトを作成後、csproj 内のとある一行を削除することで回避できます。(TechEd の期間中にこの辺までは解ってましたね。某グループでは)

なんか、上位エディションを「お金を出して」買っている人に対してこれはあまりにも失礼な制限なんじゃないですかね?

 

また、上位エディションで開くのが絶対に必要な理由が追加されまして…

開発環境を Windows のx64版で持っている場合、プロジェクトの設定で Express では変更できない「プラットフォームターゲット」をAnyCPUからx86に変更しないと起動時にBadFormatが飛んできます。(XPで確認)

最終的に XBoxまでイメージを持っていくときに x86指定されてると(XBox360はCPU違うので)困るのかも知れませんけど、Visual Studio の Express Editionでは起動できる実行イメージが得られないわけですね。

当然、ビルドは通ってもデバッグはおろか実行もできません。

 

ちょっと見た感じでは、Managed DirectXの再構成に見えるし XNA とか言って変に制約つけるなら Managed DirectXの .NET Framework 2.0版をさっさと出荷してほしいぞ。

.NET Framework 1.1 + Managed DirectX で出荷済みのアプリとか今後どうしろって言うん?

シミュレーション、CADとか3D必須な分野からWindows+.NET Frameworkは手を引きます、ゲームのみですって言うなら XNA のみでも良いけど、 DirectXを利用するアプリケーションがゲームのみって誰が決めたん?

ゲーム屋さん以外の .NET Framework ユーザーから DirectXを取り上げるって決意表明でいいんですかね?>XNA

 

 XNAはXNAで XBox 360とクロスでとかいろいろやってくれて別にかまわんけど、Managed DirectXはManaged DirectXとして必要なので、Managed DirectXの.NET Framework 2.0版を早期に出荷することを強く要望したいわけであります。

 「DirectXをゲーム以外で使いたければ.NET なんかやめて Nativeに帰れ!」

 って意味になってますよ>XNA

 そして、今後において

 「HogeをHage以外で使いたければ.NETなんかやめて Nativeに帰れ!」

 とか言われる事考えると、W?FもVistaもその先もなんか信用できないのよね。

投稿日時 : 2006年9月7日 3:28


コメントを追加

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月7日 17:20 菊池

んなわけで、XNAのManaged DirectXっぽい部分を調べているのだが、一番の問題は Redist.txt がどこにも入ってない。

動作的にはDirectXのランタイムとMicrosoft.Xna.Framework.dll だけがあれば十分のようだ。

Microsoft.Xna.Framework.dll のインストール用にXNAのランタイムとかがどういう形式で出るのかどうか良くわからない。
DirectXを入れる時点で「それってゲーム用じゃないの?」、「3D画像処理用ランタイムです」、「ゲーム用っぽいけど」、「ゲームでも3D使いますでしょ、この(ピー)の3D表示機能をはずせって言うならいいですけど?」な会話をしたのを再度XNAでやるのかと思うと…


ちなみに WindowsForms アプリケーション上に NativeWindow に基づくコントロールを作ってHWNDをやり取りさせれば一応GrphicsDevice(D3D?Device相当)の描画出力を出すことは可能だが System.Windows.Formsのメッセージループにレンダリングループを組み込むのは結構厄介になるのは以前と変わりなし。

基本は ApplicationのOnIdleイベントの中でPeekMessageでメッセージが来ない間レンダリングループを回るというのが一番楽なのかな Microsoft.Xna.Framework.Game.dll には基本的なメッセージ処理が実装されているのでXNAだけを使う人にとっては気にする必要はない。

Microsoft.Xna.Framework.Game.dllによるメッセージループと System.Windows.Forms.dllによるメッセージループには依存関係がある事が確認できたので、 Microsoft.Xna.Framework.Gameのメッセージループを使って Windows Formsアプリを動かす事ができるようだ。ためしに System.Windows.FormsのFormをXNAアプリの中から(別ウインドウとして)出してあげるのをやってみたがいとも簡単にできた。

逆にWindows Formsアプリの中にXNAのGraphicsDeviceに基づく表示をするにはメッセージループに介入してレンダリングループをまわす必要があるって事。
自分にとっての一番のネックはそれをやると単なるコントロールの立ち位置に居るはずのとあるデータの3Dモデル表示部が結局アプリケーションの中枢たるメッセージループと密接に関係し始めてしまう点なのだが、レンダリングループをシングルトンにして、お互いで共有する事で自分の範疇ではそこは何とか回避している。

ただし、結局は同じようなことをする誰かとかち合うとレンダリングループにCPUを独占的にほしい人が二人という競合の構図が発生するわけで、特にWPFとの相性がよくないって事になる。

ためしにWindows FormsのコントロールとしてXNAのGraphicsDeviceを使った描画を出すのは、レンダリングループの制御を作ってやってOnIdleに手を出す部分の制御をちゃんとやればできた。しかし、そのWindowsFormsコントロールをWPFアプリケーションに乗せると破綻、理由は明白だけど解決方法が非常に厄介って言うか無いよなぁこれ。

WPFのレンダリングループに割り込む方法とか、WPFの表示の一部を XNA のGraphicsDeviceにもらう方法とかあれば描画コードは共通で両対応をするのはできなくもなさそうなんだけどなぁ…

メッセージループっていうか、アプリケーションモデルを統一してほしい…

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月7日 21:38 NyaRuRu

ども。
このあたり割と込み入った事情や歴史的経緯があるので、その辺について TechEd の時にお話しておけば良かったかもしれませんね。

とりあえず Managed DirectX 経験者なら、XNA を MDX の代わりに使うこと自体はかなり簡単なはずです。
ちなみに AnyCPU の問題も MDX 2.0 のころから同じです。

それなりに慣れた開発者なら、今頃楽しく Professional Edition 等で楽しんでいるかと思います。
私も以前の MDX ゲームを、WinForms のままを MDX 部分のみ XNA に置き換えて遊んでみてたりしています。
# ランタイム・ライブラリの再配布については現在問い合わせ中

菊池さんに XNA 関係でチェックしておいて欲しいところと言えば、IComponent と Visual Studio のデザイン時モードのあたりでしょうか。
http://higeneko.com/diary.php?Date=2006-09-01#Date2006-09-01
WinForms や ASP.NET 関係で、結構複雑な仕組みができてたんですね。私は今回 XNA が出るまであんまり縁がなかったのでノーマークでした。

今回少し触ってみた感じでは、このデザインモードでできることについてまだまだ突っ込みどころが色々あるんじゃないかという印象です。
たぶん DirectX 開発やゲーム開発に詳しい開発者はそれなりに XNA コミュニティに来てくれそうなのですが、Visual Studio 拡張とか msbuild とかそういう方面に詳しい人もそれなりに来てくれればなーというところです。

あと、WPF と DirectX の混合については私も以前少し調べたことがありますが、基本的には期待しない方がよろしいかと。

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月8日 11:03 菊池

うん、おおよそは把握しててもきっちり把握してないからねぇ>込み入った事情とか

AnyCPUの問題とか過去はあまり意識してなかったんだけど(実は他の事情でx86縛りだったので)単独でXNAに手を出してみたら解ったって感じですね。

それで開発環境に「Expressを選ぶのは無理があるのでは無いかい?」と思うわけですよ。意図的にExpressにしているのでなければ「もうねアホかと」って感じで。

IComponentとしての出来は順当なのではないでしょうか、GameComponentの派生にするだけでドラッグ&ドロップでほいほい組み合わさりますし。
この辺はデザイナ連携系ですので、基本は .NET Framework 1.0 、Visual Studio初期からのWinForms/ASP.NET、その他もろもろで既に枯れ始めている技術の応用ですから大きな問題無いと思います。(個別実装に問題は発生しても大きな問題にはならないでしょう(個別実装を生み出す仕組みに問題が無ければ))

突っ込みどころはあんまり見えないかなぁ、そもそも自分はDirectXをとあるコントロールの中で使いたい(他には影響を与えずに)な立ち位置に居る人なので中にGameComponentを置くかは微妙です。
GameComponentに依存するとさっきのレンダリングループの問題が沸きあがりそうで&Microsoft.Xna.Framework.Game.dllに依存関係持たざるを得ないですし。

WPFとDirectXの混合は期待できないのは「そもそも仕組み的に無理よねー」って感触は持ってたのですが、「やっぱり無理だったか&XNAでもその辺は対応無しか」ってのが見えただけですね。
コントロールとして物を提供してると、WinFormsコントロールの中にWinFormsコントロールを繰り返して居るぶんには良いんですが、どっかの誰かがWPFの中に入れちゃう日がいつか来る(as is 入れたいって要求がいつ来るか…)と思うので、そこで再燃するんだろうなぁと思ってます。
WPFがWinFomrsコントロールを置けるようになったあたりから懸念していたんですよね。(レンダリングループの基本実装がアプリ内で競合しちゃう世界)
将来的にメッセージポンプの仕組みと同様で各種モデルを統合するアプリケーションモデルへ進化して調整役がどっかに生まれない限りには無理だろうと思ってます。

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月8日 17:20 NyaRuRu

>AnyCPUの問題とか過去はあまり意識してなかったんだけど(実は他の事情でx86縛りだったので)単独でXNAに手を出してみたら解ったって感じですね。

Interop を駆使したライブラリをメンテナンスしてみないとこの辺りの使い勝手の悪さははなかなか見えてこないので、もうちょっと早くしかるべきところ (Visual Studio チームか CLR チーム) にフィードバックしておくべきだったかなぁと思っています。

例えば今だと、x86 版の Interop アセンブリしか存在しない場合、それをターゲットタイプに自動で反映させる仕組みがなかったりしますよね。
その辺は要改良でしょう。

>突っ込みどころはあんまり見えないかなぁ、そもそも自分はDirectXをとあるコントロールの中で使いたい(他には影響を与えずに)な立ち位置に居る人なので中にGameComponentを置くかは微妙です。

今回の GameComponent は WinForms のコンポーネントとは違っていて (当然 WinForms 相手の連携は考慮されていない) 一応注目はしているのですが、
・Microsoft.Xna.Framework.GameComponent.Site が virtual ではないため以下のサンプルのようなテクニックが使えない。→ デザイナ連携で多少困る
http://msdn2.microsoft.com/en-us/library/system.componentmodel.design.ireferenceservice.aspx
・デザイナ上に表示されるコンポーネントの画像をカスタマイズできない
等の改善点がまだまだあるように見えました。
あんまり中途半端な状態でリリースされると結局使えないので、推すのか推さないのかどっちか決めかねている状態ですが、細かい不具合は使ってみないと分からないのが厄介ですね。

> WPFとDirectXの混合は期待できないのは「そもそも仕組み的に無理よねー」って感触は持ってたのですが、「やっぱり無理だったか&XNAでもその辺は対応無しか」ってのが見えただけですね。

WPF は内部で確かに DirectX を使っていますが、詳細については MIL が完全に隠蔽してしまっているので手の出しようがないかと思います。(MIL を使用する Desktop Window Manager ついても同様)
Vista 上での Direct3D9Ex + MIL の組み合わせは、多分その辺のゲームよりもマニアックなチューニングが行われていて、例えばプロセス間でフォントキャッシュを共有し、PixelShader を駆使した ClearType 描画を行うなど、ある意味 All-in-one な存在になっています。
あれはあれで芸術的なのですが、お互い突き抜けすぎていて DirectX Native のアプリケーションとは相性が悪いですね。

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月10日 10:39 菊池

Siteがvirtual?…IComponentインターフェースである時点でvirtualじゃないの?

少なくともインターフェースの明示実装では Site のset/getは引っ掛けられるよ。

public partial class TextComponent : GameComponent ,IComponent
{
event EventHandler IComponent.Disposed
{
add { base.Disposed += value; }
remove { base.Disposed -= value; }
}

ISite IComponent.Site
{
get { return base.Site; }
set {
System.Diagnostics.Debug.WriteLine("setting Site " + value.ToString());
base.Site = value;
}
}

void IDisposable.Dispose()
{
base.Dispose();
}


System.ComponentModel.Componentは継承しなかったみたいだし、ComponentModel.Componentに絡んだテクニックは一部通用しないものがあるかも知れないですね。

#  re: XNA Frameworkにかなりむかつきを覚えた 2006年9月10日 10:43 菊池

PDC06のHandsOnLab(WPF_HOL_Jan_CTP_Japanese_Docs.zip)にWPFと相互系の話があるみたいなので見て見た。

http://www.microsoft.com/japan/msdn/windowsvista/building/presentation/hands_on_lab/

結局、レンダリングループは別スレッドって事?
タイトル
名前
URL
コメント