Emulator Issues #11358
closed
Custom Texture: C8 texture tlut hash can cause duplicate dumps
0%
Description
As the title says. The issue does not affect every single C8 (or "_9") texture, only a select few. I am not sure if the issue can also affect "_8" and "_10" textures. Confirmed to happen in Zelda: Wind Waker and Zelda: Twilight Princess, possibly other games. The texture hash is always the same for duplicate textures, it's the tlut hash that has the potential to change.
tex1_48x51_53403146169829a2_45604eac43c6fd37_9
tex1_48x51_53403146169829a2_00bdbbec7bd28d9d_9
tex1_48x51_53403146169829a2_51202438fd7443e1_9
tex1_48x51_53403146169829a2_b85163ac8b4598d4_9
...and so on 100s-1000s of times.
It's odd because plenty of other "_9" textures do not have duplicate dumps, the compass and the map for example, are the same format as the boss key.
An example from Wind Waker. So far I have found 934 duplicate dumps and I have 3 dungeons to go.
A potential solution mentioned on that thread (by emu82) is the ability to provide a wildcard for the second hash.
For example, naming a custom texture tex1_48x51_53403146169829a2_$$$$$$$$$$$$$$$$_9 could load any hash in the place of the $ sign, which would make it compatible with every example listed above. Even a single wildcard identifier may be sufficient (like tex1_dim_hash_$_9).
As far as I've seen, no texture with duplicates has shared a (first) hash with another texture. Not saying it isn't possible, but the potential for failure for having a wildcard is most likely really low.
Files
Updated by Techjar over 6 years ago
I don't think we should be getting 934 different variants of the same texture, especially since it only happens with specific textures. Something is not right here. I know it's not supposed to affect texture dumping, but can you see what happens if you use safe texture cache?
Updated by AdmiralCurtiss over 6 years ago
Not that it wouldn't be interesting to figure out why the tlut (texture lookup table?) can differ across multiple instances of the same texture, but there does already appear to be support for using wildcards for this:
// try to match a wildcard template
if (!dump && s_textureMap.find(basename + "_*" + formatname) != s_textureMap.end())
return basename + "_*" + formatname;
...but unfortunately, the wildcard character is *, which is illegal in filenames on Windows, haha.
Updated by Bighead.0 over 6 years ago
Techjar wrote:
I don't think we should be getting 934 different variants of the same texture, especially since it only happens with specific textures. Something is not right here. I know it's not supposed to affect texture dumping, but can you see what happens if you use safe texture cache?
Texture cache accuracy does not seem to have any effect, the dumped hashes are still many and the same instances appear in all accuracy settings. Each dungeon has its own "set" of key textures that can dump (usually around 200+ common ones), then some rare ones can be found by opening the map, or restarting the game, or just plain running around for awhile.
Updated by emu82 over 6 years ago
I wondered whether there was already a wildcard character in existance, but having a * is pretty useless under Windows, yeah. So it would be a matter of simply changing that character to a more compatible one, which can be used by any Texture Pack that artists want to distribute (under any OS).
Several of the items in Twilight Princess are confirmed affected (at least Slingshot, Hawkeye Mask, Morning Star), though I haven't gone through all items yet, so there may be more.
Updated by Techjar over 6 years ago
I have fixed the character problem with the existing wildcard support: https://github.com/dolphin-emu/dolphin/pull/7349
My suspicion is that the game may be putting random garbage into parts of the TLUT, resulting in every instance having a different hash. Someone probably already came across this issue years ago and implemented the wildcard to work around it, although I guess they forgot about asterisk being an illegal character in file names on Windows.
Updated by emu82 over 6 years ago
I'll test it when the next Master developer version is released, because I don't know how to compile a version myself.
Updated by emu82 over 6 years ago
Nevermind, I just saw Bighead has already posted a test build link for me.
Updated by emu82 over 6 years ago
Issue seems to be solved, the newly introduced $ wildcard is confirmed fixing the issue for Twilight Princess.
Updated by JosJuice over 6 years ago
- Status changed from New to Fixed
- Fixed in set to 5.0-8619
The wildcard character was changed to $ in https://dolphin-emu.org/download/dev/74cbc6cde0816c9abcd436c03e6d7fb4587ccaf3/
Updated by eleriaqueen about 6 years ago
- File hashes.jpg hashes.jpg added
Hi, I have an issue that could be similar, I'm not really sure. When dumping textures from PSO Ep. I&II I end up having a lot of textures that are variants of one single bitmap-font-kinda file each missing one or two symbols in the texture. They end up having different first hash but exactly the same second hash.
I tried using a wildcard character as first hash but it didn't work.
Updated by JosJuice about 6 years ago
That isn't really something that we can fix.