-
Notifications
You must be signed in to change notification settings - Fork 287
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate Glitches in Tilemaps Plugin #689
Comments
#FIX: Fixed a Canvas state leak for rendering CamView overlays in TilemapEditor, causing one of the glitches from issue #689
Looked into (3) and fixed it with the above commit. There was an overlay rendering routine that adjusted the state of a shared Canvas without resetting it afterwards, causing offset and rotation issues in rendered overlays. The other two are of course still up for grabs 👍 |
I'll take a look and see if I can get to the bottom of either of the other 2. @mfep Is there any additional information you can provide regarding reproduction steps and/or source of the issue? Thanks in advance 👍 |
I could reproduce glitch no. 1. It's possible that this is related to issue 2. as well. Here's how:
|
It looks like there are some other issues with the tile palette. When docking windows, sometimes the palette window infinitely. I am still unsure of the mechanisms, but it looks like when the scene camera and the tile palette are in the same dock, they don't play well together. Regarding step 4 in your repro steps, that looks like another issue entirely, and is likely the source of some bugs - When resizing the source tile size to the same proportions as they were before, (e.g. resizing from (8,8) to (16,16)) the apply/revert buttons are inactive. I don't see this issue when changing the proportions, however. |
Upon further investigation, part of the issue appears to be the hash function in Point2.cs:
when you are using a square source tile, which is not an unusual scenario, this hash is always 0. The tilemap editor uses hash codes to determine whether changes have been made, so it flags this as a non-change, since the hash codes now match again, even though the source tile size has changed. Modifying the hash code calculations for tilemaps should do the trick. |
Can you verify this with a newly created tileset and repro steps? As changing the source tile size shifts how the source images are broken up into tiles, what you are observing could be correct behavior with "user caused incorrect data". For example, if tile indices are shifted, previous AutoTile settings could apply to different tiles in ways that no longer make sense visually. |
Can you file a new issue for this with the description and video you provided? I think you're right that this is something else entirely, probably better discussed in a new thread. Great work investigating these issues so far btw 👍 |
Summary
While reviewing PR #687, @mfep found some unrelated issues with the Tilemaps plugin. Investigate and fix them.
How to reproduce
The text was updated successfully, but these errors were encountered: