Just do it for OpenGL for now, deal with Direct3D9 when we figure out all the
graphics bugs and optimizations.

Okay... how do you suggest I do that? Add a parameter to TexDecoder_Decode?

Wow... That's one way to not use SSE where you don't actually need it, and stop
unpacking 8 bits into 32.

TextureDecoder is all about unpacking, so please, if you can, please do it for the
other formats(there are more unpacks IIRC)

Let's extend this idea, what about A4R4G4B4? (4-bit argb)

I'm creating a D3D patch right now.

I meant 16-bit ARGB, 4 bits per channel

D3D patch:

Index: Plugins/Plugin_VideoDX9/Src/TextureCache.cpp¶

--- Plugins/Plugin_VideoDX9/Src/TextureCache.cpp (revision 2211)
+++ Plugins/Plugin_VideoDX9/Src/TextureCache.cpp (working copy)
@@ -176,6 +176,12 @@
case PC_TEX_FMT_BGRA32:
d3d_fmt = D3DFMT_A8R8G8B8;
break;

• /*case PC_TEX_FMT_BGRA16: is this of any use?

•   d3d_fmt = D3DFMT_A4R4G4B4;
  

•   break;*/
  

• case PC_TEX_FMT_I8:

•   d3d_fmt = D3DFMT_L8;
  

•   break;
  

  }

  //Make an entry in the table

OK, I have finally made a WORKING patch. It works great on DX9 (but it requires
unpacking into 16-bit textures because Intensity texture format (XXXX) does not exist
in DX, only luminance and alpha, so to prevent downsampling I unpacked it to A8L8,
which is a 16 bit format. It's still blazing fast.

I am committing this, alright?

r2222, right? Looks good.

The other potentially interesting output formats are RGB565 (for GX_TF_RGB565), LA8 (for GX_TF_IA4
and GX_TF_IA8), and DXT1 (for GX_TF_CMPR).

As for RGB565:
-DX9 D3DFORMAT: D3DFMT_R5G6B5
-OGL format: GL_RGB in combination with GL_UNSIGNED_SHORT_5_6_5

Magumagu9: I have created a new patch for RGB565 textures, but something seems
awfully wrong (since it appears the same in both DX9 and OGL I assume it is in the
decoding area)

http://paste2.org/p/146466

I hope you'll manage to fix it.
Tip: A very common RGB565 is the Wii wrist boot-up screen

RGB565 is now finished and committed, see r2225

For DXT1 in OGL: use the following as the internalFormat and GL_RGB as the format:
#define GL_COMPRESSED_RGB_S3TC_DXT1_EXT 0x83F0

For DXT1 in OpenGL, I think you need to call glCompressedTexImage2D instead of the normal
glTexImage2D.

No, that's another type of unknown compression I think. It only supports
GL_COMPRESSED_* where * is the usual LUMINANCE/INTENSITY/RGB/RGBA. We can not be sure
whether it's DXT1 or some other type of compression

It's exactly as I said before: GL_COMPRESSED_RGB_S3TC_DXT1 with the usual glTexImage2D

http://oss.sgi.com/projects/ogl-sample/registry/EXT/texture_compression_dxt1.txt

wait, you have to use it with CompressedTexImage2D or it gives you INVALID_OPERATION.

I sure am a real post-bomber in this issue, aren't I? :)

Made IA8.

Here's a working DX9 IA4 patch but almost working in OGL (I can see double)
http://paste2.org/p/146798

As far as I know, OpenGL can't load IA4 directly.

It can be loaded if you choose either GL_LUMINANCE or GL_ALPHA as the format (because
they are 8-bit, it doesn't look correct), but GL_LUMINANCE_ALPHA somehow forces it to
be 16-bit for some unknown reason.

It works great on DX9 though. It boosts speed since all text in the Wind Waker are
actually IA4 textures, and they tend to appear and disappear a lot (the "Attack" text
on the top right is a great example).

This is too bad. Please make sure there is no way.

Currently though CMPR (DXT1) is the top priority. Please do it since I have RL
commitments :)

Work in progress on DXT1 at http://paste2.org/p/146966. It seems to work for most textures, but breaks
a few (like a couple of the logos for Tales of Symphonia startup); my guess is that there's something
wrong with the handling of non-power-of-two textures or something like that.

Looks good except for that CopyDXTBlock. Can it be avoided?

Avoided? The blocks have to be reorganized to be compatible with the PC version of DXT1.

XTra.KrazzY:

I set

case PC_TEX_FMT_IA4:
gl_format = GL_LUMINANCE_ALPHA;
gl_iformat = GL_LUMINANCE4_ALPHA4;
gl_type = GL_UNSIGNED_SHORT;
break;

in OpenGL plugin, and it looks correct.

http://i39.tinypic.com/2921hm0.png

I've made two screenshots

Here's a working OpenGL IA4 patch

http://paste2.org/p/147121

I haven't tried Unsigned short because it seems weird to do so. But if it makes it
correct (and I will try it) I'll commit.

Thanks hyperiris!

magumagu9: Great job there with DXT1! Here's an updated patch with DX9 support.

http://paste2.org/p/147213

Hope you fix those last Tales of Symphonia textures!

I think it seems weird too, just looks like a driver bug :<

so, we need test on AMD GPUs and linux systems.

I can see everything perfectly fine in the wind waker. I don't have ToS so I don't care.

well don't submit it until it works with ToS :)

http://www.gamedev.net/community/forums/topic.asp?topic_id=317744

According to this thread, some early Radeons that should be able to support Dolphin
don't actually support A8L8. We should probably at least add a sanity check so that
we can get reports of this.

"Beware that on the ATI Radeon 9600/9700/9800, D3DFMT_A8 is supported whereas
D3DFMT_A8L8 isn't supported."

This should be tested with OpenGL's GL_INTENSITY format, which is basically A8L8.

I don't know about D3D, but OpenGL should do the conversion internally even if the card doesn't directly
support the format.

What about DXT? Are you planning on finishing that?

I know for one that it's a very tough job making the texture overlay work with actual
DXT textures. Maybe we should call it completed as it is? It's already compact.

Here is a .patch file with XTra.KrazzY's last patch slightly edited so it doesn't
break the OpenGl plugin!

hmm, can anyone test this?

Texture Stuff Patch seems to work except for one thing: the paratroopas in Super
Smash Bros.' adventure mode have black wings when this patch is applied. Without the
patch, they have normal white wings. Weird!

I have no idea why!
The original patch made the whole screen not draw so maybe it has something to do
with that.

I'll look into it when i have time.

Ok try this please!
I changed a few things!

That makes no difference.

The PC requires DXT textures to have dimensions that are multiples of 4. But Smash
Bros. loads some compressed textures that don't meet that requirement. That probably
results in OpenGL refusing to take those textures.

The attached patch makes corrects the problem for me.

Awesome thanks Nolan.Check
Here is a newer patch with you're fixes and some other stuff.

Wonder if you shouldn't round up instead ... (w + 3) & ~3

I'm guesing w stands for width??

So I'm guesting something like this..

	  width &= (width + 3) & ~3;
	  height &= (height + 3) & ~3;

The patch keeps growing and growing. Nice work

sadly, I have no testbed to see whether all DXT textures work.

Same here XTra.Krazzy :)
I'm going to try and get one as soon as possible!

