Kompresja bloku (Direct3D 10)

Kompresja blokowa jest techniką kompresji tekstury w celu zmniejszenia rozmiaru tekstury. W porównaniu z teksturą z 32-bitowymi kolorami tekstura kompresowana blokowo może być do 75 procent mniejsza. Aplikacje zwykle widzą wzrost wydajności podczas korzystania z kompresji bloku ze względu na mniejsze zużycie pamięci.

Podczas utraty kompresja bloków działa dobrze i jest zalecana dla wszystkich tekstur, które są przekształcane i filtrowane przez potok. Tekstury, które są bezpośrednio mapowane na ekran (elementy interfejsu użytkownika, takie jak ikony i tekst), nie są dobrymi wyborami do kompresji, ponieważ artefakty są bardziej zauważalne.

Tekstura skompresowana blokowo musi zostać utworzona jako wielokrotność rozmiaru 4 we wszystkich wymiarach i nie może być używana jako dane wyjściowe potoku.

• Jak działa kompresja bloku?
  • przechowywanie nieskompresowanych danych
  • przechowywanie skompresowanych danych
• przy użyciu kompresji bloku
  • rozmiar wirtualny a rozmiar fizyczny
• algorytmy kompresji
  • BC1
  • BC2
  • BC3
  • BC4
  • BC5
• konwersji formatu przy użyciu Direct3D 10.1
• Tematy pokrewne

Jak działa kompresja bloku?

Kompresja blokowa to technika zmniejszania ilości pamięci wymaganej do przechowywania danych kolorów. Przechowując niektóre kolory w oryginalnym rozmiarze i innych kolorach przy użyciu schematu kodowania, można znacznie zmniejszyć ilość pamięci wymaganej do przechowywania obrazu. Ponieważ sprzęt automatycznie dekoduje skompresowane dane, nie ma kary za używanie skompresowanych tekstur.

Aby zobaczyć, jak działa kompresja, zapoznaj się z następującymi dwoma przykładami. W pierwszym przykładzie opisano ilość pamięci używanej podczas przechowywania nieskompresowanych danych; W drugim przykładzie opisano ilość pamięci używanej podczas przechowywania skompresowanych danych.

Przechowywanie nieskompresowanych danych

Poniższa ilustracja przedstawia nieskompresowaną teksturę 4×4. Załóżmy, że każdy kolor zawiera pojedynczy składnik koloru (na przykład czerwony) i jest przechowywany w jednym bajtzie pamięci.

Nieskompresowane dane są rozmieszczone sekwencyjnie w pamięci i wymagają 16 bajtów, jak pokazano na poniższej ilustracji.

Przechowywanie skompresowanych danych

Teraz, gdy wiesz już, ile pamięci używa nieskompresowany obraz, zobacz, ile pamięci zapisuje skompresowany obraz. Format kompresji BC4 przechowuje 2 kolory (1 bajt każdy) i 16 3-bitowych indeksów (48 bitów lub 6 bajtów), które są używane do interpolacji oryginalnych kolorów w teksturze, jak pokazano na poniższej ilustracji.

formatu kompresji bc4

Łączna ilość miejsca wymagana do przechowywania skompresowanych danych wynosi 8 bajtów, co stanowi 50-procentowe oszczędności pamięci w przypadku nieskompresowanego przykładu. Oszczędności są jeszcze większe, gdy jest używany więcej niż jeden składnik kolorów.

Znaczne oszczędności pamięci zapewniane przez kompresję bloków mogą prowadzić do wzrostu wydajności. Ta wydajność wiąże się z kosztem jakości obrazu (ze względu na interpolację kolorów); jednak niższa jakość często nie jest zauważalna.

W następnej sekcji pokazano, jak direct3D 10 ułatwia korzystanie z kompresji bloków w aplikacji.

Korzystanie z kompresji bloku

