Blockkomprimierung

Blockkomprimierung ist eine verlustbehaftete Texturkomprimierungsmethode zum Verringern der Texturgröße und des Speicherbedarfs, was zu einer Leistungssteigerung führen kann. Eine blockkomprimierte Textur kann kleiner als eine Textur mit 32 Bit pro Farbe sein.

Blockkomprimierung ist eine Texturkomprimierungstechnik zum Verringern der Texturgröße. Im Vergleich zu einer Textur mit 32 Bit pro Farbe kann eine blockkomprimierte Textur bis zu 75 Prozent kleiner sein. Anwendungen sehen in der Regel eine Leistungssteigerung bei verwendung der Blockkomprimierung aufgrund des geringeren Speicherbedarfs.

Obwohl sie verlustbehaftet ist, funktioniert die Blockkomprimierung gut und wird für alle Texturen empfohlen, die von der Pipeline transformiert und gefiltert werden. Texturen, die direkt dem Bildschirm zugeordnet sind (UI-Elemente wie Symbole und Text) eignen sich nicht für die Komprimierung, da Artefakte deutlicher sind.

Eine blockkomprimierte Textur muss als Vielfaches von Größe 4 in allen Dimensionen erstellt werden und kann nicht als Ausgabe der Pipeline verwendet werden.

Funktionsweise der Blockkomprimierung

Blockkomprimierung ist eine Technik zum Verringern der Zum Speichern von Farbdaten erforderlichen Arbeitsspeichermenge. Durch das Speichern einiger Farben in der originalen Größe und anderen Farben mithilfe eines Codierungsschemas können Sie die Zum Speichern des Bilds erforderliche Speichermenge erheblich reduzieren. Da die Hardware komprimierte Daten automatisch decodiert, gibt es keine Leistungseinbußen für die Verwendung komprimierter Texturen.

Sehen Sie sich die folgenden beiden Beispiele an, um zu sehen, wie die Komprimierung funktioniert. Im ersten Beispiel wird die Menge an Arbeitsspeicher beschrieben, die beim Speichern von nicht komprimierten Daten verwendet wird. Im zweiten Beispiel wird die Arbeitsspeichermenge beschrieben, die beim Speichern komprimierter Daten verwendet wird.

• Speichern nicht komprimierter Daten
• Speichern komprimierter Daten

Speichern nicht komprimierter Daten

Die folgende Abbildung stellt eine nicht komprimierte 4×4-Textur dar. Angenommen, jede Farbe enthält eine einzelne Farbkomponente (z. B. Rot) und wird in einem Byte Arbeitsspeicher gespeichert.

Die nicht komprimierten Daten werden sequenziell im Arbeitsspeicher angeordnet und erfordern 16 Bytes, wie in der folgenden Abbildung dargestellt.

Speichern komprimierter Daten

Nachdem Sie nun gesehen haben, wie viel Arbeitsspeicher ein nicht komprimiertes Bild verwendet, sehen Sie sich an, wie viel Arbeitsspeicher ein komprimiertes Bild speichert. Das BC4- Komprimierungsformat speichert 2 Farben (jeweils 1 Byte) und 16 3-Bit-Indizes (48 Bit oder 6 Byte), die zum Interpolieren der Originalfarben in der Textur verwendet werden, wie in der folgenden Abbildung dargestellt.

Der Gesamtspeicherplatz, der zum Speichern der komprimierten Daten erforderlich ist, beträgt 8 Byte, was eine 50-Prozent-Speichereinsparung gegenüber dem nicht komprimierten Beispiel darstellt. Die Einsparungen sind sogar größer, wenn mehr als eine Farbkomponente verwendet wird.

Die durch die Blockkomprimierung bereitgestellten erheblichen Speichereinsparungen können zu einer Leistungssteigerung führen. Diese Leistung kommt zu Kosten der Bildqualität (aufgrund der Farbinterpolation); Die geringere Qualität ist jedoch oft nicht erkennbar.

Im nächsten Abschnitt wird gezeigt, wie Direct3D die Verwendung der Blockkomprimierung in einer Anwendung ermöglicht.

Verwenden der Blockkomprimierung

Erstellen Sie eine blockkomprimierte Textur genau wie eine nicht komprimierte Textur, mit der Ausnahme, dass Sie ein blockkomprimiertes Format angeben.

