スペース効率のために、バイナリを使用して保存ファイルをコーディングすることに決めました。すべてのバイトは、タイルのタイプのIDを表します。これは、エンディアンの計算が異なる場合に問題になるでしょうか？このタイプのバイナリIO操作でエンディアンが問題になりますか？
また、エンディアンタイプを設定するのは、CPUまたはオペレーティングシステムですか？
追加情報：私はC++を使用しており、xプラットフォームのゲームを構築しています。私はBoostのような追加のAPIを使いたくない。
はい、の場合、BEから保存されたファイルがLEにロードされるか、その逆の場合にはが発生します。このため、UTF-16やUTF-32などのUnicodeエンコーディングの中には、いわゆるバイトオーダーマーカーがある理由があります。
通常、コードがBEでコンパイルされている場合は、LEコードがデータを使用する前にバイトオーダーをスワップするようにしなければなりません。
CPUはEndianessを設定し、一部のチップ（一部のMIPS CPUなど）では、システムのブートストラップ時に切り替えが可能です。
ありがとう、これは私が探していたものです。 – Johnathan
少し詳しい情報を使用できます。クロスプラットフォームは一つのことですが、どんなプラットフォームですか？ x86 Mac、x86 Linux、x86 Windowsのようなクロスプラットフォームを意味するならば、それについて心配する必要はありません（ただし、構造体をディスクに書き出して別のコンパイラでコンパイルしようとすると構造体パッキングが問題になることがあります）。異なるプラットフォーム）。異なるOS/CPUコンボをいくつか持っていても、サポートしたいものすべてのリストを作成することができます。すべて同じエンディアンを持っている場合は、心配しないでください。
セーブデータがプラットフォームからプラットフォームに移動することを期待していない場合は、気にする必要はありません。エンディアンは、ビッグエンディアンのマシンでデータを作成し、それをリトルエンディアンのマシンで読むか、その逆の場合にのみ問題になります。これらが単なるローカル・データ・ファイルであれば大したことではありませんが、ユーザーが1つのプラットフォームから別のプラットフォームへのセーブをコピーできれば、実行したくないものがほとんどありますサポートしていません。
さらに、バイトを記述するだけなので、バイト配列がデータが取得するほど複雑な場合は、実際にエンディアンを心配する必要はありません。マルチバイトデータ型の場合にのみ問題になります。バイト配列を保存するだけで、残りのブックキーピングデータもバイトに収まる場合は、心配する必要はありませんが、short、intまたはfloatを保存するとすぐにエンディアンの問題が発生します。
あなたのシリアルナンバーを考慮してシリアル化するときはいつも私の意見ではありますが、非常にマルチプラットフォームのバックグラウンド（5つのゲームシステムで同じ製品を出荷しています）があります。スワップマクロは既に存在していますが、必然的に別のエンディアンに移行することになった場合は、書き換えを行う必要はありません。データが複雑または構造化されている場合は、プロトコルバッファやBSONなどのライブラリを検討することもできます。
CPUとオペレーティングシステムの両方がエンドエンティティの原因となる場合があります。歴史的にはCPUに焼き付けられていましたが、x86はまだリトルエンディアンとしてハードウェア化されていましたが、ほとんどの現代のRISC派生物はどちらのモードでも動作できるため、ハードウェアとOS開発者を選択できます。
私は、（32ビットx86と64ビットx86_64の）CPUのワードサイズも同様に重要であると言いますが、それらはデフォルトのパッキングに影響するかもしれません。 –
よろしくお願いします...パッキングはEndianessの悪い兄弟の双子のようなものです。あなたのエンディアンに関連するシリアライゼーションの問題が何であるかを理解していると思うとき、パッキングはあなたの計画を崩壊させる方法を見つけます。 – Suboptimus
"すべてのバイトがIDを表します..."。 char、unsigned char、uint8_tのように 'bytes'はエンディアンの問題の影響を受けません。バイトレベルでは、ビットはすべて同じ順序です。 –