UnsupportedDataFormatError: Unsupported texture format RGB565 (104)

[JokerDKha]

Help with Pokemon Ultra Sun And Moon bflim.

[Tyulis]

That was a small error, it's fixed now. Thanks for you input !

[JokerDKha]

Sorry for bothering you again, but how do I repack bflim to RGB565. I tried repack it many times but it shows RGBA8. The Hex file is here. Original File: Pack File:

[Tyulis]

Did you use the -O format=RGB565 command line option ? Even if the texture is not is the original format, usually it doesn’t cause any problem anyway.

[IcySon55]

"Even if the texture is not is the original format, usually it doesn’t cause any problem anyway."

I would not recommend this. The game is using RGB565 for a reason, and that is VRAM. If you go around randomly increasing the size of textures and other images, you might crash the game if it runs out of memory. Then you'll be pulling your hair out trying to figure out what's going wrong!

[JokerDKha]

Did you use the -O format=RGB565 command line option ? Even if the texture is not is the original format, usually it doesn’t cause any problem anyway.

Now the pack is good but seem like is make picture error like this. Im used: 3dskit.py -pf BFLIM -O format=RGB565

[JokerDKha]

"Even if the texture is not is the original format, usually it doesn’t cause any problem anyway."

I would not recommend this. The game is using RGB565 for a reason, and that is VRAM. If you go around randomly increasing the size of textures and other images, you might crash the game if it runs out of memory. Then you'll be pulling your hair out trying to figure out what's going wrong!

Yeah the game is crash if using file not RGB565.

[Tyulis]

"Even if the texture is not is the original format, usually it doesn’t cause any problem anyway."

I would not recommend this. The game is using RGB565 for a reason, and that is VRAM. If you go around randomly increasing the size of textures and other images, you might crash the game if it runs out of memory. Then you'll be pulling your hair out trying to figure out what's going wrong!

You’re right, hence the "usually". I never got any problems with that, but this doesn’t mean it cannot happen. But it works with -O format=RGB565, I just got the time to double-check and resolved a small byte order problem by the way.

Now im the pack is good but seem like is make picture error like this.

If the latest commit doesn’t solve your problem, check that you use all the original options (-O format=<format> for the pixel format, -O swizzle=<texture swizzling option>), just as they are printed by the extraction command.

[JokerDKha]

It only pack single one output format like this. It cant pack 2 -o

[Tyulis]

The packer-specific options are with an upper-case O In this case, 3DSkit.py -pf BFLIM -O swizzle=4 -O format=RGB565

[JokerDKha]

it still error like same way:

[Tyulis]

Oh, I see. I assume this file comes from a 3DS, so it must be little endian, but as BFLIM is originally a WiiU format, it is packed in big endian by default. You have to force little endian with the -l option

[JokerDKha]

still crashing a game and picture error

[Tyulis]

Ok, I double-checked everything, indeed it causes a game crash but I have no problem with the image whatsoever, so the problem might be elsewhere. I’m trying to investigate this.

[Tyulis]

I finally found several problems with subdirectories in the GARC and ALYT packers, especially on Windows. It’s now fixed, and it works (Make sure you use version 6 when you repack your GARC with -O version=6)

[JokerDKha]

Thank's for the support now anything working so fine <3

[JokerDKha]

Can you check about this file seem like it error. Im try repack this file and the game crash again. Location file: a1-2-5

5.zip

[Tyulis]

Well, it looks like it’s some sort of custom container that is incorrectly detected as a BFLIM by 3DSkit (hence the weird looping on the image). I think you’ll need to use an hex editor to extract the BFLIM part yourself (everything that is not highlighted here), convert the BFLIM with 3DSkit, edit it, convert it back to BFLIM, and put it back into the file. As it is a custom format with no way to recognize it properly, there is not much I can do, sorry ^^

[IcySon55]

That looks like a bad extraction, as if the archive tool has the offsets wrong. :thinking:

Looks more like it should start at SARC which is a known archive format.

[JokerDKha]

That looks like a bad extraction, as if the archive tool has the offsets wrong. 🤔

Looks more like it should start at SARC which is a known archive format.

