Emulator

Please check if r6308 has fixed this problem. Hopefully the texture names are now stable after r6308 (they may not be the same as they were in r6277).

Are those really the same images or do they differ in some pixels?

As far as I can tell, they're exactly the same. They're even the same resolution and size. The only difference seems to be that they're loaded when in different areas.

I realised that I hadn't updated to r6308, for some reason I assumed I did (and deleted my last post). Anyways, updated and rechecked that the issue was still occurring and it is unfortunately.

I'll just repeat what I said in the post I deleted. I don't mean to sound naggy, I understand that enhancement games isn't as high priority as fixing games. I'm not used to posting issues, and am not entirely sure how to do it while sounding duly appreciative.

fwiw, I should have maybe asked for the filenames as well...
could you e.g. post the filenames of those 5 textures?
(and please don't delete comments, that really can be confusing sometimes :P)

Heh, sorry. The telescope images are:
GZLE01_22ed04ad3094341a_9.png
GZLE01_a92160299028438c_9.png
GZLE01_75032d3ddbab32fa_9.png
GZLE01_ad1debad086075b7_9.png
GZLE01_b885588892e78bd1_9.png

But there's plenty of images that have duplicates. Any holdable item and button icons seem to do it. Oh and looking through, even stuff like floor textures.

hm, that string between the underscores is the texture hash, i.e. apparently the texture do seem to be different.. at least to Dolphin.

Fwiw, you DO delete the old textures when retrying, right?
And... what happens if you enable/disable safe texcache and try the different accuracy levels?

Yeah, I am deleting Zelda's dump folder each time.

Hadn't thought of changing Safe Texture Cache settings but it's the same (I had it set to normal), I've now tried it with it off, set to "safe" and "fast". I made sure to restart Dolphin after setting the Safe Texture Cache mode aswell, since I couldn't remember if that was required.

I'm seriously considering looking through the textures pixel by pixel to see if there's a difference right now, but I just don't see that being the case. I didn't realize Dolphin was using a checksum before, but I now I do, I can see why it's weird, because I'm pretty certain that they're not different files. Otherwise, for some reason, Nintendo have a different texture per game area, for pretty much every texture used in the game (I mean, that would be a huge waste of disc space).

You could as well just run some diff tool over the files to check them for differences.

Oh, just noticed that the filenames are different when changing Safe Texture cache modes. When Safe Texture Cache is set to normal, the main Zelda logo on the main screen is:
GZLE01_b29da1059c232166_9.png

On fast:
GZLE01_409dc39a2f577178_9.png

On safe:
GZLE01_f7313ee6b3794f9a_9.png

Off:
GZLE01_f7313ee6b3794f9a_9.png

Tried comparing the files in WinMerge (googled for "diff tool" :D ), according to that "The selected files are identical".

@mattcallaghan The original way I implemented hires textures was saving them based off the safe texture value, so I guess when different versions of safe texture were put in, they didn't think of hires textures using it.

I guess we could force the use of a specific level for safe texture hashes when hires textures are loaded, but I'm not sure of the effect on performance/accuracy this will have.

I know this is old, but if you are loading hi-res textures, you probably have performance to spare.

So I was curious if this still happened and if I could figure out a few more details about it.

It doesn't happen with all textures, it seems to just be the GUI textures (the ones I was wanting to replace) and seemingly a few random other textures.

I didn't fully trust the diff tools that I used since they all seem to prefer proper text files, so I made a super quick and dirty diff tool for checking the RGBA values of image files, and in that way at least, the images are identical.

Just wondering if I should close this now really, since it apparently only affects one game, and only some of the textures.

The filenames indicate that this only affects paletted textures ("_9" = GX_TF_C8).

The different filenames come from the fact that those textures use a different texture lookup table (tlut). The filename is using the format gameid_texhash_format, but paletted textures get their texhash XORed with the hash of the current tlut.

A proper fix for this would be what texcache-rewrite did: Don't decode and depalettize textures at the same time, but separate the steps; texture dumping would only dump the decoded texture to disk then. However, this would probably break existing hires texture packs which use paletted textures.

Could you add in a "only dump the decoded texture to disk" check box option?

Or would an option such as that be impossible or extremely difficult to implement?