ブロック圧縮 (Direct3D 10)

[アーティクル]
06/13/2023

ブロック圧縮とは、テクスチャサイズを減少させるテクスチャの圧縮方法です。各色 32 ビットのテクスチャと比較すると、ブロック圧縮されたテクスチャは最大 75% 縮小できます。ブロック圧縮を使用すると、メモリフットプリントが小さくなり、アプリケーションでは通常、パフォーマンスが向上します。

ブロック圧縮は不可逆圧縮ですが、効果的であり、パイプラインで変換およびフィルターされたすべてのテクスチャに推奨されます。画面に直接マッピングされるテクスチャ (アイコンやテキストのような UI 要素) は、処理結果が比較的目立つので、圧縮にはあまり適していません。

ブロック圧縮されたテクスチャは、すべての次元で 4 の倍数のサイズで作成する必要があります。またパイプラインの出力として使用することはできません。

ブロック圧縮のしくみ
- 圧縮されていないデータの格納
- 圧縮データの格納
ブロック圧縮の使用
- 仮想サイズと物理サイズ
圧縮アルゴリズム
- BC1
- BC2
- BC3
- BC4
- BC5
Direct3D 10.1 を使用した書式変換
関連トピック

ブロック圧縮のしくみ

ブロック圧縮は、カラーデータの保存に必要なメモリの量を減少させるための方法です。ある色を元のサイズで保存し、他の色をエンコードスキームを使用して保存することにより、その画像の保存に必要なメモリの量を大幅に減少させることができます。圧縮されたデータはハードウェアが自動的にデコードするので、圧縮されたテクスチャを使用しても、パフォーマンスの損失は発生しません。

圧縮がどのように行われるかについては、以下の 2 つの例を参照してください。最初の例では、圧縮されないデータを保存する際に使用されるメモリの量について説明します。2 番目の例では、圧縮されたデータを保存する際に使用されるメモリの量について説明します。

圧縮されていないデータの格納

以下のイメージは、圧縮されていない 4x4 のテクスチャを表しています。各色には、単一のカラー成分 (たとえば赤) が含まれ、1 バイトのメモリに保存されているとします。

非圧縮の 4 x 4 テクスチャの図

圧縮されていないデータはメモリに順次レイアウトされ、以下のイメージに示すように、16 バイト必要となります。

シーケンシャルメモリ内の非圧縮データの図

圧縮データの格納

圧縮されていないイメージがどれぐらいの量のメモリを使用するかを理解したところで、圧縮されたイメージがどれだけ多くのメモリを使わずに済むかを説明します。 BC4 圧縮形式では、次の図に示すように、テクスチャの元の色を補間するために使用される 2 色 (各 1 バイト) と 16 個の 3 ビットインデックス (48 ビットまたは 6 バイト) が格納されます。

bc4 圧縮形式の図

圧縮されたデータを保存するのに必要な領域の合計は 8 バイトで、圧縮されていない例に比べて 50% のメモリを使用せずに済んでいます。 1 つ以上のカラー成分を使用する場合、使用せずに済む量はさらに多くなります。

ブロック圧縮によってかなりの量のメモリを使用せずに済むことで、パフォーマンスの向上につなげることができます。このパフォーマンスは、イメージの画質の代償として得られるものですが (色の補間による)、多くの場合、画質の低下は顕著ではありません。

次のセクションでは、Direct3D 10 を使用して、アプリケーションでブロック圧縮を簡単に使用する方法を示します。

ブロック圧縮の使用

ブロック圧縮形式を指定する以外は、非圧縮テクスチャと同様にブロック圧縮テクスチャを作成します ( 「ファイルからテクスチャを作成する」を参照)。

loadInfo.Format = DXGI_FORMAT_BC1_UNORM;
D3DX10CreateTextureFromFile(...);

次に、テクスチャをパイプラインにバインドするビューを作成します。ブロック圧縮テクスチャはシェーダーステージへの入力としてのみ使用できるため、 CreateShaderResourceView を呼び出してシェーダーリソースビューを作成します。

