ゲームエンジン班最終報告澤田進平開発動機そもそも今年度の開発する予定のものはゲームエンジンではなかった 1 学期に主張したことは汎用的なノードグラフエディターの開発であった当時必要に迫られていたのが開発動機である一応夏休み中にある程度開発したものがこれである C

Size: px

Start display at page:

Download "ゲームエンジン班最終報告澤田進平開発動機そもそも今年度の開発する予定のものはゲームエンジンではなかった 1 学期に主張したことは汎用的なノードグラフエディターの開発であった当時必要に迫られていたのが開発動機である一応夏休み中にある程度開発したものがこれである C"

そうりんやまがた
5 years ago
Views:

ゲームエンジン班最終報告 200711210 澤田進平開発動機そもそも今年度の開発する予定のものはゲームエンジンではなかった 1 学期に主張したことは汎用的なノードグラフエディターの開発であった当時必要に迫られていたのが開発動機である一応夏休み中にある程度開発したものがこれである C# のコントロールとして提供されノードの値画像等は外部から読み込める予定であった何故

1 ゲームエンジン班最終報告澤田進平開発動機そもそも今年度の開発する予定のものはゲームエンジンではなかった 1 学期に主張したことは汎用的なノードグラフエディターの開発であった当時必要に迫られていたのが開発動機である一応夏休み中にある程度開発したものがこれである C# のコントロールとして提供されノードの値画像等は外部から読み込める予定であった何故開発を停止したかというと単純に使う必要性が消滅し使いもしないものを開発する意欲が存在しなかったからであるそれが 2 学期後半であり 3 学期急遽個人のほうで開発を計画していたゲームエンジンを近未来マルチメディアで開発しようというのが近未来マルチメディアでこれを行う理由であるそもそも何故ゲームエンジンを開発しようと思ったのは 2006 年より開発し実際に使用していたゲームエンジンが性能面で非常に問題がありかつ拡張では既に対処できない状況に陥っていたからであるそれで今までに考えていた機能を盛り込み新規に作ろうと思い立ったのが今回ゲームエンジンを開発しようとした理由である

2 設計と目標プラットフォーム Windows Linux MacOSX XBOX360 に対応可能にする Windows では.net framework で動作 Linux MacOSX は mono で動作 XBOX360 では XNA で動作するようにするプログラム言語 C C++ IronPython で開発するこの 3 つの選択での理由としては XNA は C# での開発なので必然的に C# 中心の開発になるしかし Windows Linux MacOSX での C# では描画自体はできないため描画等 C# で記述できない部分に関しては C/C++ を使用する IronPython は C# で使用できるスクリプト言語がいまだ限られているためこれを使用する描画 Windows では DirectX Linux MacOSX では OpenGL XBOX360 では XNA を使用するその他マルチコアの CPU が増えてきたこともありコア数が多ければ多いほど実行速度が速くなるよう開発するまた最近は PC のスペックがあがってきたので実行速度よりも可読性と保守性を重視する目標当初は各々の仕様をしっかり理解していない状態で見切り発進をしてしまったためこのようないい加減かつ少ない方針で開発を開始することとなった目標としては期間が 3 ヶ月ほどしかなかったので 2 月までに 2D 描画を終了させると設定した結果 XNA の破棄理由としてはまず XBOX では他の OS に対して完全な互換性が保てない点である当初より完全な互換は無理だと分かっていたがそれ以上に互換性を捨てなければならない点が多かった具体的には IronPython は XBOX で動作しない XNA ではリソースを配置する位置が固定されているシェーダーを動的に生成ができないなどであるなお私の調査不足で実際はできるかもしれない次に可読性とメンテナンス性の点である XNA はゲームループまで固定されており当初予定していた構造とあわせるには可読性の低いコードを書かざる得なかったこれらの理由のため XBOX360 で動くというメリットは大きかったがこれらのデメリットのため XBOX360 対応はやめることにしたなお XNA のバージョンがあがりできることが増えれば再開する可能性はある

