DXT textures?

[Paco]

Hi! I read that PSP supports "compressed textures", and from older posts I gather that they are DXT textures. However, there seems to be little info about this topic, no mention at all in the Gu library and etc.

Assuming that DXT formats are an extension of the current 5650, 4444, 8888 etc, I converted a 64x64 image to DDS (DXT1) and tried setting an "8" for the texture pixel format to see what happens:

Code: Select all

    sceGuTexMode(8, 0, 0, 0);
    sceGuTexImage (0, 64, 64, 64, g_aDDSTest+128); // DDS header is 128 bytes

Right, I get a texture that seems to be interpreted similarly to a DXT1 texture, with 4x4 pixel blocks of similar colors and etc, and some binary alpha values - a lot like DXT1. However, the visible image is nothing like the texture I converted to DXT1. I could imagine the color components being switched (DXT formats use RGB whereas the PSP uses BGR), but that's not it.

I can keep experimenting with this, but if there is actual info out there, I'd love some pointers.

Note: based on the alpha patterns, it feels that format "9" seems to behave similarly to DXT3 (arbitrary 4-bit alpha per pixel), and "10" is akin to DXT5 (interpolated alpha in each block). "11" crashes the PSP, so that's that as far as pixel formats go. But the actual data is garbled in all of them, nothing like my original image.

Edit2: Continuing with pixel format 8, it seems the colors and pixel data for each block have switched places compared to Direct3D's DXT1, but it is definitely a DXT1-type format. I'll keep posting what I find.

[Paco]

Well, I confirmed format 8 is definitely DXT1. The only thing needed to make it show up properly on the PSP is to swap the color info and pixel info on each block. Each of those is a 32-bit value, so if you load a DDS texture straight to memory, just do something like this:

Code: Select all

void PostProcessDXT1(unsigned char *pData, unsigned int size)
{
  // DDS header is 128 bytes
  size = (size-128)/sizeof(unsigned int);
  pData += 128;
  for (unsigned int *p = (unsigned int *)pData; size > 0; size -= 2, p += 2)
    Swap(p[0], p[1]);
}

And your DXT1 DDS texture is ready to use. The transparent pixels in DXT1 are assigned a color value of 0 (black), so be careful if you're using bilinear filtering and alpha testing, you might get some black borders around your texture's holes. Also remember if you plan on using the mipmaps from the DDS, PSP needs textures aligned to 16 bytes, but the DDS format only requires 8 bytes alignment for mipmaps below 4x4 size.

Formats 9 and 10 still feel like DXT3 and 5, but data needs more shuffling around. Working on it...

Additionally, while you can set the swizzle flag for the texture and the hardware tries to do something with the arrangement of blocks, I think it fails miserably and in fact you can't swizzle DXT textures.

[Loothor]