Shouldn't it be:

width = (width + 3) & ~3;
height = (height + 3) & ~3;

?

I don't know try it with and without the & parts.

Here is Texture Stuff Patch 6.

These are the changes:

• Add PC-native DXT1 support to VideoCommon and OpenGL plugin
• Add I4 support to VideoCommon and OpenGL plugin
• Make paletted texture decoding smarter; they aren't all decoded to ARGB anymore

Includes work by XTra.Krazzy, death2droid, and myself.

Please test!

Good job Nolan.Check!

How can I test I4 and IA4 textures? I doubt the current patch handles them correctly
if they're ever used.

I have no idea.
I don't know any games that use it.

The wind waker utilizes IA4 for the waves in the sea and the copyright below the
logo. As for I4, it is used somewhere but I don't quite recall where

To fix the issue with non-multiple-of-4-sized DXT textures, we could decode them to
standard RGBA textures in the old way, and only use PC DXT textures if the size is a
multiple of four (which is the most common case).

That seems pretty drastic. The paratroopa wing textures at least seem to work fine
with the hack of rounding up the width and height. They also seem to work fine when
rounding DOWN the width and height, but I need to take a closer look before I'm sure.

Oh, and it looks like OpenGL does not support I4 and IA4 natively. It has the
"internal format" parameters "GL_INTENSITY4" and "GL_LUMINANCE4_ALPHA4", but
apparently these are only performance hints for the driver. The actual data has to
be converted to I8 or IA8 respectively.

That's not confusing at all...

Know what else isn't confusing at all?! Trying to figure out the difference between
"intensity" and "luminance". I'm still not 100% sure.

Didn't I document intensity and luminance before? Intensity is alpha and grayscale
color and luminance is grayscale color IIRC. For instance, in the wind waker the sun
is I8, which means that both the alpha and the color (in grayscale, colored later to
orange) are the same value.

I committed DXT1 support. I'm not very confident in the other stuff.

Dolphin now requires S3TC support on the user's graphics card. Is this reasonable, or
should we detect support and fall back to manual decoding if necessary?

Your commit glitch more game. Please fix.

Resident evil remake (GC) - Chris
http://img301.imageshack.us/img301/3725/gbie081.jpg

Wario land shake it! (WII) - Press button 2
http://img14.imageshack.us/img14/4475/rwle011.jpg

Hm, given these results, I think we should go back to manual decoding but keep the PC
DXT1 option as an experimental option, until it works 100%.

