Compressie blokkeren

Blokcompressie is een lossy texture-compression techniek voor het verminderen van de textuurgrootte en geheugenvoetafdruk, waardoor de prestaties toenemen. Een blok-gecomprimeerde textuur kan kleiner zijn dan een textuur met 32 bits per kleur.

Blokcompressie is een textuurcompressietechniek voor het verminderen van de textuurgrootte. In vergelijking met een textuur met 32 bits per kleur kan een blokcompressiepatroon tot 75 procent kleiner zijn. Toepassingen zien meestal een prestatieverhoging bij het gebruik van blokcompressie vanwege de kleinere geheugenvoetafdruk.

Hoewel verlieslatend, werkt blokcompressie goed en wordt het aanbevolen voor alle texturen die door de pipeline worden getransformeerd en gefilterd. Texturen die rechtstreeks op het scherm worden weergegeven (UI-elementen zoals pictogrammen en tekst) zijn geen goede keuzes voor compressie, omdat artefacten duidelijker zichtbaar zijn.

Een blok-gecomprimeerd patroon moet worden gemaakt als een veelvoud van grootte 4 in alle dimensies en kan niet worden gebruikt als uitvoer van de pijplijn.

Hoe blokcompressie werkt

Blokcompressie is een techniek voor het verminderen van de hoeveelheid geheugen die nodig is om kleurgegevens op te slaan. Door bepaalde kleuren op te slaan in de oorspronkelijke grootte en andere kleuren met behulp van een coderingsschema, kunt u de hoeveelheid geheugen die nodig is voor het opslaan van de afbeelding aanzienlijk verminderen. Omdat de hardware gecomprimeerde gegevens automatisch ontsleutelt, is er geen prestatiestraf voor het gebruik van gecomprimeerde patronen.

Bekijk de volgende twee voorbeelden om te zien hoe compressie werkt. In het eerste voorbeeld wordt de hoeveelheid geheugen beschreven die wordt gebruikt bij het opslaan van niet-gecomprimeerde gegevens; in het tweede voorbeeld wordt de hoeveelheid geheugen beschreven die wordt gebruikt bij het opslaan van gecomprimeerde gegevens.

• niet-gecomprimeerde gegevens opslaan
• gecomprimeerde gegevens opslaan

niet-gecomprimeerde gegevens opslaan

De volgende afbeelding vertegenwoordigt een niet-gecomprimeerd 4×4 patroon. Stel dat elke kleur één kleurcomponent (bijvoorbeeld rood) bevat en wordt opgeslagen in één byte van het geheugen.

De niet-gecomprimeerde gegevens worden opeenvolgend in het geheugen ingedeeld en vereisen 16 bytes, zoals wordt weergegeven in de volgende afbeelding.

gecomprimeerde gegevens opslaan

Nu u hebt gezien hoeveel geheugen een niet-gecomprimeerde afbeelding gebruikt, bekijkt u hoeveel geheugen een gecomprimeerde afbeelding opslaat. De BC4 compressie-indeling slaat 2 kleuren (1 byte elk) en 16 3-bits indexen (48 bits of 6 bytes) op die worden gebruikt om de oorspronkelijke kleuren in het patroon te interpoleren, zoals wordt weergegeven in de volgende afbeelding.

De totale ruimte die nodig is om de gecomprimeerde gegevens op te slaan, is 8 bytes. Dit is een geheugenbesparing van 50 procent ten opzichte van het niet-gecomprimeerde voorbeeld. De besparingen zijn zelfs groter wanneer meer dan één kleurcomponent wordt gebruikt.

De aanzienlijke geheugenbesparingen die worden geboden door blokcompressie kunnen leiden tot een toename van de prestaties. Deze prestaties komen ten koste van de beeldkwaliteit (vanwege kleurinterpolatie); de lagere kwaliteit is echter vaak niet merkbaar.

In de volgende sectie ziet u hoe Direct3D het gebruik van blokcompressie in een toepassing inschakelt.

Blokcompressie gebruiken

Maak een blok-gecomprimeerde textuur, net zoals een niet-gecomprimeerde textuur, behalve dat u een blok-gecomprimeerde indeling opgeeft.

Maak vervolgens een weergave om de texture aan de pijplijn te binden. Aangezien een blokgecomprimeerde texture alleen kan worden gebruikt als invoer voor een shader-stage, wilt u een shader-resourceweergave maken.

