Closed elringus closed 2 years ago
As 2019.4 is falling into the rearview, we can theoretically use HashUnsafeUtilities.ComputeHash128 for legacy compatibility, and use Hash128.Compute elsewhere. This will add a unique codepath, as well as a "must enable unsafe code" warning for 2019.4, but since that requirement is limited to editor-only code, perhaps this is a decent compromise in the name of backwards compatibility?
@konistehrad thank you for the info! I didn't know about HashUnsafeUtilities. It turns out Hash128.Compute in Unity 2020 is just a wrapper over that utility: https://github.com/Unity-Technologies/UnityCsReference/blob/master/Runtime/Export/Hashing/HashUtilities.cs#L58
The hack is now resolved in v1.6.
HA! Wow you're fast, very cool, and excellent work. 👍
Currently, content hash for dices is generated via Unity's Texture.imageContentsHash, which requires creating and filling a texture per dice, which is inefficient: https://github.com/Elringus/SpriteDicing/blob/master/Assets/SpriteDicing/Editor/Processors/TextureDicer.cs#L93
If anyone have an idea on how to replicate the Unity's image content hashing in a way that even slightly different textures will have unique hashes, please share it here or create a pull request. I've already tried hashing color arrays by each item value and its index, but it's not working in some cases (eg, square in
Assets/Examples/Atlases/Flat
will have artifacts).We could probably try Hash128.Compute, which accepts arrays in Unity 2020, but I want to keep compatibility with 2019.4 for the time being.