Add alwaysRecalculateTextureHashes option for games that dynamically update/override existing textures

[xoxor4d]

This PR adds a new option called Always Recalculate Hashes under the Game Setup - Textures Tab.

This new option can help in games that dynamically update/override existing textures. Remix normally does not update the hash after texture creation which can lead to issues with texture replacements or texture tagging.

The most severe issue I had was a texture tagged as UI that was switched out with a texture used on a mesh after playing the game for a bit and remix kept the hash of the original UI texture. One can imagine the result.

That was very rare. Most of the time it resulted in this:

hash_issue01.mp4

GTA San Andreas - Hemry (Discord May 2025)

I found some weird behavior, the albedo texture changes when viewing with the in-game camera, but when using the Remix Debug Camera, it doesn't happen. What's stranger is that the albedo texture changes that is without any texture replacement being applied, while the normal map still correctly uses the material replacement texture.

hash_issue02.mp4

Hemry tested this fix on GTA SA and reported the hash issue (switching textures) being fixed.

NFS Underground 2 - Hemry

He also tested the fix here:

I did a quick test in NFSU2: previously, changing the car color didn’t affect the texture hash, it kept using the same one.
But with the hash fix build, switching cars now generates a different hash, and it even flushes unused textures automatically.

Previously, we didn’t have stable hashes for car paint or vehicle meshes, the texture hash would change randomly. The only stable one was Rachael’s Z350 meshhash. But now, with this fix, it looks like some beginner cars can be replaced properly, as long as the player doesn’t manually change the color or decals.
Definitely a big improvement.

Other games/projects:

It both fixes issues with tagging textures within Remix and also has made material replacements possible!
Project64: https://discord.com/channels/1028444667789967381/1236261405909581896/1426800263557025903

[MarkEHenderson]

Have you done any perf testing in CPU bound scenarios? I'm not sure how often FlushImage, UpdateTexture, and UpdateSurface get called, but if it's frequent then this may introduce pretty considerable overhead.

I'd recommend trying to just watch the FPS counters in dxvk.hud with it on and off, see if there's any difference. If there is, it may warrant further profiling / optimization.

The ScopedCpuProfileZone() at the top of the function means that Tracy should be able to pick up its uses easily, so if you just follow the instructions here then take a profile while you're in a game that needs this, it should give you a lot of good info.

[xoxor4d]

Have you done any perf testing in CPU bound scenarios? I'm not sure how often FlushImage, UpdateTexture, and UpdateSurface get called, but if it's frequent then this may introduce pretty considerable overhead.

Couldn't really tell a difference with it on and off but I'll do some actual performance tests and report my findings 👍

[xoxor4d]

@MarkEHenderson I couldn't spot any differences in performance when cpu bound with it on/off. I've made a trace with it on and scoped a frame with pretty high cpu usage. Never used tracy before so not sure if what I did is correct:

The only downside I've noticed with this commit would be the jumping imgui texture list