Darn. I don't have any of those games.
Can someone really quickly try rounding the texture dimensions down instead of up,
please? There's a simple change to make in VideoOGL/TextureMngr.cpp. I'll make a
patch if necessary.
By those screenshots, it looks like the width of the texture is being set to either
one block too short or one block too long.

many games looks, more awesome, with this commit, incredible texture :D

a few games show this...
http://i41.tinypic.com/11skuuu.jpg

I tried the games with rounding up and down, I don't get distortion either way. Just a
fyi I guess...

Could be a case of bad drivers too...

hey death2droid, missed you on IRC. You have been added.

Alright, please test this patch. I am now rounding width and height up to the next
multiple of EIGHT in both VideoCommon and VideoOGL. It actually seems to fix some
distortion on the koopa shell items in SSBM, and I haven't seem any regressions so far.

In recent revisions I saw the distortion bug on the wario shake it menu screen. perhaps
my build was not completely up to date before :(

Anyways, using that patch to round up to the next multiple of 8 does fix the distortion
for me.

Test your patch. Glitch with Zelda WW.

http://img13.imageshack.us/img13/9770/zelda01.jpg

Crud. I made a rather silly error in that patch. Can you find it?

Here's a new one. Revert the previous patch first.

hmmm why don't you submit this into the svn?

Because he wants to make sure it works.

dont know is this might help anyone. but i can confirm that there are distortions in
Paper Mario:TTYD most of the textures are corrupted including mario and his partners
as well as the enemies and 2d backgrounds.

Your new patch fixes the corruptions in Super Paper Mario for me.

ya nolan, i had removed that part of the patch when i tested before :p

I noticed the "expandedWidth" variable used by VideoOGL's texture loader, and I'm
wondering if we should introduce an "expandedHeight." VideoCommon's
TextureDecoder_Decode_real function should not round up the width and height; it
should be up to the video plugin, correct?

Sorry, I'm just thinking.

I've committed a fix.

looks good

alot of games how doesnt display anything....gives alot of error like 09:25:106 E: *
Warning: Invalid PC texture format 268437664...

now*

Odd did this start happening in r3187 or r3188
If it's r3187 i might revert the change.

Of course if there is anymore reports

Reverted changes in r3187 because of the problem.

weell, it's cause by r3187 but then r3159 cause this
http://i41.tinypic.com/11skuuu.jpg

is it just me? im using geforce 7900GTX with 185.85 WHQL drivers

I have no problems like in the screenshot.
But i did get the Invalid PC texture format which i reverted the patch which caused
that to happen.

Also what game are you using.

wii games like ssbb, bust a move ,ZTP, and a couple of other games. only happens on
the wiimote screen though....and a few distorted graphics in game.....

I don't see how my patch could have caused TexDecoder_Decode_real to return
PC_TEX_FMT_NONE, thus causing OpenGL to throw that error message...any ideas?

I have no idea.

Try reverting r3188 instead. I notice that r3188 changes the conditions for when
TexDecoder_Decode is called.

Actually, it looks like VideoOGL throws that error message also when dfmt is some
completely unknown value. I think dfmt is getting corrupted somewhere.

Its fixed in the newest revision by baby.lueshi

i still got distorted graphics in the wiimote screen

Which video plugin are you using? I'm wondering because the FPS indicator is blue. I
thought it was supposed to be yellow.

Never mind, I'm obviously clueless about that.

Is the Wii Remote warning screen an S3TC texture?

It has fixed. You must update opengl plugin.

Blue color is better...

OK, good.

The FPS color should be aqua.

no, it has not been fixed yet, btw im using the opengl plugin. this happens to some
games only. some games works perfectly, others show distorted graphics....

im using latest SVN, DirectX March Update 2009, Nvidia 185.85 WHQL Drivers, E8400,
7900GTX, 64Bit Dolphin

just to add that all these distortion graphics happens after r3158.

What's your game?

ssbb (pal)

what's your gfx card?

With PC-native DXT texturing, the black fringes on grass in Zelda Wind Waker are back.
GC handles transparency differently.

I'm not sure PC-native DXT is worth all this trouble. If it is, it should only be used
if (1) the texture contains no transparency (could scan it quickly for that before
decoding) and (2) the dimensions are exact multiples of 8.

"GC handles transparency differently." Is that related to premultiplied alpha? i.e.
the difference between DXT1 and DXT2

Never mind. It's clearly not.

Transparent pixels have the color black on PC, while on GC, they get the mid color
(or one of the two reference colors, not entirely sure but the mid color looks good)
of the current block. The color of transparent pixels might seem to be irrelevant but
due to bilinear filtering it does matter.

Is this done now?

Or now?

Issue 2126 has been merged into this issue.

Are you guys sure that this is the same issue as 2126?

DXT native was enabled only in a few revisions (50 max), in this one, the problem is
on older than the DXT native change.

Later i'm going to try in older builds than the 3200, to see win with one the game
stops showing graphics, and then ill pass here for feedback.