Gebruik een gecomprimeerd blokpatroon op dezelfde manier als u een niet-gecomprimeerd patroon zou gebruiken. Als uw toepassing een geheugenpointer krijgt om gecomprimeerde gegevens te blokkeren, moet u rekening houden met de geheugenopvulling in een mipmap die ervoor zorgt dat de gedeclareerde grootte verschilt van de werkelijke grootte.

• virtuele grootte versus fysieke grootte

virtuele grootte versus fysieke grootte

Als u toepassingscode hebt die gebruikmaakt van een geheugenpointer om het geheugen van een gecomprimeerd blokpatroon te doorlopen, is er een belangrijke overweging die mogelijk een wijziging in uw toepassingscode vereist. Een blok-gecomprimeerde textuur moet een veelvoud zijn van 4 in alle dimensies omdat de blokcompressiealgoritmen op 4x4 texelse blokken werken. Dit is een probleem voor een mipmap waarvan de initiële dimensies deelbaar zijn met 4, maar onderverdeelde niveaus niet. In het volgende diagram ziet u het verschil in gebied tussen de grootte van de virtuele (gedeclareerde) en de fysieke (werkelijke) grootte van elk mipmapniveau.

Aan de linkerkant van het diagram ziet u de grootten op mipmapniveau die worden gegenereerd voor een niet-gecomprimeerd 60×40-patroon. De grootte op het hoogste niveau wordt genomen uit de API-aanroep waarmee het patroon wordt gegenereerd; elk volgend niveau is de helft van de grootte van het vorige niveau. Voor een niet-gecomprimeerde textuur is er geen verschil tussen de virtuele (gedeclareerde) grootte en de fysieke (werkelijke) grootte.

Aan de rechterkant van het diagram ziet u de grootten op mipmap-niveau die worden gegenereerd voor hetzelfde patroon van 60×40 met compressie. U ziet dat zowel de tweede als de derde niveaus geheugenopvulling hebben om de groottefactoren van 4 op elk niveau te maken. Dit is noodzakelijk zodat de algoritmen op 4×4 texelsblokken kunnen werken. Dit is vooral duidelijk als u mipmapniveaus beschouwt die kleiner zijn dan 4×4; de grootte van deze zeer kleine mipmapniveaus wordt naar boven afgerond op de dichtstbijzijnde factor van 4 wanneer bitmapgeheugen wordt toegewezen.

Samplinghardware maakt gebruik van de virtuele grootte; wanneer het patroon wordt gemonsterd, wordt de geheugenopvulling genegeerd. Voor mipmapniveaus die kleiner zijn dan 4×4, worden alleen de eerste vier texels gebruikt voor een kaart van 2×2, en wordt alleen de eerste texel gebruikt in een 1×1 blok. Er is echter geen API-structuur die de fysieke grootte beschikbaar maakt (inclusief de geheugenopvulling).

Kortom, wees voorzichtig met het gebruik van uitgelijnde geheugenblokken bij het kopiëren van regio's die gecomprimeerde gegevens bevatten. Als u dit wilt doen in een toepassing die een geheugenaanwijzer ontvangt, zorg er dan voor dat de aanwijzer de oppervlaktepitch gebruikt om rekening te houden met de fysieke geheugengrootte.

Algoritmen voor compressie

Compressietechnieken in Direct3D splitsen ongecomprimeerde patroongegevens op in 4×4 blokken, comprimeert elk blok en slaat de gegevens vervolgens op. Om deze reden moeten texturen die naar verwachting worden gecomprimeerd, textuurdimenaties hebben die veelvouden van 4 zijn.

In het voorgaande diagram ziet u een patroon dat is gepartitioneerd in Texelse blokken. Het eerste blok toont de indeling van de 16 texels met het label a-p, maar elk blok heeft dezelfde organisatie van gegevens.

Direct3D implementeert verschillende compressieschema's, elk implementeert een andere afweging tussen het aantal opgeslagen onderdelen, het aantal bits per onderdeel en de hoeveelheid verbruikt geheugen. Gebruik deze tabel om de indeling te kiezen die het beste werkt met het type gegevens en de gegevensomzetting die het beste bij uw toepassing past.

• BC1
• BC2
• BC3
• BC4
• BC5

