The VG Resource

https://github.com/MrRean/ReggieNext-NSM...ter/gtx.py
This is what ReggieNext uses to decode NSMBU's gtx files. I figure it can be easily modified to read the HEAD chunk and use it to load in the GTX data.

Yeah, it's definitely a GTX-based texture.


I'll have to write up the QuickBMS script to detect all of the formats and whatnot a bit later, but I've got a start at least.

Awesome, that's a very nice start! Did you figure out any of the other header values?

Very nice dude!

https://dl.dropboxusercontent.com/u/2787...RtoGTX.bms

Preliminary script time! This QuickBMS script should convert the pre-decompressed TXTR files into GTX, which can then be converted to DDS with TexConv2. I've only tested it with the files in PreLoadPak so far, looks like all of the textures there were either DXT1, DXT5 or ATI2 so I didn't need to write too much for those currently. Most textures there convert fine, but some of the itty-bitty ones are a bit garbled (but I think that's actually the fault of the TexConv2 program).

0x08 past "HEAD" is the size of the information chunk. That plus 0x18 for the default header length will bring you to the "GPU" section.
0x1C is the format, so far I've seen these -- (0x14 = 0x31/DXT1), (0x18 = 0x33/DXT5) and (0x1C = 0x35/ATI2). ATI2 textures need to be converted with the "lossless" method + the lack-of-a-better-name "DDS Fix script" to fix the colours/transparency afterwards because TexConv2 doesn't convert it properly otherwise.
0x28, listed as "Depth", seems to be used for the amount of animation frames which my script currently detects and splits accordingly.
0x30 is the "swizzle" value.
0x38 is indeed the texture size without taking any mipmaps into mind.

Not sure about most of the other header bytes that weren't already mentioned in your notes, but they aren't necessary for texture conversion from what I can see. There's probably some more texture formats, but I'm kinda sleepy right now so I'll leave it at that currently.

(EDIT: "Depth" doesn't seem to be just for animation frames, some textures have 6 which is used for a cubemap.)

awesome! Tried it out myself, works great! Some of them definitely aren't coming out right (can't even view some of them) but most of them look fine, so this is a really really good start!

That's interesting about the animated textures. I think I just noticed the value's relation to the data and assumed it was for depth textures, since obviously I wasn't able to decode the textures to see what was actually different. Retro's older games all did animated textures by sticking multiple frames within the same texture and then using a stepped UV animation to scroll between them... this definitely looks like a better way to do it. Wonder if one of the other values controls the speed of the animation, or maybe that's just entirely handled in the shader?

edit: Tried it on Mangrove Cove and Lord Fredrik, both worked fine. I think the "animation frames" value is actually just a way of storing multiple images in one texture and animations is just one particular way it's used - I'm seeing it being used on other textures where it clearly isn't meant to be an animation (it seems like most levels have a really big texture - probably a light/shadowmap? - that contains a bunch of sub-images). So it's not specific to animations.

Random highlights: I found the texture for DK's 3DS



and there's also an extremely low-res version of the Japanese DKCR title screen in the files for Mangrove Cove for some reason

UIPak has some textures that didn't convert, so I'll definitely have to check that out on the 25th since I'm going to be away for most of the day today.

Right, did some digging around to refresh my memory - I think depth is the correct name for that variable. It's a 3D texture where the depth value is part of the texture dimensions (width = X, height = Y, depth = Z). Function definition of GX2InitTexture basically confirms it; it takes a u32 parameter "depth" right after width/height.

(12-24-2015, 06:40 AM)Parax Wrote: [ -> ]Right, did some digging around to refresh my memory - I think depth is the correct name for that variable. It's a 3D texture where the depth value is part of the texture dimensions (width = X, height = Y, depth =  Z). Function definition of GX2InitTexture basically confirms it; it takes a u32 parameter "depth" right after width/height.

Yeah, that makes sense.

Anyway, ended up fixing the script after all (sleeplessness is both a good and bad thing), so now the "0x0C = 0x1A/RGBA8888" format textures are properly detected.

Awesome. Updated the wiki page with your info.

Do we know how the swizzling actually works (and how the swizzle value affects it)? That's what I kept getting stuck on last time I tried decoding these myself. The GC/Wii swizzles are relatively simple, but the Wii U ones seem to just be amazingly complicated. Either that or I just completely don't understand it.

HOOOOLY CRAP!

Random Talking Bush, you are awesome and I owe you an Internet.

EDIT: Your script, for me, seems to spit out jumbled garbage data. I wonder if I'm just extracting the wrong TXTR.

(12-24-2015, 12:06 PM)TabuuForteAkugun Wrote: [ -> ]HOOOOLY CRAP!

Random Talking Bush, you are awesome and I owe you an Internet.

EDIT: Your script, for me, seems to spit out jumbled garbage data. I wonder if I'm just extracting the wrong TXTR.

Are you trying to convert the entire folder with a wildcard? It didn't work for me when I did that; I think because it ends up trying to convert the non-TXTR files. Try selecting the TXTRs you want to convert manually.

Okay, thanks. And if I read right, I have to decompress the PAK's files first?

Yeah, decompress them first.

Well now it doesn't extract anything.

I still get crud that looks like snow on a TV