ブロック圧縮されたテクスチャを、圧縮されていないテクスチャを使用する場合と同様に使用します。アプリケーションがブロック圧縮データへのメモリポインターを取得する場合は、ミップマップのメモリパディングを考慮する必要があります。このメモリパディングは、宣言されたサイズが実際のサイズと異なる原因となります。

仮想サイズと物理サイズ

メモリポインターを使用して、ブロック圧縮されたテクスチャのメモリを扱うアプリケーションコードがある場合、アプリケーションコードの変更が必要となる可能性がある重要な考慮事項が 1 つあります。ブロック圧縮アルゴリズムは 4 x 4 のテクセルブロックで処理するため、ブロック圧縮されたテクスチャはすべての次元で 4 の倍数である必要があります。これは、最初の次元が 4 で割り切れるが、さらに分割すると 4 で割り切れなくなるミップマップでは問題となります。以下の図は、各ミップマップレベルの仮想サイズ (宣言されたサイズ) と物理サイズ (実際のサイズ) の間の領域の違いを示しています。

圧縮されていないミップマップレベルと圧縮ミップマップレベルの図

図の左側は、圧縮されていない 60 x 40 のテクスチャに対して生成されるミップマップレベルサイズを示しています。最上位レベルのサイズは、テクスチャを生成する API 呼び出しから取得されます。後続の各レベルは、前のレベルのサイズの半分になります。圧縮されていないテクスチャでは、仮想サイズ (宣言されたサイズ) と物理サイズ (実際のサイズ) との間で差はありません。

図の右側は、圧縮された 60 x 40 のテクスチャに対して生成されるミップマップレベルサイズを示しています。 2 番目と 3 番目のレベルにはどちらも、各レベルのサイズが 4 で割り切れるように、メモリパディングが追加されていることに注意してください。これは、アルゴリズムが 4 x 4 のテクセルブロックで処理できるようにするために必要です。 4 x 4 よりも小さいミップマップレベルを考慮する場合、これは特に明白です。これらの非常に小さいミップマップレベルのサイズは、テクスチャメモリが割り当てられる際、4 を因数とする最も近い数に切り上げられます。

サンプリングハードウェアは仮想サイズを使用します。テクスチャがサンプリングされる際、メモリパディングは無視されます。 4 x 4 よりも小さいミップマップレベルでは、最初の 4 つのテクセルのみが 2 x 2 のマップに使用され、最初のテクセルのみが 1 x 1 のブロックで使用されます。ただし、物理サイズ (メモリパディングを含む) を明らかにする API 構造はありません。

つまり、ブロック圧縮したデータを含む領域をコピーする際は、アライメントされたメモリブロックは注意して使用してください。メモリポインターを取得するアプリケーションでこれを実行するには、必ずそのポインターがサーフェスピッチを使用して物理メモリサイズを明らかにするようにします。

圧縮アルゴリズム

Direct3D のブロック圧縮方法では、圧縮されていないテクスチャデータを 4 x 4 のブロックに分割し、各ブロックを圧縮してから、そのデータを保存します。このため、圧縮が必要なテクスチャには、4 の倍数のテクスチャ寸法が必要です。

ブロック圧縮の図

上の図は、テクセルブロックに分割されたテクスチャを示しています。最初のブロックは、a ～ p のラベルがついた 16 のテクセルのレイアウトを示していますが、各ブロックには同じ構造のデータがあります。

Direct3D は圧縮スキームをいくつか実装しています。それぞれ、保存される成分数、成分ごとのビット数、および消費されるメモリ量の間で異なるトレードオフが存在します。この表を使用すると、アプリケーションに最適なデータの種類とデータ解像度で、最も効果的に機能する形式を選択するのに役立ちます。

ソースデータ	データ圧縮解像度 (ビット)	選択する圧縮形式
成分が 3 つの色およびアルファ	カラー (5:6:5)、アルファ (1) またはアルファなし	BC1
成分が 3 つの色およびアルファ	カラー (5:6:5)、アルファ (4)	BC2
成分が 3 つの色およびアルファ	カラー (5:6:5)、アルファ (8)	BC3
成分が 1 つの色	1 つの成分 (8)	BC4
成分が 2 つの色	2 つの成分 (8:8)	BC5

BC1

