VideoCommon: enhance wildcard support in hi res texture lookup

[iwubcode]

Splits out the texture hash from the rest of the texture name generation, so that it can be "wildcard"'d out of the texture name.

Additionally, have exact texture matches take precedent over wildcard matches. This is technically a breaking change in that it could effect existing texture packs if they had both a wildcard and an exact match texture in the pack. However, I imagine most packs aren't doing this because it'd be wasted space.

Should resolve 12505

[GhostlyDark]

Does exactly what I requested, the wildcards do load. I tested both wildcarding the first hash as well as textures wildcarded by the second hash. Non-wildcarded textures have priority, which is also correct.

Regression: Single hash HD textures aren't working right now. They are loaded into RAM, but aren't displayed and vanilla textures are seen instead.

[iwubcode]

@GhostlyDark - I believe I've fixed that issue but we're seeing issues with our windows builder (not related to this change). Not sure what OS you are running but if it's windows, I can ping you again once the builder issue is fixed.

[GhostlyDark]

Yup, using Windows. I'll check every now and then to see if the new build pops up.

[iwubcode]

@GhostlyDark - the builder issue was fixed. Please retest when you have time!

[GhostlyDark]

Works fine now.

I took a look at the code and noticed that there's also a way now to "double wildcard" textures. I'm not sure if it is any useful to texture artists and it sounds "dangerous" enabling somebody to do so as it would replace all textures with two hashes.

[BigheadSMZ]

Anything holding this back? Tested it with a few games and nothing seems to be broken. Along with everything else mentioned, this change allows the door textures in the Resident Evil 2 pack to load in mainline Dolphin without needing a custom version. There are probably other games that could potentially benefit from this as well.
https://forums.dolphin-emu.org/Thread-resident-evil-2-resident-evil-3-seamless-hd-project

[JMC47]

can we wait until after the next beta? we're having some issues with regressions and I don't wanna merge anything else right now. after the progress report @ me here and I can merge it.

[BigheadSMZ]

Okay thank you, sounds good. In the meantime, I'll test out a few more packs to make sure there isn't anything I missed.

I do have a quick question for @iwubcode on how one facet of this is supposed to work. Since this allows matching a single hash for paletted textures by omitting the wildcard or one of the hashes (texture or tlut), does that apply to both hashes? For example, lets use this texture name...

tex1_48x51_53403146169829a2_0bac239202d52920_9.dds

My question is, are all of the names below now valid names and the texture should load? Does this change mean we only have to ever match one of the hashes?

tex1_48x51_53403146169829a2_$.dds
tex1_48x51_$_0bac239202d52920_9.dds
tex1_48x51_53403146169829a2_9.dds
tex1_48x51_0bac239202d52920_9.dds

[iwubcode]

My question is, are all of the names below now valid names and the texture should load? Does this change mean we only have to ever match one of the hashes?

Let me go through your example:

"tex1_48x51_53403146169829a2_$.dds" - invalid. Missing the format number at the end. If the format is added, it is valid.
"tex1_48x51_$_0bac239202d52920_9.dds" - valid. Will match if there's not an exact texture match with a given texture hash.
"tex1_48x51_53403146169829a2_9.dds" - may be valid if there is a texture with that texture hash that doesn't have a tlut address. For your example though, this wouldn't match anything.
"tex1_48x51_0bac239202d52920_9.dds" - invalid. Not possible to have a tlut without a texture hash.

Since this allows matching a single hash for paletted textures by omitting the wildcard or one of the hashes (texture or tlut), does that apply to both hashes?

Not sure what you mean by this. Basically what this PR does is two things:

• Allows you to hash out the texture hash, just like you can with the tlut hash today.
• Makes exact matches take precedent over hashed textures.

So if you had

tex1_48x51_53403146169829a2_0bac239202d52920_9.dds

All these in the texture pack would work (in priority order):

• tex1_48x51_53403146169829a2_0bac239202d52920_9.dds - if this exists, it would take precedent as an exact match.
• tex1_48x51_53403146169829a2_$_9.dds - wildcarded out the tlut hash
• tex1_48x51_$_0bac239202d52920_9.dds - wildcarded out the texture hash

Hope that makes sense!

[BigheadSMZ]

Thank you that clears up my confusion, it's initially how I thought it worked but managed to over think and over complicate it. GhostlyDark also tried to explain it to me as well and I think I was misinterpreting the part about loading exact hashes. Aside from that, this will be really useful for some games so thank you for this PR. I've tested a number of packs so far and I'll keep my eyes out until after the progress report.

[iwubcode]

@BigheadSMZ - have you had time to do additional testing on this, do you think it's ready?

[BigheadSMZ]

I tested 13 different texture packs and couldn't find any issues, so it seems like it's good to go.

[iwubcode]

@JMC47 - ?