two g1t files of A12 can't be extract

[chitanda]

A12.zip ‘A12_EV_RORONA.g1t’、‘tgs2012_gameend.g1t’ it catch the error: ERROR: Unsupported texture type (0x21) i also have try the HyoutaTools,can't work too. I have found the filename in google and find in the PS3 ver,the CG of ‘A12_EV_RORONA' don't exit.I dont know if it's a really cg file. can u help me?

[chitanda]

A13.zip i find there also a file in A13 can't be extra，the files i upload yesterday are from the NS ver ,and i upload the STEAM ver of A12 too(the hash of these files are not same.

[VitaSmith]

Well, texture type 0x21 seems to be an ARGB 32bpp texture, so that's something I can add since it requires no conversion.

• A12_EV_RORONA.g1t:
  
• tgs2012_gameend.g1t:
  

However, it looks to me like these textures are clearly designed to be displayed only on a PS Vita (the effective texture size is 960x545, which is the resolution of PSV), and I'm afraid I am only interested in supporting files that are relevant to PC games.

My understanding is that you got these from the PS3 version of the game, which would make sense, as the PS3 version probably includes extra content that it can display on a connected Vita. Bear in mind however that I'm only planning to support PC relevant content in gust_tools, as I didn't design them to be used with the PS versions of the games. If someone wants to submit patch (and then support these features) to support PS games files, that's fine, but I'm personally not going to go out of my way to support PS content.

As to the other files:

• a13_e3_thank_you_01_ns.g1t is weird. It's supposed to be type 0x01, and therefore RGBA but it's actually type 0x21, i.e. ARGB. And once again it's meant to be displayed on Vita:
  
• A12_EV_RORONA_steam.g1t and tgs2012_gameend_steam.g1t are type 0x09 which is GRAB, and are supposed to match the same output as above, but there's an additional block transformation being applied:
  

Still, clearly these are all textures that are aimed to be used on Vita only, so I'll probably add the bare minimum of code to ensure that they get extracted, in whatever form is easiest for me, but I can not guarantee that you will actually be able to edit them, let alone view them.

[chitanda]

in face these files are from the nintendo switch ver (Atelier Arland series: Deluxe Pack).it seems that they remain all the files of the PS3 ver. the gust_tool is also useful for me to extract the NS ver files too,and for me,the feature of extract is enough. 3Q ，u are so helpful to me. And the issue for me is done ,u can close it now.

[VitaSmith]

I'll leave it open for now, as, at the very least, I am planning to add at support for type 0x21, which is very easy to do, and I'll probably add dummy extraction for 0x09 since at the very least we know it's GRAB.

I'll close this issue when I add these changes to the code.

[VitaSmith]

Apart from a13_e3_thank_you_01_ns.g1t, textures should now be properly extracted in the 1.8 release of gust_tools. Enjoy!

[chitanda]

A15_0x10.zip @VitaSmith i'm sorry to bather u again so soon.I know u have not test .g1t texture types of 0x10.I find some g1t files in A15 is 0x10 and they all can't be extra truely: like the image below i think it maybe a bug for the progam,so report it .u can have a look if u have time someday

[VitaSmith]

Sorry @chitanda, but I won't be adding support for type 0x10.

I spent about 3 days trying to figure out a way to do so, but it'll just require too much work. I know that Steven's Gas Machine (xentax) is supposed to support type 0x10, using the Xbox360 libraries , and I've tried to replicate exactly what they were doing, but that doesn't work either (and it doesn't work in Gas Machine either).

[chitanda]

ok,it's fine all the way.i'm sorry to bather u so much.

[Joschuka]

Contrary to what Semory's comment seems to imply in the gas machine source code, type 0x10 seems to be for other platforms too, I guess he just didn't have samples at that time. 0x10 seems to be DXT1 with some morton order 0x4, at least for Vita (platform code 0x6), here's one image of the A15_0x10.zip samples above decoded, all of them works Similarly 0x12 is DXT5 with morton order 0x8

You can take a look at our parser here in case you want to implement it since we only do extraction, hopefully it'll be somewhat useful since we use some Noesis internal functions. https://github.com/Joschuka/fmt_g1m/blob/master/Noesis/plugins/python/fmt_g1m.py#L992-L994

Thank you btw, your repository helped us quite a bit for g1t, I mentionned you in the credits on my zenhax/xentax topic

[VitaSmith]

Aha, so that is called a Morton order...

I'm not a graphics/texture expert (I'm pretty much discovering this whole thing as I move along), so I just called that an 'И' transposition. Finally I can make some sense of it! 😉

