Open kion-dgl opened 10 months ago
In terms of logging the file, this is the only one that looks like it makes sense.
Image found at: 0x5800
{
type: 3,
fullSize: 0x8180,
paletteX: 0,
paletteY: 503,
colorCount: 256,
paletteCount: 1,
imageX: 640,
imageY: 256,
width: 272,
height: 60,
bitfieldSize: 424
}
What's weird is the width is 0x110 and the height is 0x3c. If there are 256 colors that means we have 2 bytes per pixel, which gives us 0x220 by 0x3c. This gives us a length of 0x7F80
.
I was hoping that the assets would be version agnostic, but that doesn't seem to be the case for the title. At least between the Japanese PC version and the US PSX version.
While I had wanted to try and add support for different versions as I go along, if the changes are breaking then I'm going to stick the priority of the US PSX version and then other issues can be made if people want to see more assets.
Image found at: 0x5800
Size: 0x8180
{
type: 3,
fullSize: 33152,
paletteX: 0,
paletteY: 503,
colorCount: 256,
paletteCount: 1,
imageX: 640,
imageY: 256,
width: 544,
height: 60,
bitfieldSize: 424
}
------- Image --------
Image found at: 0x7800
Size: 0x7f80
{
type: 3,
fullSize: 32640,
paletteX: 0,
paletteY: 503,
colorCount: 256,
paletteCount: 0,
imageX: 640,
imageY: 316,
width: 544,
height: 60,
bitfieldSize: 764
}
------- Image --------
Image found at: 0xb000
Size: 0x7f80
{
type: 3,
fullSize: 32640,
paletteX: 0,
paletteY: 503,
colorCount: 256,
paletteCount: 0,
imageX: 640,
imageY: 376,
width: 544,
height: 60,
bitfieldSize: 944
}
------- Image --------
Image found at: 0xf000
Size: 0x7f80
{
type: 3,
fullSize: 32640,
paletteX: 0,
paletteY: 503,
colorCount: 256,
paletteCount: 0,
imageX: 640,
imageY: 436,
width: 544,
height: 60,
bitfieldSize: 436
}
As far as the title screen for the PSX version goes, it looks like it's made of four smaller images of size 544 x 60. Making the whole image 544 x 240.
The way it works is the first image has the first slice of the image with the 256 color palette, followed by the other three image slices with no palette defined.
In terms of approach for encoding, this probably means that we need to have one 544 x 240 image.
First we get the palette of 256 colors. Then we encode the entire image with the palette. This will then get cut up into four parts. We glue the palette onto the first part and compress it. And then compress each one of the remaining images.
We then write headers for each one of these and put them back in the file where they are expected. For reference, the files are at the following offsets:
0x5800
0x7800
0xb000
0xf000
Width the following image being at offset 0x11000
. I think we can slice from 0 to 0x5800. And then from 0x11000 to the end of the file. That gives us a length of 0xB800 to encode the file.
The easiest approach might just be to cut the title out of the middle and then stack the title onto the end. We can go back and do a sanity check to see if that works normally if and when things explode.
Looks like the first image encodes okay, but everything after that is broken.
I'm going to need to go back and break this file down a little more. First question is can I move the title to the end of the file without things breaking?
First check, moving things to the end of the file does this:
Next check is going to be to see if I can just encode the entire image and jam it in there?
Trying to replace the last of the four images does this.
I wonder if I could combine more into the first image.
This happened when I tried to encode 120px in height of the image.
What's telling is that we get a similar result to changing around the order. Let's use the framebuffer to try and debug what's going on here.
This is what the title screen is supposed to look like:
And this is the results of our edits:
What it basically looks like is the clouds from before the title are still there. I'm trying to think to what degree we can cheat on this. We have the framebuffer to debug what is going on. We could try an uncompressed version of the file and see what that does.
Trying to include the title decompressed just resulted in a crash. Encoding the first part of the image works, but trying to follow that doesn't work.
The compression aspect of this provides a lot of guess work over being able to just encode the image. This seems like something where I might want to do a sanity check on the PC version first.
Pallet Size: 0x100 count(1) Image Offset: 0x5a78 Image Length: 0x1a400 Width: 0x1e0 Height 0xe0
We can probably use this to test.