StarsMmd

This was a lot of fun to read through. It's clear you put a lot of time into it! We actually made a lot of similar decisions with things like pokespots and bonsly. It's interesting that you put both larvitar and tyranitar in. I had them both at the same points in the game in previous versions for the exact same reasons you did but it was probably the most complained about thing by players so I changed it in the end. The huge number of shadow pokemon on citadark isle is pretty troublesome though. I'm actually aiming to reduce the number in the next update of XG. Also I feel like a lot of the pokemon in the early game are quite underwhelming, especially a few of the admins' shadow pokemon. A lot of really popular pokemon are left until citadark by which point it's often too late to use them and with XG's really poor postgame they don't get much screen time. On the bright side it does mean that there's more of an incentive to try out new things which is fun too! A lot of really cool ideas! I hope you enjoy XG Your steelix stats look really broken btw !

Looks like you've put a lot of work in. I'll take another look and see if anything stands out.

Cool, I'll send some examples when I get home. ??

The library gave me 32 bit rgba with 8bits per channel. I'm not sure if that's how png stores the data or if the library converted it to that format. I divided the values to get the required format which was 5 bits per rgb and 1 bit alpha channel.

I'll upload my source code on github later. I used an iOS library to convert the png to the raw pixels as a bitmap. I started with an empty palette and for each pixel, if it's colour was in the palette I would use that as the index. If it was a new colour then I just add that colour to the palette. When the palette was full I would stop adding colours and give an error message. I don't know too much about the png format but if you can at least find a method of converting it to a bitmap then the rest is really straightforward.

Yeah I thought as much. If it was all in the same format it could have been feasible. I guess the best course of action is to have something that takes a model file, locates the textures, extracts them as pngs and then has the option to replace the textures if the new texture has a palette that fits. Using the same palette size as the original isn't too difficult usually.

It would be useful to have a program that can extract the textures from models and to replace them directly in the model files with an edited png. I was wondering how feasible it would be to just dump one large image from the models that contains all the textures in one. It could be easier to extract and reimport that way.

yeah there's this program called Tiledggd that is good for displaying these kinds of files. You feed it the starting offset of the image data (so after the header which is usually 0x80 in these). You set the image width and height, the start offset for the palette if there is one, the bits per pixel, the rgb order, whether or not there is an alpha channel, whether the data is tiled and if so the width and height of each block. For now I've just been getting this information by inspecting the hex with a hex editor. Once all the settings are done correctly you will be able to see the image in the program and there's an option to export it as png and I think you can also export to another format but I can't remember for sure. Tiledggd doesn't have any support for converting backwards from a png back to the original format so I had to write that code myself.

Yes it is and the game allows for up to 128 shadow pokemon.

umm, for example in fight_common.fsys there is "uv_icn_type_big_00". I think there are a lot of them that start with "uv". The data is really easy to recognise by eye and you can find it in a lot of other places. common.fsys and field_common.fsys have some. nintendo_logo.fsys has one too but I was never quite able to decode that one. You find a lot of them in the .fsys files for menus too. Also all the files in poke_body, poke_face and poke_dance are textures for the box sprites, mugshots and purify chamber animated sprites respectively.

From what I heard it's pretty standard. They have a header which starts with the width and height in pixels, then the bits per pixel. They were typically 8 or 16 bit indexes into a palette at the end of the file which was 0x100/0x200 bytes long I think. I did see a lot of other files with different formats though. Oh also the pixels were divided into 8x8 or 8x4 blocks.

I edited textures that were in a different format. Not the textures from models though. It's things like the title logo adding a fairy type icon. I see. The header the program expects would be different from the ones in the model files. Do you know what they should look like?

It looks like you've made a lot of progress. I think it would be better to just force the image to use the same number of colours as (or fewer than) the original image. When I was replacing other texture files from the game with pngs I'd edited, if I accidentally used more than the 200byte palette from the original then I'd display an error. Also, I would import the new image back into the original file, keeping the header from the original. It might be easier to do it that way for now. I don't use any particularly exciting hex editors unfortunately. I actually annotated very similar images to that on some of my posts somewhere on this forum .