Erstellen Sie als Nächstes eine Ansicht, um die Textur an die Pipeline zu binden. Da eine blockkomprimierte Textur nur als Eingabe für eine Shader-Phase verwendet werden kann, möchten Sie eine Shader-Ressourcenansicht erstellen.

Verwenden Sie eine blockkomprimierte Textur auf die gleiche Weise wie eine nicht komprimierte Textur. Wenn Ihre Anwendung einen Speicherzeiger zum Blockieren komprimierter Daten erhält, müssen Sie den Speicherabstand in einer Mipmap berücksichtigen, die bewirkt, dass sich die deklarierte Größe von der tatsächlichen Größe unterscheidet.

• Virtuelle Größe im Vergleich zur physischen Größe

Virtuelle Größe im Vergleich zur physischen Größe

Wenn Sie über Anwendungscode verfügen, der einen Speicherzeiger verwendet, um den Speicher einer komprimierten Blocktextur zu durchlaufen, gibt es einen wichtigen Aspekt, der möglicherweise eine Änderung in Ihrem Anwendungscode erfordert. Eine blockkomprimierte Textur muss ein Vielfaches von 4 in allen Dimensionen sein, da die Blockkomprimierungsalgorithmen auf 4x4 Texelblöcken arbeiten. Dies wird ein Problem für eine Mipmap sein, deren anfängliche Dimensionen durch 4 teilbar sind, aber deren unterteilte Ebenen es nicht sind. Das folgende Diagramm zeigt den Unterschied zwischen der virtuellen (deklarierten) Größe und der physischen (tatsächlichen) Größe jeder Mipmap-Ebene.

Die linke Seite des Diagramms zeigt die Mipmap-Ebenengrößen, die für eine nicht komprimierte 60×40-Textur generiert werden. Die Größe der obersten Ebene wird vom API-Aufruf übernommen, der die Textur generiert. jede nachfolgende Ebene ist die Hälfte der Größe der vorherigen Ebene. Bei einer nicht komprimierten Textur gibt es keinen Unterschied zwischen der virtuellen (deklarierten) Größe und der physischen (tatsächlichen) Größe.

Auf der rechten Seite des Diagramms werden die Größen der Mipmap-Ebene dargestellt, die für dieselbe 60×40-Textur mit Komprimierung generiert werden. Beachten Sie, dass sowohl die zweite als auch die dritte Ebene Speicherabstand aufweisen, um die Größenfaktoren von 4 auf jeder Ebene zu machen. Dies ist erforderlich, damit die Algorithmen auf 4×4 Texelblöcken arbeiten können. Dies ist besonders offensichtlich, wenn Sie Mipmap-Ebenen berücksichtigen, die kleiner als 4 × 4 sind; die Größe dieser sehr kleinen Mipmap-Ebenen wird auf das nächste Vielfache von 4 aufgerundet, wenn Texturspeicher zugewiesen wird.

Sampling-Hardware verwendet die virtuelle Größe; wenn die Textur abgetastet wird, wird die Speicherauffüllung ignoriert. Bei Mipmap-Ebenen, die kleiner als 4×4 sind, werden für eine 2×2-Karte nur die ersten vier Texel verwendet, und für einen 1×1-Block wird nur das erste Texel verwendet. Es gibt jedoch keine API-Struktur, die die physische Größe (einschließlich des Speicherabstands) verfügbar macht.

Achten Sie zusammenfassend darauf, ausgerichtete Speicherblöcke beim Kopieren von Bereichen zu verwenden, die blockkomprimierte Daten enthalten. Um dies in einer Anwendung zu tun, die einen Speicherzeiger abruft, stellen Sie sicher, dass der Zeiger die Surface-Pitch verwendet, um die Größe des physischen Speichers zu berücksichtigen.

Komprimierungsalgorithmen

Blockkomprimierungstechniken in Direct3D unterteilen unkomprimierte Texturdaten in 4×4 Blöcke, komprimieren jeden Block und speichern dann die Daten. Aus diesem Grund wird erwartet, dass komprimierte Texturen Texturabmessungen aufweisen müssen, die Vielfache von 4 sind.

Das vorherige Diagramm zeigt eine Textur, die in Texelblöcke unterteilt ist. Der erste Block zeigt das Layout der 16 Texel mit der Bezeichnung "a-p", aber jeder Block hat dieselbe Organisation von Daten.