Thanks a lot for the pointer to your fmt_g1m plugin. This looks very comprehensive in terms of supported types, so I'm definitely going to study that when I have a chance...

[Joschuka]

Happy to help !

All the formats should be verified except 3C/3D/5C and 5D. I just took these from Semory's code but I never had actual samples to test if these worked correctly. Also the computation needed could vary depending of the platforms, maybe Semory's code actually worked for the 0x10 X360 samples so I would recommend to use the platform ID to choose the needed computation. Don't mind the whole ETC1 and PS4 sections, the first one is just some computation to prepare the texture data so that it can be fed to an external .exe for conversion since Noesis doesn't support the format natively and the second one is PS4 unswizzling. I added these recently due to user requests.

Hopefully it'll help you, it could be way more clean but we were busy fixing bugs on models and animations and were figuring out stuff as we went with this plugin lol

Thanks again for your repo, it was a really great resource !

[VitaSmith]

I've finally added support for type 0x10 to gust_g1t.

But someone will have to explain what the heck Noesis does in rapi.imageFromMortonOrder() and specifically what the "£$%^& a "morton width" is, because it seems to have little to do with an actual Morton Order (which, AFAIK, is the log2 of the width/height of the square element you apply a Morton/Z-Order curve to, i.e., if you split texture in a series of 8x8 squares, and you apply Morton to each square, then the Morton order should be 3).

My findings (on the 1024x1024 DXT1 sample textures provided in A15_0x10.zip above) is that you should apply a Morton order of 8 not 4. In other word, you need to "Mortonize" or "Unmortonize" on the maximum dimension of the texture (since DXT1 means you're dealing with individual compressed elements of 4x4 pixels, hence the actual dimension of the texture, in number of individual elements is 256x256, and log2(256) = 8).

And what's more, since I also added support for DXT5 type 0x62, per (#25), which actually uses a Morton order of 3 with tiling, whereas the plugin sees a mortonWidth of 8 and makes no mention of tiling. So I genuinely have no idea what the frick Noesis' imageFromMortonOrder() does or what Rich Whitehouse calls a "Morton width", because it's definitely not simple Morton transformation (It should be noted that you can't substitute tiling with Morton, since these transformations are not mathematically compatible). But it sure made me spend a lot of time trying to make sense of what Noesis might be doing, which I'm not very happy about. Stop releasing closed source software, you mor(t)ons!!!

If only people realized the amount of time that humanity is wasting, on account of closed source software, and how it hinders our development as a society...

Anyway, type 0x10 should work for the textures above in the latest gust_g1t.exe. And if someone has 0x12 sample, with no extra mipmaps, I might add support for this type as well.

[Xenogz]

PSV_txtr.zip 0х12... Like this?

[yretenai]

the "mortonWidth" var in the fmt_g1t plugin means bytes per pixel, the variable name is unfortunately misleading as it's a holdover from previous code during testing. A "morton width" of 8 means that every pixel is 8 bytes, and similarly 4 means 4 bytes. It's like this because it's ordering blocks and not pixels (a single DXT1 block is 4 bytes, and a DXT5 block is 8 bytes)

In other words "width of pixel in bytes," it's a badly named variable and unfortunately that's my fault. Sorry.

[VitaSmith]

@GrayDZ, thanks for the samples!

I think I'm fine with the second 512x512 texture, which, like type 0x10 appears to be using log2(width/4) (/4 because once again we're dealing with 4x4 DXT elements) as the Morton order, and looks okay to me when extracted that way:

As to the first texture, its Morton order is log2(max(width,height)/4), so that would be 8 for a 1024x512 texture, which I was also able to confirm:

Note that I am missing the second part of the image above, on account that my current code needs to be modified further to handle a Morton order that is bigger than log2(min(width,height)/4). I'll fix that in the next version.

@yretenai,

the "mortonWidth" var in the fmt_g1t plugin means bytes per pixel

I think you mean "bits per pixel" (which is 4 for DXT1, 8 for DXT5), as a 4x4 pixel element occupies 8-bytes for DXT1 and 16 for DXT5 (which means that bytes per pixel would be 0.5 for DXT1 and 1 for DXT5).

I think what mostly threw me off is the fact that I've been trying to make sense of PS4 and non PS4 DXT# texture at the same time, in terms of Morton order, and you guys have a special case for platform == 0x0B (a.k.a. PS4) in the plugin, that calls yet another completely obscure rapi.callExtensionMethod("untile_1dthin"...) function, that most likely applies a fixed Morton order of 3 and tiling of 8 instead of just a Morton order of log2(max(width,height)/4).

If I feel like sinking some more time into this, and now that I'm hoping to have a much better understanding of what each platform requires (except XBox360. Sure hope Noesis' imageUntile360[Raw/DXT]() does actually perform simple untiling. But considering that PS4's untile_1dthin applies Morton, I'm not so sure), I'll probably improve platform support to do something similar as what your plugin does. But then again, as long as Gust seems to be tying specific types of texture to specific platforms, and, most importantly, as long as nobody complains here, it's probably not that much of a priority...

In other words "width of pixel in bytes," it's a badly named variable and unfortunately that's my fault. Sorry.

No worries. The name of the variable doesn't really matter if you can see what it's actually being used for. But since Noesis is closed source (that is unless you fork a lot of $$ for a special license, which, to me, is the same as closed source), we can't find that out, and a lot of time is being wasted on reinventing the wheel...

I do greatly appreciate the work you guys did on the plugin though, because, even if I'd have preferred a "bits per pixel" variable to be named just that (:wink:) it definitely saved me a lot of work when it comes to understand how I can add additional support for some types...

[VitaSmith]

After some more time spent figuring out the Morton/swizzling differences between platforms, and refactoring, the latest release of gust_g1t should be able to handle handle all the textures provided above properly:

[Joschuka]

Great job ! It will definitely be useful for modders. And yeah sorry about the weird naming conventions, we were figuring out and learning Noesis as we wrote the plugin. I should actually rename these in the new C++ version to prevent confusion. I wonder if they unswizzle based on the texture format ID like you do or based on the platform ID. The former would be more reasonable considering the format duplicates wouldn't make much sense otherwise.

[VitaSmith]

Yeah, I'm not sure either, and I wouldn't mind if someone provided textures for a type that I have but for a platform that I don't. For instance, here are the textures I am currently testing with (which can be downloaded from an archive I maintain at https://vitasmith.rpc1.org/gust_tools/test_g1t.7z):

* type_01_sw.g1t...     [PASS]
* type_09_ps4.g1t...    [PASS]
* type_10_psv.g1t...    [PASS]
* type_12_psv.g1t...    [PASS]
* type_12_psv_2.g1t...  [PASS]
* type_21_sw.g1t...     [PASS]
* type_3c_3ds.g1t...    [PASS]
* type_3d_3ds.g1t...    [PASS]
* type_45_3ds.g1t...    [PASS]
* type_59_win.g1t...    [PASS]
* type_5b_win.g1t...    [PASS]
* type_5f_win.g1t...    [PASS]
* type_62_ps4.g1t...    [PASS]
* type_62_ps4_2.g1t...  [PASS]
[ALL TESTS PASSED]

Obviously the part after the type is the platform. So if anyone has one of the type_XX from the list above, but for a different platform, I'm interested...

I should also mention that I do have an issue with type_59_win_2.g1t, which is included in the archive but that I left out of the tests, because even though it is type 0x59, which should be DDS_FORMAT_DXT1, and for a texture of size 256x256 with a single mipmap, it doesn't occupy 32 KB (= 256x256x0.5 since DXT1 uses 4 bits per pixel) but 192 KB.

I currently have no idea what the deal with this texture is, except that other type 0x59 do seem to comply with the expectations of DDS_FORMAT_DXT1...