Utwórz teksturę skompresowaną blokowo tak samo jak nieskompresowaną teksturę (zobacz Tworzenie tekstury z pliku), z tą różnicą, że określono format skompresowany blokowo.

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

Następnie utwórz widok, aby powiązać teksturę z potokiem. Ponieważ tekstura skompresowana blokowo może być używana tylko jako dane wejściowe do etapu cieniowania, chcesz utworzyć widok cieniowania zasobów, wywołując CreateShaderResourceView.

Użyj tekstury skompresowanej bloku w taki sam sposób, jak w przypadku użycia nieskompresowanej tekstury. Jeśli aplikacja otrzyma wskaźnik pamięci w celu zablokowania skompresowanych danych, musisz uwzględnić wypełnienie pamięci w mapie mip, która powoduje, że zadeklarowany rozmiar różni się od rzeczywistego rozmiaru.

Rozmiar wirtualny a rozmiar fizyczny

Jeśli masz kod aplikacji, który używa wskaźnika pamięci do chodzenia pamięci pamięci skompresowanej tekstury bloku, istnieje jedna ważna kwestia, która może wymagać modyfikacji w kodzie aplikacji. Tekstura kompresowana blokowo musi być wielokrotną 4 we wszystkich wymiarach, ponieważ algorytmy kompresji blokowej działają na blokach 4x4 texel. Będzie to problem z mapą mip, której początkowe wymiary są podzielne przez 4, ale nie są to poziomy podzielone. Na poniższym diagramie przedstawiono różnicę w obszarze między rozmiarem wirtualnym (zadeklarowany) a rozmiarem fizycznym (rzeczywistym) każdego poziomu mipmap.

Po lewej stronie diagramu przedstawiono rozmiary poziomów mipmap, które są generowane dla nieskompresowanej tekstury 60×40. Rozmiar najwyższego poziomu jest pobierany z wywołania interfejsu API, które generuje teksturę; każdy kolejny poziom jest o połowę rozmiaru poprzedniego poziomu. W przypadku nieskompresowanej tekstury nie ma różnicy między rozmiarem wirtualnym (zadeklarowanym) a rozmiarem fizycznym (rzeczywistym).

Po prawej stronie diagramu przedstawiono rozmiary poziomów mipmap, które są generowane dla tej samej tekstury 60×40 z kompresją. Zwróć uwagę, że zarówno drugi, jak i trzeci poziom mają dopełnienie pamięci, aby rozmiary 4 na każdym poziomie. Jest to konieczne, aby algorytmy mogły działać na blokach 4×4 texel. Jest to oczywiste, jeśli rozważasz poziomy mipmap, które są mniejsze niż 4×4; rozmiar tych bardzo małych poziomów mipmap zostanie zaokrąglony do najbliższego współczynnika 4, gdy zostanie przydzielona pamięć tekstury.

Sprzęt próbkowania używa rozmiaru wirtualnego; gdy próbkowana jest tekstura, wypełnienie pamięci jest ignorowane. W przypadku poziomów mipmap, które są mniejsze niż 4×4, tylko pierwsze cztery texels będą używane dla mapy 2×2, a tylko pierwszy texel będzie używany przez blok 1×1. Nie ma jednak struktury interfejsu API, która uwidacznia rozmiar fizyczny (w tym wypełnienie pamięci).

Podsumowując, należy zachować ostrożność przy użyciu wyrównanych bloków pamięci podczas kopiowania regionów zawierających dane skompresowane blokowo. Aby to zrobić w aplikacji, która pobiera wskaźnik pamięci, upewnij się, że wskaźnik używa skoku powierzchni do uwzględnienia rozmiaru pamięci fizycznej.

Algorytmy kompresji

Blokuj techniki kompresji w trybie Direct3D dzielą nieskompresowane dane tekstury na bloki 4×4, kompresują każdy blok, a następnie przechowują dane. Z tego powodu tekstury, które mają być skompresowane, muszą mieć wymiary tekstury, które są wielokrotnościami 4.