3 2D 表示 DirectX と OpenGL それぞれで同じように動作するものができたただ 2D 表示本当に画像を表示するだけなので特にスクリーンショット等は示さない表示した以上に DirectX と Open GL の差異に関する点で得られたものが多かったのでそれは後述する CtoC# コンバーター C で記述した DLL を読み込むためには C# 側でも特殊な記述をしたコードが必要である手動でやるとミスが発生する可能性がある変更に対して弱い単純作業なので人間がやるべき仕事ではないという点から C のヘッダパーサーとコンバーターを自作したなおこれの開発は Swig という海外発のプロジェクトで作られたソフトによって意味はなくなってしまう総評おそらく近未来マルチメディア至上類を見ない 2D 表示だけの結果であろう既存のライブラリを使うならば画像表示はおそらく数行で終わるものだと思われるしかし今回の開発で書いたコード行数は数千行と見た目からは想像できないものになっているかなりのソースが DirectX と OpenGL を問題なく裂かれたものであり単純に表示するだけならほんの短い行数で済むであろう考察今回はゲームエンジンという基盤に当たる部分の開発だったので開発以上に既存のものへの認識が深まったそれゆえに問題点等が見えてきたので主にそれらについて考察するなおこれらは知識不足より間違いが多分に含まれている可能性がある DirectX の問題点と今後 HLSL(DirectX9) セマンティクスの意義 DirectX のシェーダーでは通常のプログラムからデータを渡す際にセマンティクスというものを指定する頂点データの配列でどの部分がシェーダーでのどの値と対応するかを示すものであり POSITION0 NORMAL0 COLOR0 COLOR1 などとセマンティクス名は完全に決まったものしか使用できないまたそのセマンティクス名は過去のものと互換性により 3D の表示であるような座標法線方向色などあたかもそのセマンティクスにはそれに対応したデータを当てる必要があるような印象を覚える名前である最近のシェーダーでは単純な頂点の処理だけでなく様々な値を頂点に格納することによって見栄えをよくすることが多々あるこの傾向は DirectX9 が開発された当初には分かっていたであろうことであり DirectX8 から DirectX9 になった時点で互換性を切って固定でなくユーザーが自由に指定できるようにするべきだったと思われるちなみに OpenGL で HLSL にあたる GLSL では初期バージョンからセマンティクスのようなものを自由に設定することが出来たなお私のコンピューターでは動かないので実際に実行はさせていないが現状の流れを受けて DirectX10 ではセマンティクス名は自由になったようである

4 DirectX10 DirectX9 との大きな違いは固定描画機能が消滅したことであるこれにより DirectX10 では簡単な 2D 描画でもシェーダーを書かなければならなくなったそれに伴う関数の統廃合が行われているまたシェーダー自体の機能もあがりセマンティクス名も自由になった今回 PC のスペックの問題上サンプルコードを読む程度しかできなかったがわかりやすいほうに改善が行われているといえるだろうただ国内を見ても資料がほとんどなくまたシェーダー必須となったためこれから DirectX に触ってみようという人にとっては難しくなったのではないだろうか? OpenGL の問題点と今後 OpenGL のバージョン管理問題 OpenGL には明確なバージョンというものが存在せず拡張という形で追加機能を提供しているそのため互換性は保たれるが過去に追加された関数から最新の関数までが混在し非常に理解しにくい状況になっているこの件に関しては OpenGL3.0 で一応の解決を試みている GLSL(OpenGL2.1) の使いにくさ今回の開発は OpenGL2.1 で開発しているためこのバージョンにおける GLSL について記述する GLSL は HLSL に対して難解であり使いづらいと私は思うそれは何故か? まず GLSL の最適化機能である HLSL と同じようにシェーダー内の変数名を指定して値を渡すことができるのだが GLSL ではその値が最適化により使用されていないと判断されると消滅しプログラム本体から値を渡そうとしても渡す先が発見できなくなるこのときに表示されるエラーのメッセージはその変数名を持つ変数が見つからないであり元々なかったのか最適化で消されたのかは明記されておらず OpenGL の初心者は非常に混乱することであろうまた変数に値を渡すときは変数名で検索して取得した変数の ID を用いて値を渡すのだが変数の ID はシェーダーのソース内に記入した順で振られていくのだが最適化で ID が変わってしまうそのためプログラム本体でもシェーダーにどのような名称の変数があるか予め記憶しておく必要がある実際メモリを大して使わなくともこれは非常にメモリの無駄使いであると思われいい気分ではない次に固定の変数名と過去の変数との互換性の問題である OpenGL は固定描画機能を使っていた時代の機能や結果の出力に対して予め定義されたグローバル変数を使用している固定描画時代は座標色などそれぞれに対して値を送信する関数がありシェーダーではそれらを決まった名前の変数に代入されているという形で受け取ることが出来るその変数名を知らない限り値を受け取ることはできず初心者が扱うときの妨げとなるこれらが私が GLSL が HLSL に対して使いにくいと感じた点である OpenGL3.0 現状の OpenGL の最新版であり今回私の PC の性能の都合上使用できなかったものであるこのバージョンから遂に今まで残っていた古い関数が非推奨扱いになっている例えば glbegin glend など今までの OpenGL では描画に必須だった固定描画機能のほとんどが非推奨となりいずれは削除されることになっている当然 glsl も改良され上記の予め定義されたグローバル変数もほとんど非推奨になっているこれにより非推奨を守れば上記の OpenGL 使用時の問題がほとんど解決されることになる DirectX と同じくやはり固定描画時代のものから離れシェーダー中心になるよう進んでいるようである

