Jump to content

Recommended Posts

Posted

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.

Posted
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.

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.

Posted

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.

Posted
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.

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.

Posted

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?

Posted

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.

Posted (edited)

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.

Edited by Made_s
Posted

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.

Posted
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.

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

Posted (edited)

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.

Edited by Made_s
Posted

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.

Posted (edited)

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 .

Edited by Made_s
Posted (edited)

Another thing, the stuff the first pointer in the main pointerlist points to looks very different in the overworld files.

*EDIT: I'm pretty sure the first pointer in the overworld files doesn't point to texture pointers.

*EDIT: Also reading the texture pointers of the Battle model files might be more complicated than I thought it would be...

SO I'll have to find a way to reliably read and stop after I read all the texture pointers (finding them is not so hard because they're all in the main pointer table, there might be irregularly many pointers between the texture pointer pointers though( I'm not sure)) and find out where the texture pointers are in the overworld files.

But I can't think of aything for the stop point right now, so I'll take a break till tomorrow, maybe you can think of something, this is what I tried : Link

Edited by Made_s
Posted
Another thing, the stuff the first pointer in the main pointerlist points to looks very different in the overworld files.

*EDIT: I'm pretty sure the first pointer in the overworld files doesn't point to texture pointers.

*EDIT: Also reading the texture pointers of the Battle model files might be more complicated than I thought it would be...

SO I'll have to find a way to reliably read and stop after I read all the texture pointers (finding them is not so hard because they're all in the main pointer table, there might be irregularly many pointers between the texture pointer pointers though( I'm not sure)) and find out where the texture pointers are in the overworld files.

But I can't think of aything for the stop point right now, so I'll take a break till tomorrow, maybe you can think of something, this is what I tried : Link

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

Posted

I wrote the part of the program that writes/reads to/from the files that are used/made by the wimgt program, so when we have a way to get the data we don't have to worry about that anymore.

Posted (edited)

Also, while looking through a Pokemon Colosseum Iso, I found out that Colosseum stores its music as midi files with the samples being stored like the sound effects, this means that the samples can be extracted by my sound effect extractor, the files are snd_music.samp and snd_music_sdir.fdat and the midi files are stored in bgm_archive.fsys, but it also means that you can't directly replace tracks like in xD, and I doubt you know how to do this with sequenced tracks like these.

These files are out of our reach to competently replace.

Technically the MusyX SDK is out there so you could replace it with other midi music you make in there but that requires professional knowledge.

Edited by Made_s
Posted

There are also some models that contain RGBA8 textures, but I'll just have to adjust the amount of bytes read per pixel.

I also (probably) confirmed ( not that it was hard, I was just lazy ) that the first pointer doesn't always poin to the first texture pointer, so the information on what the pointers in the main table point to is probably stored elsewhere (maybe even still in the file).

And I think several files have multiple texture lists.

Posted
There are also some models that contain RGBA8 textures, but I'll just have to adjust the amount of bytes read per pixel.

I also (probably) confirmed ( not that it was hard, I was just lazy ) that the first pointer doesn't always poin to the first texture pointer, so the information on what the pointers in the main table point to is probably stored elsewhere (maybe even still in the file).

That complicates things a little. The exact pointer has to be somewhere since the game knows how to handle it. Maybe there's a pointer to the pointer. In the ones where we know the first pointer points to the texture we can see if there's a pointer to that offset (factoring in the header).

Posted

I'll see if I can find something, I don't really see a reason for that info to be outside the file, but maybe there's some kind of table in a different file that has loading data like the number of textures for every Pokemon for some reason .

Posted
I'll see if I can find something, I don't really see a reason for that info to be outside the file, but maybe there's some kind of table in a different file that has loading data like the number of textures for every Pokemon for some reason .

Yeah that would be a pretty crappy design choice and quite problematic for us. It's unlikely they did anything that weird though so I'm hoping something convenient turns up.

Posted
So uh. I started with a shiny beldum, is that intended? Cause that was neat.

Yup, it's a copy of the oras shiny beldum event. It was actually meant to be shiny in previous versions but I made a slight error. It's now always shiny :)

Posted
Hi I am having a problem regarding patching the game. I am using NUPS as stated but when I try to patch i get "error opening file" message. Think anyone can help?

Does it mention which of the files it can't open? Is it the ISO or the patch?

Guest
This topic is now closed to further replies.
×
×
  • Create New...