5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) を使用する 3 つの成分のカラーデータを保存するには、最初のブロック圧縮形式 (BC1) (DXGI_FORMAT_BC1_TYPELESS、DXGI_FORMAT_BC1_UNORM、または DXGI_BC1_UNORM_SRGB のいずれか) を使用します。データに 1 ビットのアルファが含まれている場合も、これが当てはまります。 4 x 4 のテクスチャが、可能な限り最も大きなデータ形式を使用することを想定すると、BC1 形式では必要なメモリが 48 バイト (16 色× 3 成分/色× 1 バイト/成分) から 8 バイトに減少します。

このアルゴリズムは、4 x 4 ブロックのテクセルで機能します。 16 色を保存する代わりに、このアルゴリズムでは、2 つの参照カラー (color_0 および color_1) と 16 個の 2 ビットカラーインデックス (a から p のブロック) を保存します。

bc1 圧縮のレイアウトの図

カラーインデックス (a ～ p) は、カラーテーブルから元の色を検索するために使用します。カラーテーブルには 4 つの色が含まれます。最初の 2 色、color_0 および color_1 は、最小および最大の色です。その他の 2 色、color_2 および color_3 は、線形補間で計算された中間色です。

color_2 = 2/3*color_0 + 1/3*color_1
color_3 = 1/3*color_0 + 2/3*color_1

4 つの色は、a ～ p のブロックに保存される 2 ビットのインデックス値を割り当てられます。

color_0 = 00
color_1 = 01
color_2 = 10
color_3 = 11

最後に、a ～ p のブロックの各色がカラーテーブルの 4 つの色と比較され、最も近い色のインデックスが 2 ビットブロックに保存されます。

このアルゴリズムは、1 ビットのアルファが含まれているデータにも適しています。違いは、color_3 が 0 (透明色を表します) に設定されることと、color_2 が color_0 と color_1 の線形ブレンドであることのみです。

color_2 = 1/2*color_0 + 1/2*color_1;
color_3 = 0;

Direct3D 9 と Direct3D 10 の違い:

この形式は、Direct3D 9 と 10 の両方に存在します。

Direct3D 9 では、BC1 形式は D3DFMT_DXT1 と呼ばれます。
Direct3D 10 では、BC1 形式は DXGI_FORMAT_BC1_UNORM または DXGI_FORMAT_BC1_UNORM_SRGB で表されます。

BC2

整合性が低いカラーデータおよびアルファデータが含まれているデータを保存するには、BC2 形式 (DXGI_FORMAT_BC2_TYPELESS、DXGI_FORMAT_BC2_UNORM、または DXGI_BC2_UNORM_SRGB のいずれか) を使用します (整合性が高いアルファデータには BC3 を使用します)。 BC2 形式は、RGB データを 5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) で、アルファを独立した 4 ビットの値で保存します。 4 x 4 のテクスチャが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリが 64 バイト (16 色 x 4 成分/色 x 1 バイト/成分) から 16 バイトに減少します。

BC2 形式では、BC1 形式と同じビット数およびデータレイアウトで色を保存しますが、BC2 ではアルファデータを保存するためにさらに 64 ビットのメモリが必要です。

bc2 圧縮のレイアウトの図

Direct3D 9 と Direct3D 10 の違い:

この形式は、Direct3D 9 と 10 の両方に存在します。

Direct3D 9 では、BC2 形式は D3DFMT_DXT2 および D3DFMT_DXT3 と呼ばれます。
Direct3D 10 では、BC2 形式は DXGI_FORMAT_BC2_UNORM または DXGI_FORMAT_BC2_UNORM_SRGB で表されます。

BC3

整合性の高いカラーデータを保存するには、BC3 形式 (DXGI_FORMAT_BC3_TYPELESS、DXGI_FORMAT_BC3_UNORM、または DXGI_BC3_UNORM_SRGB のいずれか) を使用します (整合性の低いアルファデータには BC2 を使用します)。 BC3 形式では、5:6:5 の色 (赤が 5 ビット、緑が 6 ビット、青が 5 ビット) を使用してカラーデータを、1 バイトを使用してアルファデータを保存します。 4 x 4 のテクスチャが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリが 64 バイト (16 色 x 4 成分/色 x 1 バイト/成分) から 16 バイトに減少します。

BC3 形式では、BC1 形式と同じビット数およびデータレイアウトで色を保存しますが、BC3 ではアルファデータを保存するためにさらに 64 ビットのメモリが必要です。 BC3 形式では、2 つの参照値を保存し、その 2 つの間を補間することによってアルファを処理します (BC1 で RGB カラーを保存する方法と類似しています)。

このアルゴリズムは、4 x 4 ブロックのテクセルで機能します。 16 個のアルファ値を保存する代わりに、このアルゴリズムでは、2 つの参照アルファ (alpha_0 および alpha_1) と 16 個の 3 ビットカラーインデックス (a から p のアルファ) を保存します。

bc3 圧縮のレイアウトの図

BC3 形式では、アルファインデックス (a ～ p) を使用して、8 つの値が含まれるルックアップテーブルから元の色を検索します。最初の 2 つの値である alpha_0 および alpha_1 は、最小値と最大値です。その他の 6 つの中間値は、線形補間を使用して計算されます。

このアルゴリズムでは、2 つの参照アルファ値を調べることで、補間アルファ値の数を決定します。 alpha_0 が alpha_1 より大きい場合、BC3 では 6 つのアルファ値を補間します。それ以外の場合は、4 つの値を補間します。 BC3 でアルファ値を 4 つのみ補間するときは、追加のアルファ値 (0 は完全に透明、255 は完全に不透明) を 2 つ設定します。 BC3 では、指定されたテクセルの元のアルファに最も近い補間アルファ値に対応するビットコードを保存することにより、4 x 4 のテクセル領域にアルファ値を圧縮します。

if( alpha_0 > alpha_1 )
{
  // 6 interpolated alpha values.
  alpha_2 = 6/7*alpha_0 + 1/7*alpha_1; // bit code 010
  alpha_3 = 5/7*alpha_0 + 2/7*alpha_1; // bit code 011
  alpha_4 = 4/7*alpha_0 + 3/7*alpha_1; // bit code 100
  alpha_5 = 3/7*alpha_0 + 4/7*alpha_1; // bit code 101
  alpha_6 = 2/7*alpha_0 + 5/7*alpha_1; // bit code 110
  alpha_7 = 1/7*alpha_0 + 6/7*alpha_1; // bit code 111
}
else
{
  // 4 interpolated alpha values.
  alpha_2 = 4/5*alpha_0 + 1/5*alpha_1; // bit code 010
  alpha_3 = 3/5*alpha_0 + 2/5*alpha_1; // bit code 011
  alpha_4 = 2/5*alpha_0 + 3/5*alpha_1; // bit code 100
  alpha_5 = 1/5*alpha_0 + 4/5*alpha_1; // bit code 101
  alpha_6 = 0;                         // bit code 110
  alpha_7 = 255;                       // bit code 111
}

Direct3D 9 と Direct3D 10 の違い:

Direct3D 9 では、BC3 形式は D3DFMT_DXT4 および D3DFMT_DXT5 と呼ばれます。
Direct3D 10 では、BC3 形式は DXGI_FORMAT_BC3_UNORM または DXGI_FORMAT_BC3_UNORM_SRGB で表されます。

BC4

成分が 1 つのカラーデータを、各色に 8 ビット使用して保存するには、BC4 形式を使用します。精度が向上する結果 (BC1 との比較)、BC4 は、[0 ～ 1] の範囲では DXGI_FORMAT_BC4_UNORM 形式を使用し、[-1 ～ +1] の範囲では DXGI_FORMAT_BC4_SNORM 形式を使用して、浮動小数点データを保存するのに最適です。 4 x 4 のテクスチャが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリが 16 バイト (16 色 x 1 成分/色 x 1 バイト/成分) から 8 バイトに減少します。

このアルゴリズムは、4 x 4 ブロックのテクセルで機能します。 16 色を保存する代わりに、このアルゴリズムでは、次の図で示すように、2 つの参照カラー (red_0 および red_1) と 16 個の 3 ビットカラーインデックス (red a から red p) を保存します。

bc4 圧縮のレイアウトの図

