- edited description
love.graphics.print sometimes crops the text borders when printing in non-integer coordinates
In the attached file, the upper and lower pixel lines of the text are cropped in random frames due to the floating point (this can be perceived as janky movement)
Expected results: I would expect the top/bottom (and left-right) pixels of the fonts to not be cropped out. I am not sure of how this could be resolved though. Applying blur when the text is on a half pixel? Flooring the text coordinates?
Reference forum post: https://love2d.org/forums/posting.php?mode=reply&f=4&t=81849
Comments (5)
-
-
This seems to be caused by linear filtering of the font's texture at non-integer pixel coordinates (the issue goes away if you add
love.graphics.getFont():setFilter("nearest", "nearest")
to the code).love internally adds 1 pixel transparent borders around each glyph in a font's texture atlas. I'll try making it extrude instead of having transparency, to see if that fixes it when linear filtering is used.
One of the reasons print was changed to avoid flooring on its own is because there's no way to completely undo it, as zorg mentioned in the thread. It also never worked 100% of the time (e.g. if you have custom love.graphics.translate calls), and it caused jitter issues when text was moved around.
-
The flickering is also greatly reduced if you enable gamma-correct rendering (
t.gammacorrect = true
in love.conf). -
I'll try making it extrude instead of having transparency, to see if that fixes it when linear filtering is used.
It prevents the "cropping" style flickering... by changing it to a different type of flickering, and I'm not sure which is preferable.
-
- changed status to open
- Log in to comment