Na powyższym diagramie przedstawiono teksturę podzieloną na bloki texel. Pierwszy blok przedstawia układ 16 texels oznaczonych etykietą a-p, ale każdy blok ma tę samą organizację danych.

Funkcja Direct3D implementuje kilka schematów kompresji, z których każda implementuje inny kompromis między liczbą przechowywanych składników, liczbą bitów na składnik i ilością zużytej pamięci. Ta tabela ułatwia wybór formatu, który najlepiej sprawdza się w przypadku typu danych i rozdzielczości danych najlepiej pasujących do aplikacji.

Dane źródłowe	Rozdzielczość kompresji danych (w bitach)	Wybierz ten format kompresji
Kolor trójskładnikowy i alfa	Kolor (5:6:5), Alfa (1) lub bez alfa	BC1
Kolor trójskładnikowy i alfa	Kolor (5:6:5), Alfa (4)	BC2
Kolor trójskładnikowy i alfa	Kolor (5:6:5), Alfa (8)	BC3
Kolor jednego składnika	Jeden składnik (8)	BC4
Kolor dwuskładnikowy	Dwa składniki (8:8)	BC5

 

BC1

Użyj pierwszego formatu kompresji bloku (BC1) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM lub DXGI_BC1_UNORM_SRGB) do przechowywania danych o kolorze trzech składników przy użyciu koloru 5:6:5 (5 bitów czerwony, 6 bitów zielony, 5 bitów niebieski). Jest to prawdą, nawet jeśli dane zawierają również 1-bitową alfa. Przy założeniu, że tekstura 4×4 używa największego możliwego formatu danych, format BC1 zmniejsza ilość pamięci wymaganej z 48 bajtów (16 kolorów × 3 składniki/kolor × 1 bajt/składnik) do 8 bajtów pamięci.

Algorytm działa na 4×4 blokach texels. Zamiast przechowywać 16 kolorów, algorytm zapisuje 2 kolory referencyjne (color_0 i color_1) oraz 16 2-bitowych indeksów kolorów (bloki a–p), jak pokazano na poniższym diagramie.

kompresji bc1

Indeksy kolorów (a–p) są używane do wyszukiwania oryginalnych kolorów z tabeli kolorów. Tabela kolorów zawiera 4 kolory. Pierwsze dwa kolory — color_0 i color_1 — są minimalnymi i maksymalnymi kolorami. Pozostałe dwa kolory, color_2 i color_3, są kolorami pośrednimi obliczanymi przy użyciu interpolacji liniowej.

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

Cztery kolory są przypisywane 2-bitowe wartości indeksu, które zostaną zapisane w blokach a–p.

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

Na koniec każdy z kolorów w blokach a–p jest porównywany z czterema kolorami w tabeli kolorów, a indeks najbliższego koloru jest przechowywany w blokach 2-bitowych.

Ten algorytm nadaje się do danych, które zawierają również 1-bitową alfa. Jedyną różnicą jest to, że color_3 jest ustawiona na 0 (która reprezentuje przezroczysty kolor), a color_2 jest liniową mieszanką color_0 i color_1.

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

różnice między direct3D 9 i Direct3D 10:

Ten format istnieje zarówno w trybie Direct3D 9, jak i 10.

• W Direct3D 9 format BC1 jest nazywany D3DFMT_DXT1.
• W Direct3D 10format BC1 jest reprezentowany przez DXGI_FORMAT_BC1_UNORM lub DXGI_FORMAT_BC1_UNORM_SRGB.

BC2