このアルゴリズムでは、3 ビットのインデックスを使用して、8 色が含まれるカラーテーブルから色を検索します。最初の 2 色、red_0 および red_1 は、最小および最大の色です。このアルゴリズムでは、線形補間を使用して残りの色を計算します。

このアルゴリズムでは、2 つの参照値を調べることで、補間されるカラー値の数を決定します。 red_0 が red_1 より大きい場合、BC4 では 6 つのカラー値を補間します。それ以外の場合は、4 つの値を補間します。 BC4 でカラー値を 4 つのみ補間するときは、追加のカラー値 (0.0f は完全に透明、1.0f は完全に不透明) を 2 つ設定します。 BC4 では、指定されたテクセルの元のアルファに最も近い補間アルファ値に対応するビットコードを保存することにより、4 x 4 のテクセル領域にアルファ値を圧縮します。

BC4_UNORM

単一成分データの補間は、以下のコードサンプルのように行われます。

unsigned word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = 0.0f;                     // bit code 110
  red_7 = 1.0f;                     // bit code 111
}

参照カラーは 3 ビットのインデックス (8 つの値があるので 000 ～ 111) を割り当てられます。このインデックスは、圧縮時に red a ～ red p のブロックに保存されます。

BC4_SNORM

DXGI_FORMAT_BC4_SNORM は、SNORM 範囲でデータがエンコードされることと、4 つのカラー値が補間される場合を除いて、まったく同じです。単一成分データの補間は、以下のコードサンプルのように行われます。

signed word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = -1.0f;                     // bit code 110
  red_7 =  1.0f;                     // bit code 111
}

BC5

成分が 2 つのカラーデータを、各色に 8 ビット使用して保存するには、BC5 形式を使用します。精度が向上する結果 (BC1 との比較)、BC5 は、[0 ～ 1] の範囲では DXGI_FORMAT_BC5_UNORM 形式を使用し、[-1 ～ +1] の範囲では DXGI_FORMAT_BC5_SNORM 形式を使用して、浮動小数点データを保存するのに最適です。 4 x 4 のテクスチャが、可能な限り最も大きなデータ形式を使用すると想定すると、この圧縮方法では必要なメモリが 32 バイト (16 色 x 2 成分/色 x 1 バイト/成分) から 16 バイトに減少します。

このアルゴリズムは、4 x 4 ブロックのテクセルで機能します。 2 つの成分でそれぞれ 16 色を保存する代わりに、このアルゴリズムでは各成分で 2 つの参照カラー (red_0、red_1、green_0、および green_1) と、各成分で 16 個の 3 ビットカラーインデックス (red a から red p および green a から green p) を保存します。

bc5 圧縮のレイアウトの図

このアルゴリズムでは、3 ビットのインデックスを使用して、8 色が含まれるカラーテーブルから色を検索します。最初の 2 色、red_0 および red_1 (または green_0 および green_1) は、最小および最大の色です。このアルゴリズムでは、線形補間を使用して残りの色を計算します。

このアルゴリズムでは、2 つの参照値を調べることで、補間されるカラー値の数を決定します。 red_0 が red_1 より大きい場合、BC5 では 6 つのカラー値を補間します。それ以外の場合は、4 つの値を補間します。 BC5 でカラー値を 4 つのみ補間するときは、残りの 2 つのカラー値を 0.0f と 1.0f に設定します。

BC5_UNORM

単一成分データの補間は、以下のコードサンプルのように行われます。 green の成分の計算も同様です。

unsigned word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = 0.0f;                     // bit code 110
  red_7 = 1.0f;                     // bit code 111
}

BC5_SNORM

DXGI_FORMAT_BC5_SNORM は、SNORM 範囲でデータがエンコードされることと、4 つのデータ値が補間され、-1.0f と 1.0f の 2 つの値が追加される場合を除いて、まったく同じです。単一成分データの補間は、以下のコードサンプルのように行われます。 green の成分の計算も同様です。

signed word red_0, red_1;

