A better way to handle texture scale/cache

[[Unknown]]

The problem is, consider a game using the texture you screenshoted above. I have seen tons of games use textures like that for 3d models.

In that case, it's obvious (to a human) that the entire texture is actually a texture. Hashing the whole thing is right. Here's what happens if you don't hash the whole thing:

1. Game uses top half of texture, ending 50% into texture Y.
2. We calculate the hash as 5123456.
3. Game later (after using another texture, maybe) uses the other half of the texture (going as low as you showed.)
4. Now we see its sizeInRAM as different, so even though the data is identical, we calculate the hash as 2344576.
5. We reload the texture into OpenGL unnecessarily.
6. Go back to 1, where we will again reupload.

This would kill framerates. At best, it would need to track the highest value used in the texture recently. Even then, it will slow down the initial draw of screens (like we saw with Type-0 recently) since it would re-upload textures like I described above for the first frame.

In my example, I meant that texture replacements would say how many bytes of RAM they thought the texture is, therefore allowing the issue to be worked around manually.

The same address can and definitely is used for completely different textures. The only way we get any sort of unique id right now is by hashing it.

-[Unknown]