UnityエディターのLinuxへの移植:事前に行うべきこと

今年のUnite Europeでは、開発計画を公開しました。 そして、多くのクールなものがありますが、私は個人的にLinuxのエディターが最も好きです。 Linux向けのエディターの移植の歴史は、Unity 4.0でのランタイムに対するLinuxサポートの追加の歴史に似ています。 概して、これは魂のために行われ、Unityの一部の従業員はこれにしばらくの間定期的に取り組んでいます。多くの点で、このプロジェクトはUnity開発者の間の内部ハックウィークの成果の1つです。 すぐに、皆さんが試すことができる実験的なアセンブリをリリースする予定です。



エディターをLinuxに移植するには、ランタイムの移植よりも多くの労力が必要でした。 これは、一部はリソースデータベースに起因し、一部は大文字と小文字の区別の問題に起因するため、エディターにほとんどの独自のテクノロジが組み込まれているという事実(サードパーティの開発との複雑な統合を含む)に起因しています。 エディターの構成:









*大量のC ++コード。そのほとんど(すべてではない)がランタイムと共通であり、当然、目的のプラットフォームにコンパイルされます。



* Monoの上で動作する多くのC#コード



* Linuxで再コンパイルする必要のあるさまざまなサードパーティライブラリとミドルウェア



これに対処したら、事前に行うべきことに戻ることができます。



1.大文字と小文字を区別する



Unityは、大文字と小文字を区別するファイルシステムでは正しく動作しません(大文字と小文字を区別するファイルシステムHFS +でエディターをインストールして実行しようとしたユーザーは、既に遭遇する可能性があります)。 これは主に、Unityリソースデータベースがパスを保存し、GUID値に関連付ける方法が原因です。 もちろん、開発の最初にすべてを考慮に入れようとしましたが、大文字と小文字を区別するファイルシステムでシステムがどのように機能するかを実際にテストしない場合、プログラマーのいずれかが最善の意図でLowerに適用しないとクラッシュすることはありません( )全体のアイデアを損なうことはありません。



このような事柄を遡及的に修正することは困難で退屈なので、私たちは事前にこれに気をつけてください。



2. #if WINDOWS #else OSXを使用しないでください



エディターをWindows用に移植する初期段階でのまったく予期しない作業は、次のようなものに関連していました。



#ifdef WIN32 return _isnan(val) != 0; #elif __APPLE_CC__ return std::isnan(val) != 0; #endif
      
      







または、オプションとして



 #if UNITY_WIN // Some Windows-specific codepath #else // Some Mac-specific codepath #endif
      
      







結論:移植性のあるコードを書きたい場合は、#elseの場合は常に合理的なこと(読み方:未来を見据えて)をしてください。



3.仮定をしないでください



以前の2つの問題は非常に大きく、次の問題は小さかった



*コンパイラに関する前提。 たとえば、バグレポーターシステムを取り上げます。このシステムは、主にメインエディターとは別に作成され、C ++ 11の機能の一部を使用しています。 多くの場所で、この標準...ええと...は幾分曖昧であり、異なるコンパイラはそれを異なる方法で実装します。 これにより、C ++ 11コードを3番目のコンパイラに移植するのが非常に困難になります。 this-pattern-C ++の精神には多くのコンパイルエラーがありました-山括弧の束はthis-pattern-C ++と一致しません-山括弧の束は一定の場所にあります真ん中に。



*アプリケーションメニューに自動的に含まれるアイテムを含む、ネイティブアプリケーションに関する仮定。 たとえば、Windowsでは「コピー」、「ペースト」などが無料で含まれていますが、GTKには含まれていないため、手動で追加する必要がありました。 私は嘘をつきません、OS Xではそれらも自動的に追加されませんが、OS Xの実装は上記の#if WINDOWS #else OSXトラップに陥りました。



*ファイルダイアログの操作に関する前提。 他のプラットフォームには、親アプリケーションが特定のものを選択できないことをダイアログに説明できるコールバックシステムがあります。 標準のGTKウィジェットはそのようには機能しません。



*一般的な仮定



結論:仮定はすべての病気の原因です。 :-)



上記のすべてにもかかわらず、作業は非常に興味深いものでした。Unityに匹敵するプロジェクトを新しいプラットフォームに移植すると、同様の問題が予想されます。



興味のために、転送プロセスで放棄しなければならなかったソリューションを説明します。 GTKとQTのどちらにもバインドしたくないため、最初のオプションは純粋なX11を使用してウィンドウとイベントを処理しました。 このため、初期のメニューシステムはUnity GUIで作成されました。 いつかこれに戻ってくるのは本当にクールだと思う。 Unity 5.1では、GTKに依存するCEFが組み込みブラウザーとして使用されるため、すべてのメニューシステムのウィンドウとイベントを処理するためにGTKに切り替えました。 しかし、これは私たちが再び何かをやり直さなければならなかった唯一の時間でした。



それでは、エディターでどのように作業を進めていますか? 私が知っていることは次のとおりです。



* 64ビットLinuxのみがサポートされます



*ランタイムと同様に、狂わないように、Ubuntuのみを公式にサポートします。 しかし、おそらくエディターは他のディストリビューションで動作します。



*ほとんどの場合、12.04からUbuntuのバージョンをサポートします(現在のビルドを作成しているのはその上にあります)



*サードパーティライブラリに依存する機能(グローバルカバレッジなど)が機能します



*インストーラーは、おそらくパッケージ.debになります(まだ行っていません)。



*サードパーティソフトウェア(3ds MaxやSketchUpなど)に依存するモデルのインポーターの一部は機能しません。 回避策として、FBXへのエクスポートを使用できます



今のところすべてです。 小さなティーザー:







LinuxエディターからLinuxにエクスポートされた2次元シューティングゲームのネットワークデモ。







Unity LabsのLinuxエディター。 Retina搭載のMacBook Proで実行されるため、フォントは非常に小さいです。



All Articles