gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS development > Format of compressed textures?

#75910 - EyeballKid - Thu Mar 16, 2006 11:17 pm

Does anyone have any info on the format for compressed textures on the DS?
I've been scouring the web for clues, but no joy so far :-(

Thanks!

#75925 - tepples - Fri Mar 17, 2006 1:11 am

What you think of as texture compression might just be 16-color indexed textures.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#75979 - sasq - Fri Mar 17, 2006 9:36 am

No, its basically a texture divided into 4x4 blocks with 2 bits per pixel and one 4 color palette per block. Not completey clear on how you should place it in VRAM though.

#75982 - EyeballKid - Fri Mar 17, 2006 10:36 am

sasq wrote:
No, its basically a texture divided into 4x4 blocks with 2 bits per pixel and one 4 color palette per block. Not completey clear on how you should place it in VRAM though.


Ahh... cool! maybe it's S3TC format?
http://www.hardwarecentral.com/hardwarecentral/reports/140/4/

As you described, except only two colours in the palette are stored, with the other two being derived by interpolation...

#75998 - sasq - Fri Mar 17, 2006 3:05 pm

yes it seems to be S3TC more or less... for each block you can decide if you want to specify only 2 colors and interpolate the other two, or specify 4 individual colors...

#76038 - tepples - Fri Mar 17, 2006 10:07 pm

The GameCube is known to use S3TC. Given parallels between GameCube and DS 3D in other ways, I'd expect the DS to also support S3TC.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#77063 - masscat - Mon Mar 27, 2006 10:06 pm

I have been playing around trying to figure out how to use compressed textures.
The texel data and palette are seperate. As said above, each texel is 2 bits which forms the index into the palette.
The following shows how a byte array of texture data would appear on screen (assuming a one to one mapping between texel and pixel) when it is copied into VRAM using the glTexImage2D function. Each byte is shown split into the 2bit fields.
Code:
unsigned char texture_data[] = { (a,b,c,d), (e,f,g,h), (i,j,k,l), (m,n,o,p), (q,r,s,t), (u,v,w,x), .......}

Appearance on screen:

d, c, b, a, t, s, r, q, ...........
h, g, f, e, x, w, v, u, ...........
l, k, j, i, ...........
p, o, n, m, ...........


The palette is not working for me. The first four entries are being used as the palette for all 4x4 texel groups. Any texel with the value 11 is actually transparent.
Anybody know how to handle the palette?

#77119 - EyeballKid - Tue Mar 28, 2006 12:12 pm

How are you treating the palette currently?

From what I can tell, the other paletted texture formats reference a palette residing in another VRAM bank. I wonder if the compressed texture format also uses a separate palette or an "inline" palette (like S3TC, where 2 RGB values follow each 4x4 block of pixels)...

#77122 - masscat - Tue Mar 28, 2006 1:04 pm

I have set up the palette as 4 16bit values per 4x4 texel block just as an array. I copy these into VRAM using the glTexLoadPal. Since I only have one texture and one palette I am assuming the palette gets copied into VRAM bank E.

If I do not copy the palette, I get colours for indices 00, 01 and 10 as black and 11 as transparent. I imagine this is because the VRAM bank has been zeroed at some point.

From my experiments, I believe the palette is seperate in a similar way to normal palette textures.

The code is based on one of the examples from libnds. You can download it from here.