Direct3D implementiert mehrere Komprimierungsschemas, jedes implementiert einen anderen Kompromiss zwischen der Anzahl der gespeicherten Komponenten, der Anzahl der Bits pro Komponente und der Menge des verbrauchten Arbeitsspeichers. Verwenden Sie diese Tabelle, um das Format auszuwählen, das am besten mit dem Datentyp und der Datenauflösung funktioniert, die am besten zu Ihrer Anwendung passt.

• BC1
• BC2
• BC3
• BC4
• BC5

BC1

Verwenden Sie das erste Blockkomprimierungsformat (BC1) (entweder DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM oder DXGI_BC1_UNORM_SRGB), um drei komponentenbasierte Farbdaten mit einer Farbe von 5:6:5 (5 Bit rot, 6 Bit grün, 5 Bit Blau) zu speichern. Dies gilt auch, wenn die Daten auch 1-Bit-Alpha enthalten. Wenn eine 4×4-Textur mit dem größtmöglichen Datenformat verwendet wird, reduziert das BC1-Format den erforderlichen Speicher von 48 Byte (16 Farben × 3 Komponenten/Farbe × 1 Byte/Komponente) auf 8 Bytes Arbeitsspeicher.

Der Algorithmus arbeitet mit 4×4 Texelblöcken. Anstatt 16 Farben zu speichern, speichert der Algorithmus 2 Referenzfarben (color_0 und color_1) und 16 2-Bit-Farbindizes (Blöcke a–p), wie im folgenden Diagramm dargestellt.

Die Farbindizes (a–p) werden verwendet, um die Originalfarben aus einer Farbtabelle nachzuschlagen. Die Farbtabelle enthält vier Farben. Die ersten beiden Farben – color_0 und color_1 – sind die minimalen und maximalen Farben. Die anderen beiden Farben, color_2 und color_3, sind Zwischenfarben, die mit linearer Interpolation berechnet werden.

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

Den vier Farben werden 2-Bit-Indexwerte zugewiesen, die in den Blöcken a–p gespeichert werden.

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

Schließlich wird jede der Farben in Blöcken a–p mit den vier Farben in der Farbtabelle verglichen, und der Index für die ähnlichste Farbe wird in den 2-Bit-Blöcken gespeichert.

Dieser Algorithmus eignet sich auch für Daten, die 1-Bit-Alpha enthalten. Der einzige Unterschied besteht darin, dass color_3 auf 0 festgelegt ist (die eine transparente Farbe darstellt) und color_2 eine lineare Mischung aus color_0 und color_1 ist.

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

BC2