Im try delete First Hex File and extract the SARC. The file now can extract But now i dont even know how to put it back :(

[IcySon55]

Hmm, I know our tools support SARC. Have you heard of Kuriimu? Or perhaps you're asking about how to put it all back in the end, like restoring the stripped bytes before SARC. I haven't looked into these files that deeply so I'm short on details.

How many layers of extraction are we at before getting to the BFLIM? Like how many archives deep are we and what are the filenames and types?

[JokerDKha]

Hmm, I know our tools support SARC. Have you heard of Kuriimu? Or perhaps you're asking about how to put it all back in the end, like restoring the stripped bytes before SARC. I haven't looked into these files that deeply so I'm short on details.

How many layers of extraction are we at before getting to the BFLIM? Like how many archives deep are we and what are the filenames and types?

Im trying used Kuriimu too but it still error. Can you check help me check out this file? Here is the file: dec_2.zip

[Tyulis]

Hmm, I know our tools support SARC. Have you heard of Kuriimu? Or perhaps you're asking about how to put it all back in the end, like restoring the stripped bytes before SARC. I haven't looked into these files that deeply so I'm short on details. How many layers of extraction are we at before getting to the BFLIM? Like how many archives deep are we and what are the filenames and types?

3DSkit supports SARC as well, but there’s a custom header with no way to recognize it properly, and it is probably only used here.

[Tyulis]

But now i dont even know how to put it back :(

You can directly copy the reconverted file’s content in place of the old one with an hex editor

[Tyulis]

That looks like a bad extraction, as if the archive tool has the offsets wrong. 🤔

It’s not, I double-checked the GARC content and the files are extracted properly

[JokerDKha]

But now i dont even know how to put it back :(

You can directly copy the reconverted file’s content in place of the old one with an hex editor

Im use HxD but dont know how to import or replace the file.

[Tyulis]

Just replace the original content at the original position by the new one by copy-pasting

[JokerDKha]

Copy like that make a files error. Im use File edit sarc and i copy original content form old file to new file like this.

[Tyulis]

Are you sure you pasted it at the original position, and that you replaced the original content (by selecting it before pasting such that it is overwritten) ? It should not give you any "file size changed" warning

[JokerDKha]

Original File: Edited File:

[Tyulis]

Ok, so if you’re sure you put the data correctly, what kind of error do you get ?

[JokerDKha]

Ok, so if you’re sure you put the data correctly, what kind of error do you get ?

Im try repack a game with edited file, and the game crash. The file edited cant extract(3dskit) or view(Kuriimu,SwitchTool) again.

[Tyulis]

What’s weird is that I have no problem whatsoever

[Tyulis]

Oh, I found your problem. I’m trying to fix it, it’s in the pure-python compression part

[Tyulis]

It should be fixed by the latest commit

[JokerDKha]

Working 100000% Thank's you <3

[JokerDKha]

Sorry for bothering you again but im need help for extract Z-move sprits but i dont know how to open this file and extract it. Im using 3DSkit and it print like below: No compression UnrecognizedFormatError: Unrecognized format (102) dec_2.zip

[Tyulis]

It seems like a custom texture format, so it’s not supported by 3DSkit The header mentions a TGA file, but it doesn’t look like one.

[JokerDKha]

im find out we can Export with this: https://gbatemp.net/threads/wip-ultra-sun-and-ultra-moon-pokemon-models-textures-and-animations.490365/ But now i dont think this tool will let saving again after editing a picture :( EDIT: I find out the way to replace the tex. Tks and sorry bothering you <3

[IcySon55]

Hey there guys. Just figured I could chip in here specifically on dec_2.bin.

The image is 3DS Z-Order ETC1A4 encoded, 512 x 256:

And here's the image saved to PNG:

The file header leaves much to be desired but an image plugin for this is certainly doable. :)

[JokerDKha]

Nice is so good to hear that, if kuriimu have image plugin for this tex. It so easy for edit picture in game. There is so much file in this game using image is 3DS Z-Order ETC1A4 encoded in game.

[IcySon55]

A plugin would need to be created of course, but that shouldn't be that difficult if somebody wants to give it a go. I don't have that much time on my hands these days. ;_;

[JokerDKha]

After Edited file with Ohana3DS sun-moon, the file will not working after repack. Header like below: Edited: Original:

[Tyulis]

Making a 3DSkit module is certainly possible, but this require some investigation on the format first, I’ll try to give it a go today

[Tyulis]

The format seems fairly simple, I hacked something together that seems to work. ETC1 and ETC1A4 compression is not supported yet, but it might work with more standard formats like RGBA4 or RGB5551, could you please check ?

Conversion to PNG is as usual, to convert it back it’s with the PkmSMTexture format : 3DSkit.py -pf PkmSMTexture -o <output file> -Oformat=<texture format> image.png

The image file name is important as it is stored inside the file and presumably used to identify it in other models and scenes, so keep the filename given when 3DSkit extracts the file.

[JokerDKha]

Report more error big file GARC cant repack RGB5551 is not support and RGBA4 is not working. Im try repack with pk3DS Sample: https://drive.google.com/file/d/1rC3KI-TYiVoJdPa9d1X1_0uK6bMEIUFP/view?usp=sharing

[Tyulis]

It’s RGBA5551, not RGB, sorry for the typo I just fixed some regressions in the last updates, ensure you use the latest commit. Don’t forget the -d option when packing an archive, otherwise it won’t pack it properly, your error might be because of this.

If repacking in another texture format does not work I’m afraid I won’t have time to implement it any time soon, ETC1 compression is currently not supported and would be much more complicated to implement, and I don’t have free time for that at the moment.

[JokerDKha]

RGBA5551 still not working too Sample file ez_cmn_name_02_usa.zip .

[Tyulis]

I could successfully replace one of those ETC1A4 texture in RGBA4 format, so check that you used the right options, did not forget to remove your working files from the GARC directory before packing, did not inadvertantly renamed a file, …

For reference, the command to convert the texture back : 3DSkit.py -pf PkmSMTexture -o whatever\dec_3.bin -Oformat=RGBA4 whatever\ez_cmn_name_03_fra.png And to repack the GARC : 3DSkit.py -pdf GARC -o 7 -Oversion=6 whatever\7_

[IcySon55]

@Tyulis Regarding replacing textures with other pixel formats. I imagine that your script updated the format identifier in the header accordingly. However, RGBA4 likely produces a larger file and thus eats more VRAM while in-game. I've often seen this cause games to crash because their ram allowance is usually well used by the devs.

In short, I do not recommend changing the pixel format when modifying game graphics. Especially on low-spec hardware like most handhelds.

[JokerDKha]

@Tyulis it working so Fine now, but repack GARC is take so long maybe 30-45min. But thank's for your help, im will update soon if any error show in testing game.