if( red_0 > red_1 )
{
  // 6 interpolated color values
  red_2 = (6*red_0 + 1*red_1)/7.0f; // bit code 010
  red_3 = (5*red_0 + 2*red_1)/7.0f; // bit code 011
  red_4 = (4*red_0 + 3*red_1)/7.0f; // bit code 100
  red_5 = (3*red_0 + 4*red_1)/7.0f; // bit code 101
  red_6 = (2*red_0 + 5*red_1)/7.0f; // bit code 110
  red_7 = (1*red_0 + 6*red_1)/7.0f; // bit code 111
}
else
{
  // 4 interpolated color values
  red_2 = (4*red_0 + 1*red_1)/5.0f; // bit code 010
  red_3 = (3*red_0 + 2*red_1)/5.0f; // bit code 011
  red_4 = (2*red_0 + 3*red_1)/5.0f; // bit code 100
  red_5 = (1*red_0 + 4*red_1)/5.0f; // bit code 101
  red_6 = -1.0f;                    // bit code 110
  red_7 =  1.0f;                    // bit code 111
}

Direct3D 10.1 を使用した書式変換

Direct3D 10.1 では、同じビット幅の事前構造化型テクスチャとブロック圧縮テクスチャ間のコピーが可能になります。これを実現できる関数は 、CopyResource と CopySubresourceRegion です。

Direct3D 10.1 以降では、 CopyResource と CopySubresourceRegion を使用して、いくつかの形式の種類間でコピーできます。このようなコピー操作では、そのリソースデータを異なる形式として再解釈する、一種の形式変換を実行します。より一般的な変換の動作と、データの再解釈との違いを示す、この例をご覧ください。

    FLOAT32 f = 1.0f;
    UINT32 u;

'f' を 'u' の型として再解釈するには、 memcpy を使用します。

    memcpy( &u, &f, sizeof( f ) ); // ‘u’ becomes equal to 0x3F800000.

上の再解釈では、基になるデータの値は変更されません。memcpy は浮動小数点数を符号なし整数として再解釈します。

より一般的な変換を実行するには、割り当てを使用します。

    u = f; // ‘u’ becomes 1.

上の変換では、基になるデータの値が変更されます。

次の表は、このような再解釈による形式変換に使用できる、変換元と変換先の形式を示しています。再解釈が期待どおりに動作するためには、値を適切にエンコードする必要があります。

ビット幅	圧縮されていないリソース	ブロック圧縮されたリソース
32	DXGI_FORMAT_R32_UINT DXGI_FORMAT_R32_SINT	DXGI_FORMAT_R9G9B9E5_SHAREDEXP
64	DXGI_FORMAT_R16G16B16A16_UINT DXGI_FORMAT_R16G16B16A16_SINT DXGI_FORMAT_R32G32_UINT DXGI_FORMAT_R32G32_SINT	DXGI_FORMAT_BC1_UNORM[_SRGB] DXGI_FORMAT_BC4_UNORM DXGI_FORMAT_BC4_SNORM
128	DXGI_FORMAT_R32G32B32A32_UINT DXGI_FORMAT_R32G32B32A32_SINT	DXGI_FORMAT_BC2_UNORM[_SRGB] DXGI_FORMAT_BC3_UNORM[_SRGB] DXGI_FORMAT_BC5_UNORM DXGI_FORMAT_BC5_SNORM

リソース (Direct3D 10)

ブロック圧縮 (Direct3D 10)

ブロック圧縮のしくみ

圧縮されていないデータの格納

圧縮データの格納

ブロック圧縮の使用

仮想サイズと物理サイズ

圧縮アルゴリズム

BC1

BC2

BC3

BC4

BC4_UNORM

BC4_SNORM

BC5

BC5_UNORM

BC5_SNORM

Direct3D 10.1 を使用した書式変換

フィードバック

フィードバック

その他のリソース

ブロック圧縮 (Direct3D 10)

ブロック圧縮のしくみ

圧縮されていないデータの格納

圧縮データの格納

ブロック圧縮の使用

仮想サイズと物理サイズ

圧縮アルゴリズム

BC1

BC2

BC3

BC4

BC4_UNORM

BC4_SNORM

BC5

BC5_UNORM

BC5_SNORM

Direct3D 10.1 を使用した書式変換

関連トピック

フィードバック

フィードバック

その他のリソース