5 OpenGL と DirectX の比較 DirectX9.0c と OpenGL2.1+ 拡張によるマルチプラットフォーム対応は難しいか? OpenGL は拡張により Framebuffer Object に対応とするこの機能は画面に描画するのではなく別の内部のメモリに描画しそれをテクスチャとして使用可能にする機能であるこれが無いとできないことも多いので使用するまた DirectX と OpenGL は両方とも固定描画は使用せず全てシェーダーで描画することにする文法面 DirectX は C++ であり OpenGL は C 言語であるそのため DirectX はクラスを中心に記述されており OpenGL は関数を中心に記述しているまた DirectX は確保したバッファなどはクラスが保持するのに対し OpenGL は ID をバインドすることで対処しているこの方針の違いは実際にやってみるとラッパーを 1 つ書くだけでよく特に問題にはならなかった FramebufferObject DirectX では描画先は画面も画面以外も同じように扱われカラーと深度のテクスチャは別々に扱うことができるが OpenGL では画面と画面以外の描画先は別の扱いでありまた FramebufferObject というカラーと深度のテクスチャセットを扱う必要があるただ FramebufferObject で使用するカラーと深度のテクスチャは切り替えることができるので DirectX のように扱えるように OpenGL のラッパーを書かなければ問題はないだろう DirectX を OpenGL のように振舞わせることは簡単だが OpenGL を DirectX のように振舞わせるのは多少面倒である HLSL と GLSL HLSL と GLSL で記述できる内容はほぼ全くといっていいほど変わらないむしろ問題となるのはプログラム本体とシェーダーを接続する部分である前述したとおり DirectX はセマンティクスを使用してバッファをシェーダーに結び付けており OpenGL は変数名から取得した ID によってバッファとシェーダーを結び付けている OpenGL は変数名を必ずプログラム側で知っている必要があるまた DirectX では使用するテクスチャを直接シェーダーに渡すことができるが OpenGL はテクスチャを決まった位置にバインドしシェーダーにはバインドしている位置を渡してテクスチャを使用するこの点も OpenGL 側にあわせればなんら苦労はすることはないが DirectX 側にあわせようとすると多少苦労することになる総評今回は見切り発進につき設計をほとんど DirectX 側にあわせてしまったため何点かの点で面倒なところがでてきてしまったしかし実際のところは両方の仕様をしっかり理解していればほぼ問題なく全ての機能に対してラッパーを作れると思われるシェーダーになったおかげで座標系や UV などの OpenGL と DirectX の仕様の違いも関係なくなっており固定描画機能時代よりもはるかに楽に実装できることであろう

6 DirectX10.0 と OpenGL3.0+ 拡張によるマルチプラットフォーム対応はどれくらい簡単になるか? 仕様を見る限り両方とも固定機能の廃止もしくは非推奨とシェーダーの強化以外は大差はない DirectX のセマンティクスが自由になり OpenGL に近くなった点を除けば DirectX9.0c と OpenGL2.1+ 拡張でのマルチプラットフォームと大差はないだろう DirectX と OpenGL の今後今まで述べてきたように固定機能が廃止されたことによって非常に似通ってきているもはや独自路線という時代ではなくこれからもその傾向が続くのではないだろうか? 昔はそれぞれの立場と使用される場面に差はあり一度は Fahrenheit というプロジェクトで統合という話がでたものの失敗した経緯があるしかし今ならば統合してもほとんど問題ないレベルまで似通っており万が一に統合という話が再度浮上すれば問題なく統合されるのではないだろうか? 今後の展望まず既に作り上げた部分を破棄し再度 DirectX と OpenGL の違いを確認した上で C++ を使用して書き直したい上記の DirectX と OpenGL の差異は多少面倒な方法でカバーしておりその部分の可読性が若干落ちているまた現在は C# で扱いやすくするために C 言語で記述していたが Swig の性能が予想以上によく C++ でも問題なく C# で扱えるようになると予想されるので一般的には C 言語よりも楽と思われる C++ を一部機能を制限しながら使用したいと思う次にゲームエンジンを開発するだけでなく早めにサークルのほうで実用に使いたいと思うそれにより使い勝手や不足している機能が発見されるであろうそれらを修正しいずれ外部に公開したいところであるまたこのプロジェクトを進めるといずれは再度ノードグラフエディタを必要とする場面がくることが予想されるのでいずれは再度 1,2 学期に開発していたノードグラフエディタを改良し使用したいところである

XNA Framework

XNA Framework 2.0 M@STER SESSION 01 XNA Framework の技術的背景システム基盤は.NET Framework マネージ環境で実行クロスプラットフォーム Windows, Xbox360, Zune DirectX, MDX から独立している開発実行環境の構造 XNA Game Studio (Visual Studio 2005) XNA Framework