[rtext] Incorrect rendering of pixel font

[Vanglant]

Issue description

Hello! I'm using the m5x7 pixel font(https://managore.itch.io/m5x7) in my game, with a 480x270 render target (point texture filter) that is rendered then to the screen (960,540), it currently looks like this (using point texture filter as well):

I noticed that it is rendering fine in Foster framework and they are also using stb_truetype, but instead of
stbtt_ScaleForPixelHeight

raylib/src/rtext.c

Line 638 in 8a68587

float scaleFactor = stbtt_ScaleForPixelHeight(&fontInfo, (float)fontSize);

they are using:
stbtt_ScaleForMappingEmToPixels https://github.com/FosterFramework/Foster/blob/0b814e1ee312d216008c1fd2291f0e0b12295c91/Framework/Internal/ThirdParty/StbTrueType.cs#L48

Compiled latest raylib with this change and looks like the output is correct now:

I'm not sure if this is a breaking change, tried the text_font_filters example with the change and seems to be ok aswell, but not sure yet, currently going through the stb_truetype docs to find out more info https://github.com/nothings/stb/blob/28d546d5eb77d4585506a20480f4de2e706dff4c/stb_truetype.h#L766

Also this issue might be relevant: nothings/stb#689

Found similar issues: https://www.reddit.com/r/raylib/comments/1g0pwr5/pixel_font_blurriness_with_specific_fonts/
https://www.reddit.com/r/raylib/comments/1g0cbny/pixel_font_distortion/

Environment

Windows 11

[CrackedPixel]

I don't think this is a simple problem to solve 😅

stbtt_ScaleForPixelHeight scales with pixelSize / (ascent - descent), and is mostly guaranteed to have pixel-perfect bounding boxes

stbtt_ScaleForMappingEmToPixels instead scales based on "point size" and the specific fonts ascent/descent/EM values can affect the output

i think both are valuable to have. good luck, ray 🤣

[tacf]

I'm also bumping into this, although i think i've partially mitigated it by forcing any sizing to clamp to the nearest integer. Poor mans solution so i'd be interested in seeing how this goes 😄

[Vanglant]

@CrackedPixel yep definitely not as simple as swapping one for the other 😅, tested more pixel fonts with the setup and it varies from font to font, seems like for low res rendering stbtt_ScaleForMappingEmToPixels works quite well, some fonts do not need it at all and render properly without it

using stbtt_ScaleForMappingEmToPixels + specifying the size of the font on load

rl.LoadFontEx("assets/m5x7.ttf", 16, nil, 0) then rendering with that size or twice the size, for example rl.DrawTextEx(g.font, "m5x7", rl.Vector2{0, 0}, 16 * 2, 0, rl.WHITE):

Using ScaleForPixelHeight + specifying the size of the font on load:

Using ScaleForPixelHeight + loading font at 10x the size: rl.LoadFontEx("assets/m5x7.ttf", 16 * 10, nil, 0)

[raysan5]

This is a tricky issue, solving it for some fonts will break it for others, raylib always considered font size in pixels, actually, the maximum-pixel-height a character can take. Changing to a points method will break many things.

[tacf]

This is a tricky issue, solving it for some fonts will break it for others, raylib always considered font size in pixels, actually, the maximum-pixel-height a character can take. Changing to a points method will break many things.

Despite it possibly be a breaking change and since we're at the brink of 6.0 release (and possibly breaking changes are more acceptable at these marks). Would it be a possibility to allow the scaling strategy to be specified through a parameter in LoadFontEx ?

[raysan5]

@tacf That's a too-breaking change for me, LoadFontEx() is a highly-used function, it will break many codebases and alienate many users. I'm afraid this is out of raylib 6.0 release... but as a potential solution for the future could be something in the line of SetFontMetrics(FONT_SIZE_POINTS).