Texture formats 9 and 10 are indeed DXT3 and DXT5. There is another thread that has a pretty good discussion of this titled "DXTn texture format" (http://forums.ps2dev.org/viewtopic.php? ... highlight=)

We have successfully converted and used many DXT textures with the following code. Our DXTs were created using the nVidia plugin for Photoshop and/or the nvdxt.exe tool. It seems some people have experienced slightly different results, perhaps using different DXT generators.

Code: Select all

void PSPconvert_dxt1(unsigned char *data, unsigned int size)
{
	unsigned short *src = (unsigned short *) data;

	for(int j = 0; size >= 8; size -= 8, j++)
	{
		unsigned short converted[4];

		converted[0] = src[2];
		converted[1] = src[3];
		converted[2] = src[0];
		converted[3] = src[1];

		for &#40;int i = 0; i < 4; i++&#41; src&#91;i&#93; = converted&#91;i&#93;;

		src += 4;
	&#125;
&#125;

void PSPconvert_dxt35&#40;unsigned char *data, unsigned int size&#41;
&#123;
	unsigned short *src = &#40;unsigned short *&#41; data;

	for&#40;int j = 0; size >= 16; size -= 16, j++&#41;
	&#123;
		unsigned short converted&#91;8&#93;;

		converted&#91;4&#93; = src&#91;1&#93;;
		converted&#91;5&#93; = src&#91;2&#93;;
		converted&#91;6&#93; = src&#91;3&#93;;
		converted&#91;7&#93; = src&#91;0&#93;;

		converted&#91;0&#93; = src&#91;6&#93;;
		converted&#91;1&#93; = src&#91;7&#93;;
		converted&#91;2&#93; = src&#91;4&#93;;
		converted&#91;3&#93; = src&#91;5&#93;;

		for &#40;int i = 0; i < 8; i++&#41; src&#91;i&#93; = converted&#91;i&#93;;

		src += 8;
	&#125;
&#125;

Hope this helps.

[Paco]

Texture formats 9 and 10 are indeed DXT3 and DXT5. There is another thread that has a pretty good discussion of this titled "DXTn texture format" (http://forums.ps2dev.org/viewtopic.php? ... highlight=)

Bah I hate forum search, it didn't find that thread. :) Thanks!

Hm in my sample textures, converting DXT3 alpha is definitely different from converting DXT5 alpha, and different from your conversion (you just copy the alpha bytes without changing order like you do for DXT5). I built these DDSs with the DirectX texture tool, but that shouldn't make a difference.

Why aren't those constants in the Gu header? CHPPPPPPPPPPPPPPPPP! :)

[Grom]

This is good news that I can use compressed textures in PSP.
Is it possible to use them from PSPGL?

If you have any working sample with compressed textures - please give it to me.

[chp]

Why aren't those constants in the Gu header? CHPPPPPPPPPPPPPPPPP! :)

They are now. :) I just forgot to add them at the time, was a bit busy with other stuff.

[Paco]

This is interesting... one of the reasons I had trouble with the DXT5 conversion seems to be a GCC compiler bug. Unfortunately it stopped happening on its own.

Anyway, I don't think the DXT5 conversion is correct also for DXT3:

Code: Select all

  // copy alpha
  converted[4] = src[1];
  converted[5] = src[2];
  converted[6] = src[3];
  converted[7] = src[0];

DXT3 contains an explicit (not interpolated) alpha block, it wouldn't make sense to arbitrarily switch the first row, and indeed it shows the wrong texture if you do.

So I recommend separating the dxt3 and dxt5 functions, and using

Code: Select all

      converted[4] = src[0];
      converted[5] = src[1];
      converted[6] = src[2];
      converted[7] = src[3]; 

for DXT3.

Thanks for adding the constants, chp. :)

[Grom]

Does anybody use compressed textures with PSPgl?

Am i right that one can use original DXT* compressed textures and PSPgl will make all the things needed for hardware?

[jsgf]

Does anybody use compressed textures with PSPgl?

Am i right that one can use original DXT* compressed textures and PSPgl will make all the things needed for hardware?

Yes, you can load them in standard format with glCompressedTexImage2D, and PSPGL will do the conversion.

I never tested DXT5 properly, so it is quite likely wrong. Hm, and DXT3 seems to have a 1 block offset.

[jsgf]

So I recommend separating the dxt3 and dxt5 functions, and using

Code: Select all

      converted[4] = src[0];
      converted[5] = src[1];
      converted[6] = src[2];
      converted[7] = src[3]; 

That's what I have in PSPGL. The 1,2,3,0 order doesn't make much sense to me. I think the PSPGL code is still wrong, but that doesn't look like the fix.

[Grom]

jsgf,

As wrote before, I'm using 128x128 texture

I tried to use it in DXT1 format. And I found 2 problems:
* It looks shifted exactly on 0.5 by t coordinate.
* When I set up right mipmap level (level=-5), it failes

My function call looks like this:

Code: Select all

		GLCHK(glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGBA_S3TC_DXT1_EXT, 128,128,0, 11040,summer_1_texture_start));

What is wrong with it?

[jsgf]

jsgf,

As wrote before, I'm using 128x128 texture

I tried to use it in DXT1 format. And I found 2 problems:
* It looks shifted exactly on 0.5 by t coordinate.

I've noticed that too. I'm not sure what's causing it. I'll need to experiment, though when I last experimented with this, I was getting the same output from the nvidia drivers. I need to double-check.

* When I set up right mipmap level (level=-5), it failes

-5? Mipmap levels are >= 0.

[Grom]

When I was triyng to set up it as 5, app just hangs,
then I searched in google and found same func doc for opengl ES. they mentioned in doc that mipmap number should be negative!

[jsgf]

When I was triyng to set up it as 5, app just hangs,

Could be a bug. I haven't tested mipmaps much yet.

then I searched in google and found same func doc for opengl ES. they mentioned in doc that mipmap number should be negative!

Can you give a reference? That doesn't sound right though. For normal textures, mipmap levels are definitely positive.

[Paco]

That's what I have in PSPGL. The 1,2,3,0 order doesn't make much sense to me. I think the PSPGL code is still wrong, but that doesn't look like the fix.

The alpha block in DXT3 contains explicit alpha values. DXT5 contains two alpha values and a block of interpolants for the pixels. In the PSP that kind of interpolated block (for both alpha and color) has the interpolants first and the color values last, the opposite from D3D's DXT format.

That's why DXT3 should use 0,1,2,3 and DXT5 should use 1,2,3,0.

[Grom]

I get info from here

So what can you say about t bias? Maybe some info will help to you or maybe I should try to modify a texture somehow?

[jsgf]

I get info from here

Ah, OK. That's an overloaded meaning for level. If level >= 0, then you're loading a texture for a specific mipmap level. If level < 0, then you're loading a bunch of mipmap levels all together. PSPGL doesn't support this usage; just call glCompressedTexImage2D N times to load N mipmap levels. You mentioned it locked up when you tried to do this. Can you describe what happened in more detail? Did the PSP power off/reset? Did the home button still work?

So what can you say about t bias? Maybe some info will help to you or maybe I should try to modify a texture somehow?

Well, if I get the same results on the nvidia drivers, I'll presume its OK. But I want to test it out before making any particular suggestions.

Which DXT format are you using anyway? Still DXT1?

[Grom]

Ah, OK. That's an overloaded meaning for level. If level >= 0, then you're loading a texture for a specific mipmap level. If level < 0, then you're loading a bunch of mipmap levels all together. PSPGL doesn't support this usage; just call glCompressedTexImage2D N times to load N mipmap levels. You mentioned it locked up when you tried to do this. Can you describe what happened in more detail? Did the PSP power off/reset? Did the home button still work?

Please, give proper code sample how to load DXT texture with mipmaps
As I remember, app just hanged. Power was still working. But I didn't try home button. I will try it tomorrow at work.

Well, if I get the same results on the nvidia drivers, I'll presume its OK. But I want to test it out before making any particular suggestions.

Which DXT format are you using anyway? Still DXT1?

I tried DXT1 format. What do you think, could it be because of DXT compression tool?

[Grom]

Ah, OK. That's an overloaded meaning for level. If level >= 0, then you're loading a texture for a specific mipmap level. If level < 0, then you're loading a bunch of mipmap levels all together. PSPGL doesn't support this usage; just call glCompressedTexImage2D N times to load N mipmap levels. You mentioned it locked up when you tried to do this. Can you describe what happened in more detail? Did the PSP power off/reset? Did the home button still work?

It have tested it again. If I'm setting up level=5, then PSP hangs for some seconds. None of the buttons works. After that it turns power off.
If I'm setting level=-5 function call just fails. All works except I got wrong texture on object.

The situation with texture offset is still interesting. Is there anybody else who tryied compressed textures? Have you also got texture shifted on 0.5 by t coordinate?
Does it only PSPGL problem or it is the same when using GU functions?