RE: Texture Replacement coming?



1. The first 8 characters are the address. For example, 09a67ee0. Games may load different things into the same address, or reuse the address in other scenes. They may also load the same texture in a different address.



2. The next 8 characters are a clut and dimension hash. For most textures, this'll be static. In games that use palette swapping, it'll change for each color variation.



3. The final 8 characters are the data hash. This is based on the data the texture points to in memory. Sometimes there are bleeds, as LunaMoo is describing.



To make it clear, the PSP can only use textures of certain specific sizes. For example, 8x1, 8x2, 8x4, 8x8, and so on. It's not possible to create a 8x3 texture, even if you want one. So games use a larger texture, and when drawing, only draw with part of it.



Here's a visual example:

Code:

+---------+

| X X |

|X X X X X|

| X X | <-- actual height is 3, but 3 is not supported.

|ASDJASDHS| <-- row 4 isn't used, but it's part of the texture.

+---------+

Because a single texture can be (and usually is) drawn multiple times, we can't always tell that this part is unused (or we could, but everything would get a whole lot slower.) So we're forced to consider it part of the texture.



Another syntax in the ini (WARNING: loaded gun that you can point at your foot) is this:



Code:

[hashes]

09a67ee09dc425ed = 09a67ee09dc425ed.png

If you're absolutely sure the texture never ever ever changes, and the address/clut are never ever ever used by a different texture, you can use the above to map the address/cluthash to a single file.



The main reason for that syntax is actually to be able to ignore frequently-changing textures (e.g. sometimes games draw text or video content.) You can use this to ignore:



Code:

[hashes]

09a67ee09dc425ed =

This also works for full (24 character) hashes. SaveNewTextures will ignore these and not save them.



I'm planning to add a way to map just the data hash (or maybe clut + data hash) to a file... not sure what to call it in the ini. Would probably put it under a new section, like "[datahashes]"? Hm. Sounds weird, don't like it...



-[Unknown] Just to note, the filename is made up of three things, which is also how PPSSPP sees textures:1. The first 8 characters are the address. For example, 09a67ee0. Games may load different things into the same address, or reuse the address in other scenes. They may also load the same texture in a different address.2. The next 8 characters are a clut and dimension hash. For most textures, this'll be static. In games that use palette swapping, it'll change for each color variation.3. The final 8 characters are the data hash. This is based on the data the texture points to in memory. Sometimes there are bleeds, as LunaMoo is describing.To make it clear, the PSP can only use textures of certain specific sizes. For example, 8x1, 8x2, 8x4, 8x8, and so on. It's not possible to create a 8x3 texture, even if you want one. So games use a larger texture, and when drawing, only draw with part of it.Here's a visual example:Because a single texture can be (and usually is) drawn multiple times, we can't always tell that this part is unused (or we could, but everything would get a whole lot slower.) So we're forced to consider it part of the texture.Another syntax in the ini (WARNING: loaded gun that you can point at your foot) is this:If you're absolutely sure the texture never ever ever changes, and the address/clut are never ever ever used by a different texture, you can use the above to map the address/cluthash to a single file.The main reason for that syntax is actually to be able to ignore frequently-changing textures (e.g. sometimes games draw text or video content.) You can use this to ignore:This also works for full (24 character) hashes. SaveNewTextures will ignore these and not save them.I'm planning to add a way to map just the data hash (or maybe clut + data hash) to a file... not sure what to call it in the ini. Would probably put it under a new section, like "[datahashes]"? Hm. Sounds weird, don't like it...-[Unknown]