Verwenden Sie das BC2-Format (entweder DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM oder DXGI_BC2_UNORM_SRGB), um Daten zu speichern, die Farb- und Alphadaten mit geringer Kohärenz enthalten (verwenden Sie BC3- für hoch kohärente Alphadaten). Im BC2-Format werden RGB-Daten als 5:6:5-Farbe (5 Bit rot, 6 Bit grün, 5 Bit Blau) und Alpha als separater 4-Bit-Wert gespeichert. Wenn eine 4×4-Textur mit dem größtmöglichen Datenformat verwendet wird, reduziert diese Komprimierungstechnik den erforderlichen Speicher von 64 Byte (16 Farben × 4 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Bytes Arbeitsspeicher.

Das BC2-Format speichert Farben mit der gleichen Anzahl von Bits und demselben Datenlayout wie das Format BC1; BC2 erfordert jedoch zusätzlichen 64-Bit-Speicher, um die Alphadaten zu speichern, wie im folgenden Diagramm dargestellt.

BC3

Verwenden Sie das BC3-Format (entweder DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM oder DXGI_BC3_UNORM_SRGB), um hoch kohärente Farbdaten zu speichern (verwenden Sie BC2- mit weniger kohärenten Alphadaten). Das BC3-Format speichert Farbdaten mit 5:6:5 Farbe (5 Bit rot, 6 Bit grün, 5 Bit Blau) und Alphadaten mit einem Byte. Wenn eine 4×4-Textur mit dem größtmöglichen Datenformat verwendet wird, reduziert diese Komprimierungstechnik den erforderlichen Speicher von 64 Byte (16 Farben × 4 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Bytes Arbeitsspeicher.

Das BC3-Format speichert Farben mit der gleichen Anzahl von Bits und dem gleichen Datenlayout wie das BC1--Format; BC3 erfordert jedoch einen zusätzlichen 64-Bit-Speicher, um die Alphadaten abzulegen. Das BC3-Format verarbeitet Alpha-Werte, indem es zwei Referenzwerte speichert und dann zwischen ihnen interpoliert (ähnlich wie BC1 RGB-Farbwerte speichert).

Der Algorithmus arbeitet mit 4×4 Texelblöcken. Anstatt 16 Alphawerte zu speichern, speichert der Algorithmus 2 Referenz-Alphas (alpha_0 und alpha_1) und 16 3-Bit-Farbindizes (Alpha a bis p), wie im folgenden Diagramm dargestellt.

Das BC3-Format verwendet die Alphaindizes (a–p), um die Originalfarben aus einer Nachschlagetabelle mit 8 Werten nachzuschlagen. Die ersten beiden Werte – alpha_0 und alpha_1 – sind die Mindest- und Höchstwerte; die anderen sechs Zwischenwerte werden mit linearer Interpolation berechnet.

Der Algorithmus bestimmt die Anzahl interpolierter Alphawerte, indem die beiden Referenz-Alphawerte untersucht werden. Wenn alpha_0 größer als alpha_1 ist, interpoliert BC3 6 Alphawerte; andernfalls interpoliert er 4. Wenn BC3 nur vier Alphawerte interpoliert, werden zwei zusätzliche Alphawerte festgelegt (0 für vollständig transparent und 255 für vollständig undurchsichtig). BC3 komprimiert die Alphawerte im Bereich 4×4 Texel, indem der Bitcode gespeichert wird, der den interpolierten Alphawerten entspricht, die dem ursprünglichen Alpha für ein bestimmtes Texel am ehesten entsprechen.

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
}

BC4

Verwenden Sie das BC4-Format, um Farbdaten mit einer Komponente unter Verwendung von 8 Bit pro Komponente zu speichern. Aufgrund der erhöhten Genauigkeit (im Vergleich zu BC1) eignet sich BC4 ideal zur Speicherung von Gleitkommadaten im Bereich zwischen [0 und 1] mit dem DXGI_FORMAT_BC4_UNORM-Format und [-1 und +1] mit dem DXGI_FORMAT_BC4_SNORM-Format. Wenn eine 4×4-Textur mit dem größten möglichen Datenformat verwendet wird, reduziert diese Komprimierungstechnik den erforderlichen Speicher von 16 Byte (16 Farben × 1 Komponenten/Farbe × 1 Byte/Komponente) auf 8 Bytes.

Der Algorithmus arbeitet mit 4×4 Texelblöcken. Anstatt 16 Farben zu speichern, speichert der Algorithmus 2 Referenzfarben (red_0 und red_1) und 16 3-Bit-Farbindizes (rot a bis rot p), wie im folgenden Diagramm dargestellt.

Der Algorithmus verwendet die 3-Bit-Indizes, um Farben aus einer Farbtabelle mit 8 Farben nachzuschlagen. Die ersten beiden Farben – red_0 und red_1 – sind die minimalen und maximalen Farben. Der Algorithmus berechnet die verbleibenden Farben mithilfe der linearen Interpolation.

Der Algorithmus bestimmt die Anzahl der interpolierten Farbwerte, indem er die beiden Referenzwerte untersucht. Wenn red_0 größer als red_1 ist, interpoliert BC4 6 Farbwerte; andernfalls interpoliert er 4. Wenn BC4 nur vier Farbwerte interpoliert, werden zwei zusätzliche Farbwerte festgelegt (0,0f für vollständig transparent und 1,0f für vollständig undurchsichtig). BC4 komprimiert die Alphawerte im 4×4 Texel-Bereich, indem der Bitcode gespeichert wird, der den interpolierten Alphawerten am ähnlichsten ist und das ursprüngliche Alpha eines bestimmten Texels am besten wiedergibt.

• BC4_UNORM
• BC4_SNORM

BC4_UNORM

Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel.

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
}

Die Referenzfarben werden 3-Bit-Indizes zugewiesen (000–111, da es 8 Werte gibt), die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.

BC4_SNORM

Die DXGI_FORMAT_BC4_SNORM ist identisch, mit der Ausnahme, dass die Daten im SNORM-Bereich codiert sind und 4 Farbwerte interpoliert werden. Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel.

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
}

Die Referenzfarben werden 3-Bit-Indizes zugewiesen (000–111, da es 8 Werte gibt), die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.

BC5