Użyj formatu BC2 (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM lub DXGI_BC2_UNORM_SRGB), aby przechowywać dane zawierające dane koloru i alfa z małą spójnością (użyj BC3 dla wysoce spójnych danych alfa). Format BC2 przechowuje dane RGB jako kolor 5:6:5 (5 bitów czerwony, 6 bitów zielony, 5 bitów niebieski) i alfa jako oddzielną wartość 4-bitową. Przy założeniu, że tekstura 4×4 przy użyciu największego możliwego formatu danych, ta technika kompresji zmniejsza ilość pamięci wymaganej z 64 bajtów (16 kolorów × 4 składniki/kolor × 1 bajt/składnik) do 16 bajtów pamięci.

Format BC2 przechowuje kolory o tej samej liczbie bitów i układu danych co format BC1; Jednak BC2 wymaga dodatkowych 64-bitowych pamięci do przechowywania danych alfa, jak pokazano na poniższym diagramie.

kompresji bc2

różnice między direct3D 9 i Direct3D 10:

Ten format istnieje zarówno w trybie Direct3D 9, jak i 10.

• W Direct3D 9format BC2 jest nazywany D3DFMT_DXT2 i D3DFMT_DXT3.

• W Direct3D 10format BC2 jest reprezentowany przez DXGI_FORMAT_BC2_UNORM lub DXGI_FORMAT_BC2_UNORM_SRGB

BC3

Użyj formatu BC3 (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM lub DXGI_BC3_UNORM_SRGB), aby przechowywać wysoce spójne dane kolorów (użyj BC2 z mniej spójnymi danymi alfa). Format BC3 przechowuje dane kolorów przy użyciu koloru 5:6:5 (5 bitów czerwony, 6 bitów zielony, 5 bitów niebieski) i danych alfa przy użyciu jednego bajtu. Przy założeniu, że tekstura 4×4 przy użyciu największego możliwego formatu danych, ta technika kompresji zmniejsza ilość pamięci wymaganej z 64 bajtów (16 kolorów × 4 składniki/kolor × 1 bajt/składnik) do 16 bajtów pamięci.

Format BC3 przechowuje kolory o tej samej liczbie bitów i układu danych co format BC1; jednak BC3 wymaga dodatkowych 64-bitowych pamięci do przechowywania danych alfa. Format BC3 obsługuje alfa, przechowując dwie wartości referencyjne i interpolując między nimi (podobnie jak w przypadku przechowywania koloru RGB przez BC1).

Algorytm działa na 4×4 blokach texels. Zamiast przechowywać 16 wartości alfa, algorytm przechowuje 2 odwołania alfa (alpha_0 i alpha_1) oraz 16 3-bitowych indeksów kolorów (alfa od p), jak pokazano na poniższym diagramie.

kompresji bc3

Format BC3 używa indeksów alfa (a–p), aby wyszukać oryginalne kolory z tabeli odnośników zawierającej 8 wartości. Dwie pierwsze wartości — alpha_0 i alpha_1 — są wartościami minimalnymi i maksymalnymi; pozostałe sześć wartości pośrednich jest obliczanych przy użyciu interpolacji liniowej.

Algorytm określa liczbę interpolowanych wartości alfa, sprawdzając dwie wartości alfa odwołania. Jeśli alpha_0 jest większa niż alpha_1, następnie BC3 interpoluje 6 wartości alfa; w przeciwnym razie interpoluje 4. Gdy bc3 interpoluje tylko 4 wartości alfa, ustawia dwie dodatkowe wartości alfa (0 dla w pełni przezroczyste i 255 dla w pełni nieprzezroczyste). BC3 kompresuje wartości alfa w obszarze 4×4 texel, przechowując kod bitowy odpowiadający wartościom interpolowanym alfa, które najlepiej pasują do oryginalnej alfa dla danego texelu.

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
}

różnice między direct3D 9 i Direct3D 10:

• W Direct3D 9 format BC3 jest nazywany D3DFMT_DXT4 i D3DFMT_DXT5.

• W Direct3D 10format BC3 jest reprezentowany przez DXGI_FORMAT_BC3_UNORM lub DXGI_FORMAT_BC3_UNORM_SRGB.

