Made_s

Ok, the conversion script works, which means C8 to PNG and PNG to C8 can be done now with the wimgt program. The model files also contain C4 files, for which I I'll have to write something too, shouldn't be too difficult, it's pretty much the same thing with minor differences that don't affect the palette format. *EDIT: actually I can just run the same script over it .

Conversion via tool to png now works correctly and it seems that the data differs because the data from the model file is RGB5A3 and the data that is converted from the PNG(that is in turn converted from the original data) is in RGB565. The good thing is that (at least for this file) the conversion seems to have reduced the palette size. I'll just write a check into the program that tells you when the palette is too large and I'll shift the green channel to fit the alpha. The documentation tells me that all data in the files is big endian, but TiledGGd only displays the palette data correctly if it's set to small endian(the indexes are still big endian), something strange is going on there.

The native conversion doesn't work for files with alpha channels though, it only takes RGB for bmp files, so that might be a problem if some of the models contain alpha. *EDIT: do you know the endianess of the .bmp data ? *EDIT: I was now able to make the data into a file the conversion program could read(It doesn't get the palette right, I think it reads the palette as big endian even though it's small ) the problem is that converting C8 to png and back changes color values, at least with the program I used ( which is a bit strange since PNG is upposedly lossless compression, it's probably because PNG doesn't support RGB lower than 24 bit). This means that pretty much every color will look a little different. The best way to edit the files would be to edit the file in the palette format and never even convert it to png in the first place. This would make it less user friendly as you're restricted to a few programs that can edit that format ( I don't know of a proper tile editor that can is the problem) but it would make edits look a lot better and would solve the palette problem. So far I could only get it to display the palette correctly in FileGGD Image Link and could only get the index data read correctly by the conversion tool Image Link. couldn't get both to work in either. I could just change the endianness of the palette in a program but tat still wouldn't change much about the rest.

I could compare the png files the libarary gave you to the ones the other program creates if you send me one. I could also probably directly write them in the format you have if they're different. *EDIT: Apparantly java supports png to bmp and bmp to png natively which will probably save me a lot of trouble.

Ok, I'll see what I can do for now, I'll write the raw data extraction and worry about all the conversion stuff when that's done. *EDIT : I'll also have to do a bit of research about binary manipulation in java first since these files get quite large and using Strings would be *really* slow.

Did the colors work correctly? Because as far as I know most bitmaps save colors as ARGB8888 unlike C8 which uses RGB565 (or similar). Or can you specify which colr space you use with that library?

If you know how to reduce palette sizes of exisiting Palette based files it could work, I'd just need code to convert to and from png. maybe I can think of a way for the CMPR files but your code for conversion of png to palette based could be useful even if it is Mac only, I could probably still rewrite it into java.

For it to work I'd have to put all in one format (probably png) and that wouldn't solve any of the present problems like Palette size limitations. It would also mean I'd have to save location of the files, thier type and other needed data seperately. I don't really see how that simplifies anything.

So if you already have that, waht should the program be able to do? I haven't written anything yet because it's been a bit unclear what you want it to do.

The nintendo logo looks like CMPR to me. ¯\_(ツ)_/¯ So how exactly did you edit those uv files ? did you use something to convert them ?

Sounds like C4 and C8, could you give me the name/location of one of those files ?

What format were those images in ? Yes, I mostly figured it out by watching how different file's headers differ in combination with the gamecube file codumentation. The problem is it still throw errors occasionally and I'm trying to find out why.

How did you import the textures before ? Also the header I'm talking about is the one I need for the program to cnvert it to png so you can edit it.

Images (I forgot to color the type in the selected area pink) The lime green part in picture 1 points to the black part in Picture 2 and the blue value in Picture 2 points to the yellow part ( which is just the start of the data after that 0x20 long line). I think this is the Palette data for C8 (and possibly other Palette formats) since only the texture with the format ( the pink sections in Picture 1) of 0x09 ( which is for C8) have this pointer and the CMPR (CMPR doesn't use external palettes ) ones (the one with 0x0E for type) have 0x00000000 at that part. Inserting Palette based formats might be a problem since the palette size probably varies with the picture you want to insert, which would require a whole lot of pointer editing at multiple places. I wasn't able to make a C8 file out of C8 data yet, mostly because there seem to be issues with the header I haven't figured out yet (the header in the file I'm making not the ones in the data). If I get this to work I should be able to extract those and CMPR files. Also do you know of any Hex Editor that can highlicht areas of code ? Like the style options in Notepad++. It would making these notes a lot easier and prettier.

These sections seperating the texture pointers contain their own offset which is pretty dumb unless a pointer points to that value for some reason instead of just pointing directly to the offset.

Thanks, with this I can probably write something that extracts the textures into a format that can be converted by the szs tool. I already wrote something very similar to this for the sound effect extraction/insertion. If there are only CMPR and C8 textures, the type can easily be determined by dividing the length of the file ( which is just the difference between offsets of following pointers ( the file I'm using right now definitely has all pointers in order, if that isn't the case in every file I'll have to write something that sorts them)) by the pixel count, since CMPR has 4 bits per pixel and C8 1 byte per pixel. Do you know whether the texture data is all in one block? If not so then getting the length might be a bit more complicated. About finding a stop for the texture table, the end contains two of the 0x2C long sections that are between the texture poitners, so we could just let the program check whether the an entry starts with the start of one of those sections.

I just found some info on the palettes and header if you do manage to find them Link

The CMPR data is really easy to recognize, they mostly look like the examples I gave you.

So far (since yesterday) I found out that most of the textures contained in model files are compressed CMPR files with only a few uncompressed C8 files ( somewhat documented here Image_Formats ). There is a program that can convert .png images to CMPR here which you can use with the commands listed here . Since the files don't contain any header data for textures (that I know of) I'm trying to use a different solution and will try to write a program which can search for the texture in the file by using a CMPR version of the original texture you can get through Dolphin which you'll have to provide. It replaces that section with the custom CMPR file you provide. The searching is a bit more complicated than just searching for the exact data though, because the program to convert to CMPR doesn't give the exact same data, because there is not *one* algorithm for compressing to CMPR. Even though the colors are changed, most pixel indexes keep the same patterns, even when values are replaced with other ones, so if you know about pattern searches with ubstituted patterns that could help me, if not I'll continue to try to come up with one myself , I have somewhat of a lead of how I could write that. Example comparison between CMPR images ( one raw data from model file , the other converted image from Dolphin): The last 4 bytes of each 8 byte section are the pixel indexes with 2 bits per pixel selecting one of 4 colors generated by the first 4 bytes, each 32 bytes are one block and so on (see documentation)(excluding the first 64 bytes of the file which is a header exclusive to the converted file which I added to the Raw file for conversion to .png to compare and see whether these are even matching files): Link There may also be a third image format in the files like RGB565,RGB5A3 or RGBA32 (or something else since I don't know whether it even fits any of those ) since there are large areas with uncompressed texture data that are very large but result in a small image ( example is tha back texture of Salamence I showed earler , which I thought was a shader, but was just a really small texture), which doesn't fit C 8 and CMPR. I wouldn't know how to edit the C8 files though, since those are color palette formats and I didn't see any palettes in the file before the data chunks. The search script would first search for CMPR sections with the same length as the Dolphin texture and then compute a value of how similar the patterns of the sections are and then take the one with the highest value. There may be another way of doing this, finding all the textures and numbering them , extracting them, then reinserting them by running the numbering script again and inserting it at a specific number. (This is probably the easiest way ) None of the textures in the files have Magic Bytes so even the second option would need some kind of patterns search. (Sorry for how all-over-the-place this is) ( Also, does the Music Tool work for you ? )

Yeah, the compression code is what I don't have, I can only write a bit of Java.

Yes, it took me a lot of time recompressing and inserting it everytime... what are you using to automate it ?

When working with models and things that probably don't completely break the game when broken, a good way to figure stuff out is to corrupt them at certain interesting points and see what changes, this is how I figured out the location of the coordinate data and that it's stored as floating point, which then led me to it being wavefront data.

The start of the coordinate data is easy, it's always 0xE80 , the hard part is the end of the data, which is why I've only done it manually so far but that will prbably be changed. The sound files are easy because they have easy to spot patterns. The textures... I'll have to see how I'll do that, like I said I'm still figuring this out. I posted this here because one of the people in the group I'm workin gin told me to post this on a forum somewhere for other people to use and you were the first that came to mind.

That's really easy using Dolphin's Dump Textures option, Google it to find out how it works. But I also know they're easy to find in the files themselves since they're saved there uncompressed (in the .fdat files at least), I'll probably write another program for that if you want since I'm currently further looking into the model file structure. The model files probably also contain shaders in a simmilar form as This happened when I first tried editing a texture You can also definitely Gardevoirs Head, I already did as a test, just in a different way Link

I also somewhat know know how to edit models, while I can't export/import complete models, I can extract the coordinate data of the points used in the model, save them as an .obj file, edit that in blender (only moving the points' position) , reconvert that to hex and then add it back in (as long as the compressed file doesn't get too big, which is pretty random). This makes size edits and transforming edits to existing models possible, though you probably can't do much with that.