● ToolBox API徒然草（2006/05/26）

今回は、前回に引き続いてもう少しリソースデータについての例題を調べてみます。また、効率の良いエンディアンの反転方法についても考察してみます。

以下のaddIconResources()は、FSpOpenResFile()などでオープンされたカレントのリソースファイルに、48x48ピクセルのフルカラー画像アイコンリソースを付加するルーチンです。何故だか、現在のCarbon APIやQuickTime APIにはファイル（JPEGやTIFF）に画像アイコンを手軽に付加するAPIが存在しないために、こうした自作ルーチンが必要となります。アイコン用の画像は、引数で渡されたCGrafPtr（GWorldオフスクリーン）に先んじて描画されていることが条件です。

ここでは、リソースタイプが'icns'でリソースIDが-16455のリソースをAddResource()を用いて付加しています。'icns'リソースは、マスク画像、白黒画像、フルカラー画像など複数のアイコン情報を含むデータ構造を取っています。そのため、データの先頭に各データのタイプ（'icns'と'ich#'と'ih32'）とそのサイズ（容量）を保存します。これらの情報（数値）は、すべてビッグエンディアンフォーマットでリソースフォークへ保存されていますので、Intel CPU版のアプリケーションでは保存前にエンディアンを反転する必要があります。




こうして見てくると、エンディアンの反転は、データをファイルに保存する直前かファイルから読み込んだ直後に行うことが多いようです。しかし、こうした処理をファイルI/Oが発生する度にいちいち追加していては面倒ですし、必要な処理を見落としてしまう危険性もあります。そこで、以下の様にFSWriteFork()やFSReadFork()と自作フリッパーを組み合わせた上位ファイルI/Oルーチンを用意しておくと便利です。ファイルへ読み書きするフォーマット（構造体）の種類をOSTypeで指示してやることで、エンディアンの反転処理を一元管理することが可能です。ちょうどApple社が用意したカスタムリソースデータのフリッパーと同じ仕組みです。



こうした処理が必要なのは、ファイル保存されているデータフォーマットがエンディアンの違いに影響を受ける場合に限られます。つまり、shortやlongの整数値、floatやdoubleの浮動小数点値が、そのままファイルへ保存されている場合です。保存フォーマットがリトルエンディアンであれば、PowerPC用アプリケーションのファイルI/Oで反転する必要がありますし、逆にビッグエンディアンであればIntel CPU用アプリケーションで反転する必要があります。ちなみに、保存形式がテキストデータやXMLデータなどエンディアンの違いに影響されないフォーマットであれば、その必要はありません。

次回は、画像（ビットフィールド）を処理するアプリケーションにおけるエンディアンの違いの影響について調べてみます。例題として、OpenGLのテクスチャ画像を作成する場合などについて解説する予定です。