Nova videos Posted January 20 Share Posted January 20 (edited) 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 January 20 by Nova videos Link to comment Share on other sites More sharing options...
piken Posted January 21 Share Posted January 21 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): 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 More sharing options...
piken Posted January 21 Share Posted January 21 (edited) Yep, PVRTC 4bpp: (note the green color in Kuriimu's background shows through the translucent texture) Edited January 21 by piken Add screenshot Link to comment Share on other sites More sharing options...
Nova videos Posted January 21 Author Share Posted January 21 (edited) 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 January 21 by Nova videos Link to comment Share on other sites More sharing options...
Nova videos Posted January 21 Author Share Posted January 21 So it works with most of the textures, but not all of them it seems. If you want, Think you could take a look at these samples? Thanks again Samples2.rar Link to comment Share on other sites More sharing options...
Solution piken Posted January 22 Solution Share Posted January 22 (edited) 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: 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: 3. Double the width to 128. Yeah, we have something now: 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: 5. With PVRTexTool, you may see the colors don't look right with RGBA: 6. Fix that to BGRA: *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: For the other 2 images, the parameters are similar. Spoilers: offset = 0x110, size = 512x512, element type = 32-bit element type (BGRA). Edited January 23 by piken Delete weird extra blank lines 2 Link to comment Share on other sites More sharing options...
Nova videos Posted January 24 Author Share Posted January 24 (edited) 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! Edited January 24 by Nova videos Link to comment Share on other sites More sharing options...
BloodRaynare Posted January 24 Share Posted January 24 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. 2 Link to comment Share on other sites More sharing options...
Sparagas Posted February 2 Share Posted February 2 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: 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: 3. Double the width to 128. Yeah, we have something now: 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: 5. With PVRTexTool, you may see the colors don't look right with RGBA: 6. Fix that to BGRA: *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: For the other 2 images, the parameters are similar. Spoilers: offset = 0x110, size = 512x512, element type = 32-bit element type (BGRA). Thanks this is a good one! 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now