I look forward to seeing the results. I'd love to hear some of the stat changes you would propose too! Yes it's very simple to change the trade evolutions.

Yeah I noticed that as well. Have no idea why it's there. I hope we can figure out what the rest of the data is. It will probably make the extraction and insertion process a lot easier.

That's good to hear and I'm really happy I was able to help ?? I'm pretty sure the headers should store the dimensions of the texture and maybe even whether or not it's c8 or cmpr

Alright, here's what I've found so far. So there a few small differences between the model files depending on whether they are in battle models or overworld models, etc. The one's you're referring to, where the coordinate data starts at 0xE80 are the pkx ones I believe. These are the in battle models. The model data starts at 0xE60 in these files (with the header). In files with the overworld models (usually found in the .fsys files for maps) the model data's header starts at 0x00. The header is 0x20 bytes long. The first 4 bytes in the header are the file size of the model including the header. The next 4 bytes are a pointer to a list of pointers. This pointer's offset is relative to the end of the header (i.e. from 0xE80 in pkx or 0x20 in overworld models). Each of the pointers in that list is also relative to the end of the header. The next 4 bytes is the number of pointers there are. From what I've seen, the first pointer in the list points to a list of texture headers. The first 4 bytes being the offset of the header followed by what I presume to be the width and height? Each header appears to be 0x74 bytes long. I don't think there are any other reliable pointers to each of the individual headers so we may have to just add 0x74 bytes to the offset each time. I also haven't found a value to determine the number of texture files yet. Also the headers aren't necessarily in the same order that the actual data is in.

Sweet, I'm going to fire up my laptops now and take a look.

Thanks for all the information. I'll look into too and see if I can spot anything. Ideally we'd be able to find some kind of header or table somewhere. Once I'm able to recognise the cmpr data it should be possible. I'll have to take some time to get up to speed but will get back to you. I ran the program just to have a look and it all looks fine but I haven't actually used it yet just because I've been busy. Will potentially give it a go tonight though.

I think this is the code I used lzss.c. I was able to use it directly in swift but don't know if you know a way to use c code in java. The lzss algorithm is really well documented though and the fsys files use the typical, standard, usual compression. Maybe you can find a library somewhere online or attempt to translate it since c and java have really similar syntax.

I wrote some code in swift. Swift is still mac only though so it's not been very portable so far. It's nothing too complicated though. I found some c code for lzss compression which I just use directly for compression. The .fsys format is pretty straight forward so putting the compressed files back in is simple. You just look up the offset to place it at. Then I use the .toc file from the ISO to look up the offset of the .fsys file in the game and put it back in.

That's true, I did read an article a few years back about corrupting data in NES games or something. I've usually been doing things safely and only changing things when I can predict the results. The main reason being it took me so long to rebuild the ISO and load it up each time I wanted to test things. I've finally got code to automate everything now though so it could be a good way to go forward in some areas.

Thaat's really appreciated. Yeah when I started working on the games I really wanted to post it on a forum too. It helps to record things for later and I even ended up getting a lot of help from some really talented people . I look forward to seeing the results of your work. Do let me know if there's anything I can help with.

Yeah I've used the dolphin one before but I was hoping to change the files directly so I can make the changes viewable even on other emulators like nintendon't. It's awesome that you've figured out so much though. I was really hoping someone would come along and figure this stuff out as I'm a total noob. I've been staring at the hex for years now and still only managed to pick up on very basic patterns. A program for extracting and reimporting textures would be incredible if it's not too much trouble. I'd be curious to learn the method you use to locate them within the file. I wasn't able to pinpoint an offset table or pointers myself.

That's really cool! It's definitely a start and gives a lot more hope that the full thing will be possible soon. Maybe it would be possible to decrease Gardevoir's huge head for now . It's model in is pretty funny. You wouldn't happen to know how extract the textures from the models would you? It's something I thought would be really easy but haven't found anything substantial yet.