kion-dgl / Dash2-Toolkit

Save State Viewer for Mega Man Legends 2 for the PSX
http://mml2.dashgl.org/
1 stars 0 forks source link

Create Title Screen Logo for Miku #12

Open kion-dgl opened 10 months ago

kion-dgl commented 10 months ago

image

Pallet Size: 0x100 count(1) Image Offset: 0x5a78 Image Length: 0x1a400 Width: 0x1e0 Height 0xe0

We can probably use this to test.

title-rgb

kion-dgl commented 10 months ago

In terms of logging the file, this is the only one that looks like it makes sense.

image

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.

kion-dgl commented 10 months ago

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.

kion-dgl commented 10 months ago

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:

  1. 0x5800
  2. 0x7800
  3. 0xb000
  4. 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.

kion-dgl commented 10 months ago

Looks like the first image encodes okay, but everything after that is broken.

image

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?

kion-dgl commented 10 months ago

First check, moving things to the end of the file does this:

image

Next check is going to be to see if I can just encode the entire image and jam it in there?

kion-dgl commented 10 months ago

Trying to replace the last of the four images does this.

image

I wonder if I could combine more into the first image.

kion-dgl commented 10 months ago

This happened when I tried to encode 120px in height of the image.

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: framebuffer(1)

And this is the results of our edits: framebuffer

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.

kion-dgl commented 10 months ago

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.