BC1

Gebruik de eerste blokcompressie-indeling (BC1) (DXGI_FORMAT_BC1_TYPELESS, DXGI_FORMAT_BC1_UNORM of DXGI_BC1_UNORM_SRGB) om kleurgegevens van drie onderdelen op te slaan met een kleur van 5:6:5 (5 bits rood, 6 bits groen, 5 bits blauw). Dit geldt ook als de gegevens ook 1-bits alfa bevatten. Uitgaande van een 4×4-patroon met de grootste gegevensindeling, vermindert de BC1-indeling het geheugen dat nodig is van 48 bytes (16 kleuren × 3 onderdelen/kleur × 1 byte/component) tot 8 bytes geheugen.

Het algoritme werkt op blokken van 4×4 texels. In plaats van 16 kleuren op te slaan, worden in het algoritme 2 referentiekleuren (color_0 en color_1) en 16 2-bits kleurenindexen (blokken a–p) opgeslagen, zoals wordt weergegeven in het volgende diagram.

De kleurindexen (a–p) worden gebruikt om de oorspronkelijke kleuren van een kleurentabel op te zoeken. De kleurentabel bevat vier kleuren. De eerste twee kleuren( color_0 en color_1) zijn de minimum- en maximumkleuren. De andere twee kleuren, color_2 en color_3, zijn tussenliggende kleuren die worden berekend met lineaire interpolatie.

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

De vier kleuren worden 2-bits indexwaarden toegewezen die worden opgeslagen in blokken a–p.

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

Ten slotte worden alle kleuren in blokken a–p vergeleken met de vier kleuren in de kleurentabel en wordt de index voor de dichtstbijzijnde kleur opgeslagen in de 2-bits blokken.

Dit algoritme leent zich ook voor gegevens die 1-bits alfa bevatten. Het enige verschil is dat color_3 is ingesteld op 0 (die een transparante kleur vertegenwoordigt) en color_2 een lineaire combinatie van color_0 en color_1 is.

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

BC2

Gebruik de BC2-indeling (DXGI_FORMAT_BC2_TYPELESS, DXGI_FORMAT_BC2_UNORM of DXGI_BC2_UNORM_SRGB) om gegevens op te slaan die kleur- en alfagegevens bevatten met een lage samenhang (gebruik BC3- voor zeer coherente alfagegevens). De BC2-indeling slaat RGB-gegevens op als een 5:6:5-kleur (5 bits rood, 6 bits groen, 5 bits blauw) en alfa als een afzonderlijke 4-bits waarde. Uitgaande van een 4×4-patroon met de grootste gegevensindeling, vermindert deze compressietechniek het geheugen dat nodig is van 64 bytes (16 kleuren × 4 onderdelen/kleur × 1 byte/component) tot 16 bytes geheugen.

De BC2-indeling slaat kleuren op met hetzelfde aantal bits en gegevensindeling als de BC1-indeling; BC2 vereist echter een extra 64 bits geheugen voor het opslaan van de alfagegevens, zoals wordt weergegeven in het volgende diagram.

BC3

Gebruik de BC3-indeling (DXGI_FORMAT_BC3_TYPELESS, DXGI_FORMAT_BC3_UNORM of DXGI_BC3_UNORM_SRGB) om zeer coherente kleurgegevens op te slaan (gebruik BC2 met minder coherente alfagegevens). In de BC3-indeling worden kleurgegevens opgeslagen met 5:6:5 kleur (5 bits rood, 6 bits groen, 5 bits blauw) en alfagegevens met één byte. Uitgaande van een 4×4-patroon met de grootste gegevensindeling, vermindert deze compressietechniek het geheugen dat nodig is van 64 bytes (16 kleuren × 4 onderdelen/kleur × 1 byte/component) tot 16 bytes geheugen.

De BC3-indeling slaat kleuren op met hetzelfde aantal bits en gegevensindeling als de BC1-indeling; BC3 vereist echter een extra geheugen van 64 bits om de alfagegevens op te slaan. De BC3-indeling verwerkt alfa door twee verwijzingswaarden op te slaan en ertussen te interpoleren (vergelijkbaar met de manier waarop BC1 RGB-kleur opslaat).

