Texture import Mipmaps broken

[JimScript]

I don't know if anyone figured out a workaround for the messed up textures yet, but I found that for the most part only the first mip of these textures are actually broken, base texture and mips beyond 1 seem to work just fine.

Edit: I made a custom texture 512 and it caused mip 2 to repeat its top half over its bottom half, and 1024 causes it to quadruple up instead(before crashing the emulator with a texture too big for the PS2 to handle that is), so both of which each loop the pixels after every 64th pixel row.

[chaoticgd]

There's no fix currently, the texture packer is just broken.

[JimScript]

Ah, I should have figured, but I can't help but wonder how the Horizon's Forge does it correctly(if it doesn't just skip the mips all together as a workaround that is) since their packer isn't open source yet.

[chaoticgd]

I don't know too much about Forge, you'll have to ask Dan/Badger about that. I think their Discord has a public invite link.

[JimScript]

Maybe the texture unpacker/packer could export/import mipmaps as well as with their base textures as to avoid the packer needing to (re)generate the mipmaps on packing, have it use either multiple PNGs or a single uncompressed DDS file to store the mipmaps for the packer to put in, and then have the mipmap generator be a falllback for if it doesn't detect any user input mipmaps.

[chaoticgd]

Maybe the texture unpacker/packer could export/import mipmaps as well as with their base textures as to avoid the packer needing to (re)generate the mipmaps on packing, have it use either multiple PNGs or a single uncompressed DDS file to store the mipmaps for the packer to put in, and then have the mipmap generator be a falllback for if it doesn't detect any user input mipmaps.

Generating the mipmaps isn't the problem, the problem is packing them correctly so that the game can setup the GS to draw them properly.

[JimScript]

Yeah, I did a bit of testing right now and I found that Mip1 doesn't seem to actually save any indexing for the palette, it seems to just take garbage from the vram and then use the texture's palette to display. I'm sorry if I'm not finding anything you didn't already know.

[JimScript]

I've noticed that it isn't just any garbage from the vram, it's the next texture data from the shared level texture pool right after the first one. Meaning that if the next texture in line was miraculously just like the mip1 of the one before it, then it would look just fine. So there is a workaround of sorts by making second smaller textures right after the main ones, and I guess that means there was a way to import custom mipmaps after all. But that's not an ideal workaround, as not only does it fill up the memory with unnecessary data, but it also means that it's a nonviable fix for objects that aren't shrubs and have multiple textures as redefining texture orders is not yet available for anything else.

So now I guess I'm trying to figure out how the packer moves mip2 independent from mip0 and mip1, and if there was a way to move mip1 by itself then this could be fixed. Or the mipmaps could just be mapped sequentially right after the texture instead, but that seems it could get messy fast trying to figure out the spacing between textures.