開発には一から作るのは大変なので、既存のサンプルプロジェクトを使って作成してみたいというときなど、名前を変更してやる場合があると思います。
今回はサンプルの「X-Plane-11-Window-API-Sample」をベースに名前を変更しています。
プロジェクト名を「Polo-Test-Window」と変更しました。ウインドウの別のところをクリックするか、リターンキーで下の画面が出てくる、Chengeのところで変更される項目がわかるので、どこが変更されるのかが理解できると思う。
「Rename」をクリックし、OKをクリックする。
次に「Source」内のcppファイルの名前も変更します。
次に上の方にギリシャ神殿マークみたいなのがあるが、ここをクリック。
Manage Schemes（スキームの管理）を選択。
すると下のウインドウが出る。
Autocreate schemes（スキームの自動作成）、Autocreate schemes New（スキームの自動作成 新規）
左下のある「+」ボタンをクリックすると、新しく作成した名前が表示されるので、OKをクリック。
新しい名前が追加さるので、古い名前を選択して「−」ボタンで削除します。
Deleteボタンで削除。
以下のようになれば完了です。Closeで終了します。
最後に以下のようになっているのを確認します。
これで一応一通りの新しいプロジェクトとビルドの環境が整ったことになります。
これをXcodeで一から作成するとなるとビルドの設定が非常に難しくなるので、既存の設定をそのまま使うと何も考えずにビルダが実行できるので簡単にできるようになります。
目次
ビルドしたファイル名が元の名前になっている
うまく名前が変更できたと思ったが、ビルドすると以前の名前の中にビルドファイルが入っている。
以下は上とは違うプロジェクト名で混乱するかもしれないが、下のSimple Text Viewが変更したプロジェクト名でHell World SDK 3は変更前のプロジェクト名になる。
警告が沢山出るのを解決
▶のビルドボタンを押すと警告が沢山でます。
基本的にはあくまで警告なので、このまま使うことができる。
この中で下の方にあるUpdateとMigrateとEnableはクリックしていくと自動的に解決してくれる。
例えば、一番下のEnable Baseをクリックすると以下のウインドウが出るので「Enable」をクリックするだけで解決。
一番上のUpdate to recommended settingsが何故か消えない。
「Perform Changes：変更の実行」
Updating the target’s macOS deployment target to a newer value is recommended. This will update the MACOSX_DEPLOYMENT_TARGET build setting.
ターゲットの macOS 展開ターゲットを新しい値に更新することをお勧めします。 これにより、MACOSX_DEPLOYMENT_TARGET ビルド設定が更新されます。
何故かこれが変更されない。
次にいってみる。
Dylib (SDK/Libraries/Mac/XPLM.framework/XPLM) was built for newer macOS version (10.10) than being linked (10.9)
Dylib (SDK/Libraries/Mac/XPLM.framework/XPLM) は、リンクされている (10.9) よりも新しい macOS バージョン (10.10) 用にビルドされました。
つまり、これは(SDK/Libraries/Mac/XPLM.framework/XPLM）が10.9で設定されているが、実際は10.10でビルドされたとうことになる。
このことを指している。
これの解決策は、プロジェクトを(Cmd-Shift-K)でクリーンアップ、もう一度ビルドすることだけ。これでこの警告が消えて、選択した展開設定で動作するまったく新しいオブジェクトファイルが作成されます。とあった。実際警告は消えたけど10.9でビルドされたのかがどこで確認するのかが不明。
これでも最後にUpdate云々が残った。
この時点で再度ビルドするとまたまた大量の警告
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:206:5 ‘sprintf’ is deprecated: This function is provided for compatibility reasons only. Due to security concerns inherent in the design of sprintf(3), it is highly recommended that you use snprintf(3) instead.
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:206:5 ‘sprintf’ is deprecated: この関数は、互換性の理由でのみ提供されています。 sprintf(3) の設計に固有のセキュリティ上の懸念により、代わりに snprintf(3) を使用することを強くお勧めします。
以下のところでsprintfをsprintfをsprintf(3)に変更するようにという警告。
しかし、変更するとエラーになってしまうので変更ができない。まだ警告のままが良いということになる。
これはX-Plane SDKの関数の問題だと思うので、そちらを変更するかXcodeのバージョンをダウングレードするかのどちらかをしないと永遠に解決しない問題である。
従ってこのままでいくことにする。
次の警告
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:154:4 ‘glEnd’ is deprecated: first deprecated in macOS 10.14 – OpenGL API deprecated. (Define GL_SILENCE_DEPRECATION to silence these warnings)
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:154:4 ‘glEnd’ は非推奨です: macOS 10.14 で最初に非推奨になりました – OpenGL API は非推奨になりました。 (これらの警告を消すには GL_SILENCE_DEPRECATION を定義してください)
以下を追加すると、この警告が消えるということだが消えない。
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:127:102 Implicit conversion loses integer precision: ‘size_t’ (aka ‘unsigned long’) to ‘int’
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:127:102 暗黙的な変換により整数精度が失われます: ‘size_t’ (別名 ‘unsigned long’) から ‘int’ へ
Traditional headermap style is no longer supported; please migrate to using separate headermaps and set ‘ALWAYS_SEARCH_USER_PATHS’ to NO.
従来のヘッダーマップ スタイルはサポートされなくなりました。 別のヘッダーマップを使用するように移行し、「ALWAYS_SEARCH_USER_PATHS」を NO に設定してください。
これで警告は消えた。
次の警告、これもX-Plane SDKの関数の問題。こちらでは解決できない。
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:127:102 Implicit conversion loses integer precision: ‘size_t’ (aka ‘unsigned long’) to ‘int’
/Volumes/Colorful SL500 SSD 960GB/X-Plane SDK/Polo-Test-Window/Polo-Test-Window.cpp:127:102 暗黙的な変換により整数精度が失われます: ‘size_t’ (別名 ‘unsigned long’) から ‘int’ へ
このドキュメントでは、OpenGLを使用してX-Planeのプロセス内で実行されているX-Planeプラグインから描画するためのガイドラインを提供します。
X-PlaneのOpenGLについて
X-PlaneはOpenGL、Vulkan、またはMetalドライバを使用してグラフィックスカードにレンダリングできますが、プラグイン描画はOpenGL経由でのみサポートされています。OpenGLは最速または最新のAPIではありませんが、メモリ管理、リソースバリア、並行性などの複雑でエラーが発生しやすい実装の詳細を公開することなく、3Dを描画する堅牢な方法を提供し、カスタムユーザーインターフェイスとカスタム航空機ガラスディスプレイに適した選択肢になります。
XPLMとOpenGLの使用を最小限に抑える
X-Planeユーザーはパフォーマンスを深く気にかけています。OpenGLとXPLMの使用を最小限に抑えて、アドオンがフレームレートに及ぼす悪影響を最小限に抑えます。必要な操作と、OpenGLリソースを除き、XPLM APIを介して取得したキャッシュ値のみを実行し、可能であれば後で再利用します。描画するときは、繰り返されるOpenGLの状態の変更を避け、可能な場合は最新のOpenGL技術を採用してください。静的ジオメトリにシェーダーと頂点バッファオブジェクトを使用することは、OpenGL 2.0以前の即時モードレンダリングを使用するよりもはるかに高速です。