Het algoritme werkt op blokken van 4×4 texels. In plaats van 16 alfawaarden op te slaan, slaat het algoritme 2 verwijzings alfa's (alpha_0 en alpha_1) en 16 3-bits kleurindexen (alfa a tot en met p) op, zoals wordt weergegeven in het volgende diagram.

De BC3-indeling gebruikt de alfa-indexen (a–p) om de oorspronkelijke kleuren op te zoeken uit een opzoektabel die 8 waarden bevat. De eerste twee waarden, alpha_0 en alpha_1, zijn de minimum- en maximumwaarden; de andere zes tussenliggende waarden worden berekend met behulp van lineaire interpolatie.

Het algoritme bepaalt het aantal geïnterpoleerde alfawaarden door de twee referentie alfawaarden te onderzoeken. Als alpha_0 groter is dan alpha_1, interpoleert BC3 6 alfawaarden; anders interpoleert het 4. Wanneer BC3 slechts 4 alfawaarden interpoleert, worden er twee extra alfawaarden ingesteld (0 voor volledig transparant en 255 voor volledig ondoorzichtig). BC3 comprimeert de alfawaarden in het 4×4 texelsgebied door de bitcode op te slaan die overeenkomt met de geïnterpoleerde alfawaarden die het meest overeenkomen met de oorspronkelijke alfa voor een gegeven texel.

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

Gebruik de BC4-indeling om kleurgegevens met één component op te slaan met 8 bits voor elke kleur. Als gevolg van de toegenomen nauwkeurigheid (vergeleken met BC1), is BC4 ideaal voor het opslaan van drijvende-kommagegevens in het bereik van [0 tot 1] met behulp van de DXGI_FORMAT_BC4_UNORM-indeling en [-1 tot +1] met behulp van de DXGI_FORMAT_BC4_SNORM-indeling. Uitgaande van een 4×4-textuur met behulp van het grootste gegevensformaat, reduceert deze compressietechniek het geheugen dat nodig is van 16 bytes (16 kleuren × 1 component/kleur × 1 byte/component) tot 8 bytes.

Het algoritme werkt op blokken van 4×4 texels. In plaats van 16 kleuren op te slaan, worden in het algoritme 2 referentiekleuren (red_0 en red_1) en 16 3-bits kleurenindexen (rood a tot en met rode p) opgeslagen, zoals wordt weergegeven in het volgende diagram.

Het algoritme gebruikt de 3-bits indexen om kleuren op te zoeken uit een kleurentabel die 8 kleuren bevat. De eerste twee kleuren, red_0 en red_1, zijn de minimum- en maximumkleuren. Het algoritme berekent de resterende kleuren met behulp van lineaire interpolatie.

Het algoritme bepaalt het aantal geïnterpoleerde kleurwaarden door de twee referentiewaarden te onderzoeken. Als red_0 groter is dan red_1, interpoleert BC4 6 kleurwaarden; anders interpoleert het 4. Wanneer BC4 slechts 4 kleurwaarden interpoleert, worden er twee extra kleurwaarden ingesteld (0,0f voor volledig transparant en 1,0f voor volledig ondoorzichtig). BC4 comprimeert de alfawaarden in het 4×4 texelsgebied door de bitcode op te slaan die overeenkomt met de geïnterpoleerde alfawaarden die het meest overeenkomen met de oorspronkelijke alfa voor een gegeven texel.

• BC4_UNORM
• BC4_SNORM

BC4_UNORM

De interpolatie van de gegevens met één component wordt uitgevoerd zoals in het volgende codevoorbeeld.

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
}

Aan de referentiekleuren worden 3-bits indexen toegewezen (000-111 omdat er 8 waarden zijn), die worden opgeslagen in blokken rood a tot en met rode p tijdens compressie.

BC4_SNORM

De DXGI_FORMAT_BC4_SNORM is precies hetzelfde, behalve dat de gegevens zijn gecodeerd in het SNORM-bereik en wanneer 4 kleurwaarden worden geïnterpoleerd. De interpolatie van de gegevens met één component wordt uitgevoerd zoals in het volgende codevoorbeeld.

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
}

Aan de referentiekleuren worden 3-bits indexen toegewezen (000-111 omdat er 8 waarden zijn), die worden opgeslagen in blokken rood a tot en met rode p tijdens compressie.

BC5