BC4

Użyj formatu BC4, aby przechowywać dane kolorów jednego składnika przy użyciu 8 bitów dla każdego koloru. W wyniku zwiększonej dokładności (w porównaniu z BC1), BC4 jest idealnym rozwiązaniem do przechowywania danych zmiennoprzecinkowych w zakresie od [0 do 1] przy użyciu formatu DXGI_FORMAT_BC4_UNORM i [-1 do +1] przy użyciu formatu DXGI_FORMAT_BC4_SNORM. Przy założeniu, że tekstura 4×4 przy użyciu największego możliwego formatu danych, ta technika kompresji zmniejsza ilość pamięci wymaganej z 16 bajtów (16 kolorów × 1 składnik/kolor × 1 bajt/składnik) do 8 bajtów.

Algorytm działa na 4×4 blokach texels. Zamiast przechowywać 16 kolorów, algorytm przechowuje 2 kolory referencyjne (red_0 i red_1) oraz 16 3-bitowych indeksów kolorów (czerwony przez czerwony p), jak pokazano na poniższym diagramie.

kompresji bc4

Algorytm używa indeksów 3-bitowych do wyszukiwania kolorów z tabeli kolorów zawierającej 8 kolorów. Pierwsze dwa kolory — red_0 i red_1 — są minimalnymi i maksymalnymi kolorami. Algorytm oblicza pozostałe kolory przy użyciu interpolacji liniowej.

Algorytm określa liczbę interpolowanych wartości kolorów, sprawdzając dwie wartości referencyjne. Jeśli red_0 jest większa niż red_1, następnie BC4 interpoluje 6 wartości kolorów; w przeciwnym razie interpoluje 4. Gdy bc4 interpoluje tylko 4 wartości kolorów, ustawia dwie dodatkowe wartości kolorów (0,0f dla w pełni przezroczyste i 1,0f dla w pełni nieprzezroczyste). BC4 kompresuje wartości alfa w obszarze 4×4 texel, przechowując kod bitowy odpowiadający interpolowanym wartościom alfa, które najlepiej pasują do oryginalnej alfa dla danego texelu.

BC4_UNORM

Interpolacja danych jednoskładnikowych jest wykonywana tak jak w poniższym przykładzie kodu.

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
}

Kolory odwołania są przypisywane 3-bitowe indeksy (000–111, ponieważ istnieją 8 wartości), które zostaną zapisane w blokach na czerwono przez czerwony p podczas kompresji.

BC4_SNORM

DXGI_FORMAT_BC4_SNORM jest dokładnie taka sama, z tą różnicą, że dane są kodowane w zakresie SNORM i gdy są interpolowane 4 wartości kolorów. Interpolacja danych jednoskładnikowych jest wykonywana tak jak w poniższym przykładzie kodu.

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
}

Kolory odwołania są przypisywane 3-bitowe indeksy (000–111, ponieważ istnieją 8 wartości), które zostaną zapisane w blokach na czerwono przez czerwony p podczas kompresji.

BC5

Użyj formatu BC5, aby przechowywać dane kolorów dwuskładnikowych przy użyciu 8 bitów dla każdego koloru. W wyniku zwiększonej dokładności (w porównaniu z BC1), BC5 jest idealnym rozwiązaniem do przechowywania danych zmiennoprzecinkowych w zakresie od [0 do 1] przy użyciu formatu DXGI_FORMAT_BC5_UNORM i [-1 do +1] przy użyciu formatu DXGI_FORMAT_BC5_SNORM. Przy założeniu, że tekstura 4×4 używa największego możliwego formatu danych, ta technika kompresji zmniejsza ilość pamięci wymaganej z 32 bajtów (16 kolorów × 2 składniki/kolor × 1 bajt/składnik) do 16 bajtów.