Verwenden Sie das BC5-Format, um zwei Komponentenfarbdaten mit 8 Bit für jede Farbe zu speichern. Aufgrund der erhöhten Genauigkeit (im Vergleich zu BC1) eignet sich BC5 ideal zum Speichern von Gleitkommadaten im Bereich von [0 bis 1] mithilfe des DXGI_FORMAT_BC5_UNORM Formats und [-1 bis +1] mithilfe des DXGI_FORMAT_BC5_SNORM Formats. Wenn eine 4×4-Textur mit dem größten möglichen Datenformat verwendet wird, reduziert diese Komprimierungstechnik den erforderlichen Speicher von 32 Byte (16 Farben × 2 Komponenten/Farbe × 1 Byte/Komponente) auf 16 Byte.

• BC5_UNORM
• BC5_SNORM

Der Algorithmus arbeitet mit 4×4 Texelblöcken. Anstatt 16 Farben für beide Komponenten zu speichern, speichert der Algorithmus 2 Referenzfarben für jede Komponente (red_0, red_1, green_0 und green_1) und 16 3-Bit-Farbindizes für jede Komponente (rot a bis rot p und grün a bis grün p), wie im folgenden Diagramm dargestellt.

Der Algorithmus verwendet die 3-Bit-Indizes, um Farben aus einer Farbtabelle mit 8 Farben nachzuschlagen. Die ersten beiden Farben – red_0 und red_1 (oder green_0 und green_1) – sind die minimalen und maximalen Farben. Der Algorithmus berechnet die verbleibenden Farben mithilfe der linearen Interpolation.

Der Algorithmus bestimmt die Anzahl der interpolierten Farbwerte, indem er die beiden Referenzwerte untersucht. Wenn red_0 größer als red_1 ist, interpoliert BC5 6 Farbwerte; andernfalls interpoliert er 4. Wenn BC5 nur vier Farbwerte interpoliert, werden die verbleibenden beiden Farbwerte auf 0,0f und 1,0f festgelegt.

BC5_UNORM

Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel. Die Berechnungen für die grünen Komponenten sind ähnlich.

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
}

Die Referenzfarben werden 3-Bit-Indizes zugewiesen (000–111, da es 8 Werte gibt), die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.

BC5_SNORM

Die DXGI_FORMAT_BC5_SNORM ist identisch, mit der Ausnahme, dass die Daten im SNORM-Bereich codiert sind und wenn vier Datenwerte interpoliert werden, sind die beiden zusätzlichen Werte -1,0f und 1,0f. Die Interpolation der Einzelkomponentendaten erfolgt wie im folgenden Codebeispiel. Die Berechnungen für die grünen Komponenten sind ähnlich.

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
}

Die Referenzfarben werden 3-Bit-Indizes zugewiesen (000–111, da es 8 Werte gibt), die während der Komprimierung in Blöcken rot a bis rot p gespeichert werden.

Formatkonvertierung

Direct3D ermöglicht Kopien zwischen vorstrukturierten Texturen und blockkomprimierten Texturen derselben Bitbreite.

Sie können Ressourcen zwischen einigen Formattypen kopieren. Dieser Kopiervorgangstyp führt eine Formatkonvertierung durch, die Ressourcendaten als einen anderen Formattyp neu interpretiert. Betrachten Sie dieses Beispiel, das den Unterschied zwischen dem Erneutinterpretieren von Daten mit dem Verhalten eines typischeren Konvertierungstyps zeigt:

FLOAT32 f = 1.0f;
UINT32 u;

Um "f" als den Typ von "u" neu zu interpretieren, verwenden Sie memcpy.

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

In der vorherigen Neuinterpretation ändert sich der zugrunde liegende Wert der Daten nicht; memcpy interpretiert den Float als eine Ganzzahl ohne Vorzeichen neu.

Um den typischeren Typ der Konvertierung auszuführen, verwenden Sie die Zuweisung:

u = f; // 'u' becomes 1.

In der vorherigen Konvertierung ändert sich der zugrunde liegende Wert der Daten.

In der folgenden Tabelle sind die zulässigen Quell- und Zielformate aufgeführt, die Sie in diesem Neuinterpretationstyp der Formatkonvertierung verwenden können. Sie müssen die Werte ordnungsgemäß codieren, damit die Neuinterpretation wie erwartet funktioniert.

Verwandte Themen

Komprimierte Texturressourcen