Gebruik de BC5-indeling om kleurgegevens van twee onderdelen op te slaan met 8 bits voor elke kleur. Als gevolg van de verhoogde nauwkeurigheid (vergeleken met BC1), is BC5 ideaal voor het opslaan van drijvende-kommagegevens in het bereik van [0 tot 1] met behulp van de DXGI_FORMAT_BC5_UNORM-indeling en [-1 tot +1] met behulp van de DXGI_FORMAT_BC5_SNORM-indeling. Ervan uitgaande dat een 4×4-patroon met de grootste gegevensindeling mogelijk is, vermindert deze compressietechniek het geheugen dat nodig is van 32 bytes (16 kleuren × 2 onderdelen/kleur × 1 byte/component) tot 16 bytes.

• BC5_UNORM
• BC5_SNORM

Het algoritme werkt op blokken van 4×4 texels. In plaats van 16 kleuren voor beide onderdelen op te slaan, slaat het algoritme 2 referentiekleuren op voor elk onderdeel (red_0, red_1, green_0 en green_1) en 16 3-bits kleurindexen voor elk onderdeel (rood a tot en met rood p en groen a tot en met groene p), zoals wordt weergegeven in het volgende diagram.

Het algoritme gebruikt de 3-bits indexen om kleuren op te zoeken uit een kleurentabel die 8 kleuren bevat. De eerste twee kleuren ( red_0 en red_1 (of green_0 en green_1)) zijn de minimum- en maximumkleuren. Het algoritme berekent de resterende kleuren met behulp van lineaire interpolatie.

Het algoritme bepaalt het aantal geïnterpoleerde kleurwaarden door de twee referentiewaarden te onderzoeken. Als red_0 groter is dan red_1, interpoleert BC5 6 kleurwaarden; anders interpoleert het 4. Wanneer BC5 slechts 4 kleurwaarden interpoleert, worden de resterende twee kleurwaarden ingesteld op 0,0f en 1,0f.

BC5_UNORM

De interpolatie van de gegevens met één component wordt uitgevoerd zoals in het volgende codevoorbeeld. De berekeningen voor de groene componenten zijn vergelijkbaar.

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
}

Aan de referentiekleuren worden 3-bits indexen toegewezen (000-111 omdat er 8 waarden zijn), die worden opgeslagen in blokken rood a tot en met rode p tijdens compressie.

BC5_SNORM

De DXGI_FORMAT_BC5_SNORM is precies hetzelfde, behalve dat de gegevens zijn gecodeerd in het SNORM-bereik en wanneer 4 gegevenswaarden zijn geïnterpoleerd, zijn de twee extra waarden -1,0f en 1,0f. De interpolatie van de gegevens met één component wordt uitgevoerd zoals in het volgende codevoorbeeld. De berekeningen voor de groene componenten zijn vergelijkbaar.

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
}

Aan de referentiekleuren worden 3-bits indexen toegewezen (000-111 omdat er 8 waarden zijn), die worden opgeslagen in blokken rood a tot en met rode p tijdens compressie.

formaatconversie

Direct3D maakt kopieën mogelijk tussen vooraf gestructureerde patronen en blok-gecomprimeerde patronen van dezelfde bitbreedte.

U kunt bronnen kopiëren tussen enkele indelingstypen. Met dit type kopieerbewerking wordt een type indelingsconversie uitgevoerd waarmee resourcegegevens opnieuw worden geïnterpreteerd als een ander indelingstype. Bekijk dit voorbeeld waarin het verschil wordt weergegeven tussen het opnieuw interpreteren van gegevens met de manier waarop een meer typisch type conversie zich gedraagt:

FLOAT32 f = 1.0f;
UINT32 u;

Als u 'f' opnieuw wilt interpreteren als het type 'u', gebruikt u memcpy:

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

In de voorgaande herinterpretatie verandert de onderliggende waarde van de gegevens niet; memcpy herinterpreteert de float als een geheel getal zonder teken.

Als u het meest typische type conversie wilt uitvoeren, gebruikt u de toewijzing:

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

In de voorgaande conversie wordt de onderliggende waarde van de gegevens gewijzigd.

De volgende tabel bevat de toegestane bron- en doelindelingen die u kunt gebruiken bij dit type formatconversie door herinterpretatie. U moet de waarden correct coderen om de herinterpretatie naar behoren te laten werken.

verwante onderwerpen

Gecomprimeerde textuurbronnen