Jump to content

(iOS) Alpha Zero .dtx Texture Format


Go to solution Solved by piken,

Recommended Posts

Hello! I've been trying to get these textures into a viewable format and haven't been successful at all, I've tried using some general tools such as raw texture cooker and whatnot, but little to no success. Any help is appreciated

Thanks in advance!

samples.rar

 

Edited by Nova videos
Link to comment
Share on other sites

It has regular patterns every 8-bytes apart (blocks of 64 bits), with a clear partition between one chunk of 4 bytes (likely color endpoints) and the other 4 bytes (likely indices):

image.png.bf73ff885ab40ccd6a41b14a6b2680aa.png

It's probably PVRTC (https://en.wikipedia.org/wiki/PVRTC, https://blog.imaginationtech.com/pvrtc-the-most-efficient-texture-compression-standard-for-the-mobile-graphics-world/), as many mobile games use PVR/ETC1/ETC2. From the list of viewers here https://reshax.com/topic/170-graphicstexture-finders-and-viewers/, have you tried PVRTexTool and Kuriimu?

Link to comment
Share on other sites

Wow, nice! I always thought it was some sort of encrypted .zip (barely know hex) because I saw some headers containing unique resolution dimensions under “ipad_hd” and “iPhone” in spaceship.dtx and whatnot like 2048x2048 under ipad_hd specifically, is it possible that there’s higher quality image data in there? Nonetheless thanks so much!

 

Edited by Nova videos
Link to comment
Share on other sites

  • Solution
Quote

Think you could take a look at these samples? 

Aah, these are easy ones, and I can't spoil the fun outright of you figuring it out :D. So instead, I'll share the process of how I'd figure it out (potentially useful for anyone else too reading this post later), and try to guess the remainder at any step along the way 🤞.

1. Pick your favorite image viewer to open the file "asteroid1.dtx" with some small wrap width (powers of two are a good start) like 64, and scroll through it looking for patterns. Notice the groups of four bytes, meaning the image elements are probably 32-bit. Notice the interleaved black lines, meaning it's too small of a wrap width:

image.png.56d1afc7d20d62c7ca61a53a9f5bff09.png

2. Try 32-bits per pixel instead. Yep, that looks much better, and it's clearly stored as raw linear (no block compression), but the wrap is still too small:

image.png.a688c7b088f295a41aacaf0cb38abc0a.png

3. Double the width to 128. Yeah, we have something now:

image.png.71e01af1e29c5d334b81108cca371874.png

4. The image is shifted though. So align the image's base offset (0x110 looks either right or very close, just visually skipping past the header bytes). You'll notice some mipmaps too later:

image.png.0b40c0c63bb47470bc5cc821d312d84e.png

5. With PVRTexTool, you may see the colors don't look right with RGBA:

AsteroidBlue.png.10056c6082ed23ef12e7d17c64ad8eff.png

6. Fix that to BGRA:

AsteroidTan.png.8b67e665160527d12844f7b325bfc03d.png

*Beware that some tools (evidently Kuriimu2's raw image viewer and TiledGGD) store the channels bewilderingly backwards. So unlike PVRTexTool, where BGRA means exactly that (blue comes first, green is the next byte, red, and finally alpha as byte 3), you have to use "ARGB" 🙃. Otherwise you get wonky blending since the blue channel is being misread as alpha.

7. The color looks way too bright though. The default color space might be set to sRGB. So use Linear instead:

image.png.738d159339dddbbda7d5062f6defa666.png

For the other 2 images, the parameters are similar. Spoilers: offset = 0x110size = 512x512element type = 32-bit element type (BGRA).

 

Edited by piken
Delete weird extra blank lines
  • Like 2
Link to comment
Share on other sites

2 hours ago, Nova videos said:

Thanks!

I do have another question, Is it possible to batch convert all these .dtx files to .Png or no? Either way, thanks so much for the help

really appreciate it!

Yes, you can
I just wrote a Noesis python plugin for this format here:
tex_AlphaZeroDTX.zip
Put this py script in the <Noesis directory>\plugins\python\
Then ran Noesis and use "Batch Process" for convert them all.

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...
Spoiler
On 1/22/2024 at 9:08 AM, piken said:

Aah, these are easy ones, and I can't spoil the fun outright of you figuring it out :D. So instead, I'll share the process of how I'd figure it out (potentially useful for anyone else too reading this post later), and try to guess the remainder at any step along the way 🤞.

1. Pick your favorite image viewer to open the file "asteroid1.dtx" with some small wrap width (powers of two are a good start) like 64, and scroll through it looking for patterns. Notice the groups of four bytes, meaning the image elements are probably 32-bit. Notice the interleaved black lines, meaning it's too small of a wrap width:

image.png.56d1afc7d20d62c7ca61a53a9f5bff09.png

2. Try 32-bits per pixel instead. Yep, that looks much better, and it's clearly stored as raw linear (no block compression), but the wrap is still too small:

image.png.a688c7b088f295a41aacaf0cb38abc0a.png

3. Double the width to 128. Yeah, we have something now:

image.png.71e01af1e29c5d334b81108cca371874.png

4. The image is shifted though. So align the image's base offset (0x110 looks either right or very close, just visually skipping past the header bytes). You'll notice some mipmaps too later:

image.png.0b40c0c63bb47470bc5cc821d312d84e.png

5. With PVRTexTool, you may see the colors don't look right with RGBA:

AsteroidBlue.png.10056c6082ed23ef12e7d17c64ad8eff.png

6. Fix that to BGRA:

AsteroidTan.png.8b67e665160527d12844f7b325bfc03d.png

*Beware that some tools (evidently Kuriimu2's raw image viewer and TiledGGD) store the channels bewilderingly backwards. So unlike PVRTexTool, where BGRA means exactly that (blue comes first, green is the next byte, red, and finally alpha as byte 3), you have to use "ARGB" 🙃. Otherwise you get wonky blending since the blue channel is being misread as alpha.

7. The color looks way too bright though. The default color space might be set to sRGB. So use Linear instead:

image.png.738d159339dddbbda7d5062f6defa666.png

For the other 2 images, the parameters are similar. Spoilers: offset = 0x110size = 512x512element type = 32-bit element type (BGRA).

 

Thanks this is a good one!

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...