[HD] Turok 3: Cerebral Bore UI texture bug

[GhostlyDark]

The red, center parts of the Cerebral Bore crosshair are supposed to dump as 4 textures. When dumping, only 3 textures appear however.

Leaving them out:

Adding the 3 dumps unedited:

Useful files:
Dumps.zip
PJ64_Savestate.zip

[gonetz]

@GhostlyDark I checked that problem. GLideN64 dumps only 3 of 4 textures because it calculates the same Rice CRC for two textures. GLideN64 texture CRC is different for them, so native textures work correctly. It can be a bug in GLideN64 implementation of Rice CRC calculation. I tried to dump textures with Rice plugin to check that. Unfortunately, I can't find these textures among dumped ones. Could you try to dump these textures with Rice and if it makes correct dump, attach it to the task?

[GhostlyDark]

Rice exhibits the exact same issues.

[gonetz]

@GhostlyDark , thanks! So, it's not a problem with implementation of Rice CRC, it is problem with Rice CRC itself.
The only way to solve it is to somehow modify CRC calculation.
I can suggest the following solution:

• add new dump mode: "dump with strong hash".
• if some textures dumped incorrectly with vanilla RiceCRC, texture artist uses alternative dump mode.
  Texture format remains the same, only checksum in texture name will be different.
• During textures load, graphics plugin will first try to load HD texture as usual, with RiceCRC.
  If load fails, the plugin calculates alternative CRC and tries to load HD texture with it.

This way we keep compatibility with existing HD packs and solve problems like this one.
Such a modification is easy to add to other graphics plugins.
The necessary condition is existing of 32bit hash, which is stronger than RiceCRC32 one.
Such hash really exists. GLideN64 currently uses XXH3_64bits_withSeed for texture checksum calculation.
It returns 64bit hash. We need a 32bit one for compatibility with Rice format.
I checked the "Cerebral Bore crosshair" case. XXH3_64bits returns different hashes for textures, where RiceCRC32 fails and return the same. The results remain different even just being cast to uint32. We can also xor higher and lower 32 bits to be sure in the result.

If this solution sounds acceptable, I can implement it.

[GhostlyDark]

Sounds good to me.

[gonetz]

@GhostlyDark
I created PR: Add "Use strong CRC for texture dump" option. #2820
All textures for "Cerebral Bore crosshair" dumped correctly with strong CRC and plugin can load them as HD textures.
Texture dumps stored in "strong_crc" sub-folder when this option is enabled.
I also added a hotkey to switch it on/off, so you may switch between dump modes without using the config dialog.
Please try that build and tell me, what should be added or changed for texture artists convenience.

[GhostlyDark]

This works really well and addresses similar issues, like #2798.

Used some mindless upscaling for testing, the strong_crc is needed for I, . and :.

#2317 is at least partially fixed. The numbers in the VS Record screen are still busted, which is probably unrelated to this, as the Rice dumps differ. I updated that issue with some info and a savestate, in case you want to check it out.

Resident Evil 2 has issues with differently colored text overwriting, which is also fixed with this new option.

The hotkey is really handy and I don't have an issue with the current implementation. The location of the strong_crc folder is fine and makes it easy to sort out the files, although it can look a bit cluttered. Not sure if it'd be better to have it in Internal ROM Name/strong_crc or Internal ROM Name/GLideNHQ_strong_crc or something similar, but I don't have hard feelings either way.

[gonetz]

Thanks for the feedback!

Not sure if it'd be better to have it in Internal ROM Name/strong_crc or Internal ROM Name/GLideNHQ_strong_crc or something similar, but I don't have hard feelings either way.

The plugin builds path to dumps folder and passes it to GLideNHQ library. The library adds internal name to the path and builds the full file name. To build path as "Internal ROM Name/GLideNHQ_strong_crc", I need to pass "strong_crc" flag to the library. It could be done, but I had decided to add as little changes to library's interface as possible. If the current location of the strong_crc folder looks cluttered, I'll fix it.

[GhostlyDark]

I think going the route of doing as little changes as possible is better, so keeping it the way it is right now should be fine.

[gonetz]

It was not hard to change and the changes in the library interface were minimal - I just added txfilter_dmptx_strong function.

[GhostlyDark]

Fixed via ded38f8