Skip to content
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

Brushes get messed up on Staggered maps #3431

Closed
eishiya opened this issue Aug 4, 2022 · 3 comments · Fixed by #3628
Closed

Brushes get messed up on Staggered maps #3431

eishiya opened this issue Aug 4, 2022 · 3 comments · Fixed by #3628
Assignees
Labels
bug Broken behavior.

Comments

@eishiya
Copy link
Contributor

eishiya commented Aug 4, 2022

When copy+pasting tiles on a staggered maps, if the origin (top left corner) of the brush was on a staggered row, every other row of the brush is pushed in the opposite direction of what's required to account for the staggering. Here, the hexagon of tiles starts on row 1, a staggered row, and copy+pasting it results in a mess:
image
If the origin of the brush was on a non-staggered row, then stagger compensation works perfectly fine. Here, I redrew my hexagon of tiles starting on row 0, a non-staggered row, and copy+pasted it, it behaves correctly no matter where I try to paint it:
image

I don't use staggered maps often so I don't know when this started. I noticed this in 1.9.0, Win64.

My guess is the stagger-compensating code always shifts certain rows in a particular direction based on their coordinates in the brush itself, disregarding where they came from in the source map, which would affect which rows are staggered and which are not.

@eishiya eishiya added the bug Broken behavior. label Aug 4, 2022
AtlaStar added a commit to AtlaStar/tiled that referenced this issue Mar 14, 2023
Appears that the reinterpret cast from a QRect to a QRegion was causing issues when the selection started on a staggered index.
@bjorn
Copy link
Member

bjorn commented Mar 17, 2023

Problem appears related to there being an odd number of empty rows at the top of the captured area, like this:

image

@eishiya
Copy link
Contributor Author

eishiya commented Mar 17, 2023

Problem appears related to there being an odd number of empty rows at the top of the captured area

On maps with stagger axis X, it may be related to empty columns instead, that's something to check too.

@bjorn
Copy link
Member

bjorn commented Mar 20, 2023

After being stumped on this for way too long, I eventually located the issue. Should be fixed by #3628.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Broken behavior.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants