-
Notifications
You must be signed in to change notification settings - Fork 199
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
Fix Tile Bleeding When Using Atlas Feature #197
Conversation
d3d52f6
to
d2bf922
Compare
6a95d15
to
25da5ea
Compare
Oh, wait, I messed something up. I've got to fix it. |
25da5ea
to
adc1f7d
Compare
Does anybody know if branching ( using an I have a version that works without branching, but it's harder to read and I only got it to work if I handled clamping overflow in the positive x or y direction, and not in in the negative x or y direction. Apparently for my hardware it only bleeds in the positive direction, but I'm not sure if it's like that for all hardware. Anyway, if the And this branch should be ready and working again. |
Branching should be avoided in some cases, but I'm not too worried about it here I think. 👍 |
Awesome! Would we be able to make a new release with the fix? I'm wanting to release my crate which depends on it, but since I use the atlas feature I wanted to get this fixed before I did the release. |
I'm not planning on releasing until the rewrite is finished. I just moved this change over to the rewrite. |
OK, no problem. 👍 |
Fixes #184 ! 🎉 ( I think )
This issue has plagued me in all the tile renderer's I've written over the last couple years, but I think this might finally fix it. :)
The strategy is to offset the UV sampling of the tilemap one half-pixel away from the edges of the tile so that it doesn't come close to sampling onto the next tile near the edges.
It seems to work great on my hardware, but it could be different for different hardware. Please try it out and see if it works!