Algorytm działa na 4×4 blokach texels. Zamiast przechowywać 16 kolorów dla obu składników, algorytm przechowuje 2 kolory referencyjne dla każdego składnika (red_0, red_1, green_0 i green_1) oraz 16 3-bitowych indeksów kolorów dla każdego składnika (czerwony od czerwonego p i zielonego do zielonego p), jak pokazano na poniższym diagramie.

kompresji bc5

Algorytm używa indeksów 3-bitowych do wyszukiwania kolorów z tabeli kolorów zawierającej 8 kolorów. Dwa pierwsze kolory — red_0 i red_1 (lub green_0 i green_1) — są minimalnymi i maksymalnymi kolorami. Algorytm oblicza pozostałe kolory przy użyciu interpolacji liniowej.

Algorytm określa liczbę interpolowanych wartości kolorów, sprawdzając dwie wartości referencyjne. Jeśli red_0 jest większa niż red_1, funkcja BC5 interpoluje 6 wartości kolorów; w przeciwnym razie interpoluje 4. Gdy bc5 interpoluje tylko 4 wartości kolorów, ustawia pozostałe dwie wartości kolorów na 0,0f i 1.0f.

• BC5_UNORM
• BC5_SNORM

BC5_UNORM

Interpolacja danych jednoskładnikowych jest wykonywana tak jak w poniższym przykładzie kodu. Obliczenia dla zielonych składników są podobne.

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
}

Kolory odwołania są przypisywane 3-bitowe indeksy (000–111, ponieważ istnieją 8 wartości), które zostaną zapisane w blokach na czerwono przez czerwony p podczas kompresji.

BC5_SNORM

DXGI_FORMAT_BC5_SNORM jest dokładnie taka sama, z tą różnicą, że dane są kodowane w zakresie SNORM i gdy są interpolowane 4 wartości danych, dwie dodatkowe wartości to -1.0f i 1.0f. Interpolacja danych jednoskładnikowych jest wykonywana tak jak w poniższym przykładzie kodu. Obliczenia dla zielonych składników są podobne.

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
}

Kolory odwołania są przypisywane 3-bitowe indeksy (000–111, ponieważ istnieją 8 wartości), które zostaną zapisane w blokach na czerwono przez czerwony p podczas kompresji.

Konwersja formatu przy użyciu programu Direct3D 10.1

Funkcja Direct3D 10.1 umożliwia kopiowanie między teksturami wstępnie typizowanych i teksturami skompresowanych blokowo o tej samej szerokości bitów. Funkcje, które mogą to osiągnąć, to CopyResource i CopySubresourceRegion.

Począwszy od wersji Direct3D 10.1, można użyć CopyResource i CopySubresourceRegion do kopiowania między kilkoma typami formatów. Ten typ operacji kopiowania wykonuje typ konwersji formatu, która ponownie interpretuje dane zasobów jako inny typ formatu. Rozważmy ten przykład pokazujący różnicę między ponownym interpretowaniem danych w sposób, w jaki zachowuje się bardziej typowy typ konwersji:

    FLOAT32 f = 1.0f;
    UINT32 u;

Aby ponownie interpretować 'f' jako typ 'u', użyj memcpy:

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

W poprzedniej reinterpretacji podstawowa wartość danych nie zmienia się; memcpy ponownie interpretuje zmiennoprzecinkowy jako niepodpisaną liczbę całkowitą.

Aby wykonać bardziej typowy typ konwersji, użyj przypisania:

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

W poprzedniej konwersji zmienia się podstawowa wartość danych.

W poniższej tabeli wymieniono dozwolone formaty źródłowe i docelowe, których można użyć w tym typie ponownej interpretacji konwersji formatu. Należy poprawnie zakodować wartości, aby ponowne interpretowanie działało zgodnie z oczekiwaniami.

Szerokość bitu	Nieskompresowany zasób	zasób Block-Compressed
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

 

Tematy pokrewne

zasoby (Direct3D 10)