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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Tile Bleeding When Using Atlas Feature #197

Merged
merged 1 commit into from Jun 25, 2022

Conversation

zicklag
Copy link
Contributor

@zicklag zicklag commented Jun 24, 2022

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!

@zicklag
Copy link
Contributor Author

zicklag commented Jun 24, 2022

Oh, wait, I messed something up. I've got to fix it.

@zicklag
Copy link
Contributor Author

zicklag commented Jun 24, 2022

Does anybody know if branching ( using an if statement ) is something to really try to avoid in fragment shaders? I've seen people mention it in random places before and I kind of got the feeling that it was something you want to avoid if possible.

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 if statements are a problem I can try more to fix them, but if they aren't then it's easier to read as is.


And this branch should be ready and working again.

@StarArawn StarArawn merged commit 7619cc6 into StarArawn:main Jun 25, 2022
@zicklag zicklag deleted the feature/fix-tile-bleeding branch June 25, 2022 15:46
@StarArawn
Copy link
Owner

Does anybody know if branching ( using an if statement ) is something to really try to avoid in fragment shaders? I've seen people mention it in random places before and I kind of got the feeling that it was something you want to avoid if possible.

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 if statements are a problem I can try more to fix them, but if they aren't then it's easier to read as is.

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. 馃憤

@zicklag
Copy link
Contributor Author

zicklag commented Jun 25, 2022

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.

@StarArawn
Copy link
Owner

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.

@zicklag
Copy link
Contributor Author

zicklag commented Jun 25, 2022

OK, no problem. 馃憤

@zicklag zicklag restored the feature/fix-tile-bleeding branch June 25, 2022 17:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

visual tearing between tiles
2 participants