グラフィックスでは、OBJ や COLLADA などのより一般的なテキストベースの形式を実行時に解析する必要がないように、3D アセットの保存用にカスタム バイナリ ファイル形式を作成することについて多くの議論があります。理にかなっています。
ただし、このバイナリ ファイルの実際の作成はそれほど単純ではありません。シリアル化やその他の方法などの手法が含まれているため、最新のバリアントを除いて、C++ によってネイティブに処理されないものもあります。
しかし、これらのテキストベースの形式の 1 つを C スタイルのヘッダーに解析すると、データが単純にfloatorstruct宣言に解析されると、このデータはアプリの残りの部分と一緒にバイナリにコンパイルされることに気付きました。つまり、解析はおそらくスクリプトによってアプリの外部で行われ、バイナリへの変換はコンパイル時に変換単位にヘッダーが含まれているときに処理されます。
私の考えは正しいですか?実際にバイナリ ファイル形式を作成してそのルートに進むのと比較してどうですか?
あなたの考えは絶対に正しいです。コンパイラのヘルプを使用して、テキスト表現をバイナリに変換できます。ヘッダーを使用するのではなく、データを別の翻訳単位に入れ、スクリプトによって入力されたデータ構造の前方宣言を含む固定ヘッダーを保持します。
ヘッダ：
// This is fixed
extern float data_array[];
extern size_t data_array_cnt;
CPP ファイル:
// This gets generated by a script
float data_array[] = {1.2, 3.4, 5.6, 7.89 };
size_t data_array_cnt = sizeof(data_array)/sizeof(float);
2 つのアプローチの最大の違いは、バイナリ表現をファイルに保持すると、すべてをコンパイルした後で表現内容を変更できることです。実際、本番環境で別のバイナリをスワップすると、すぐに有効になります。対照的に、コンパイラ ルートでは、バイナリ データを変更する必要があるたびにプログラムを再コンパイルする必要があります。事実上、バイナリ データはプログラムのコンテンツに「焼き付け」られます。
動的リンクをサポートする環境では、バイナリ データを別の動的にリンクされたライブラリに分離し、そのライブラリを "メイン" コードとは別にコンパイルすることで、中立的なソリューションを作成できます。バイナリ データはコードの一部のままですが、プログラムの残りの部分とは別に、新しいデータをスワップインできるようになりました。
コンパイル時間などは別として、リソースが個別のファイルにパックされている最大かつ最も主要な理由の1つ目を台無しにしています-それらは外部でスワップ可能です。このヘッダー形式で DLC を作成することはほとんど不可能です。
あなたの方法では、リソースが変更されるたびに関連するプロジェクト部分の再コンパイルが強制されますが、それらを外部化すると解析が実行時に移動します。アーティストはモデル、テクスチャ、その他すべての作業を行うことができ、開発者は互いの邪魔にならずにコードを作業できます。