Conversation
Contributor
|
I did something similar for the Odin raylib renderer, and I recommend not making this the default, a lot of text is so ascii, and it's significantly faster to work with than full utf-8. In the Odin version I have measure_text_ascii and measure_text_utf8, with measure_text being an alias for the ascii one. I'd recommend a similar approach here to keep performance, while adding the more expensive option when necessary |
Author
|
@rats159 fair enough, I've added the old function again. Lmk if this is ok |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The present implementation for the text measuring function in the raylib renderer does not support multibyte UTF-8 codepoints, such as German umlauts.
Worse, since the leading bit of the first byte in a multibyte UTF-8 sequence is always a 1, the index calculated by
int index = text.chars[i] - 32;is guaranteed to be negative, makingfontToUse.glyphs[index].advanceXread into random memory.Also, the order in which the glyphs are present in the
glyphsfield of a raylib font can be arbitrary, for example when loaded with custom code points using raylib'sLoadFontEx().This fix employs the functions
GetCodepoint()andGetGlyphInfo(), both provided by raylib.It also addresses the point raised in #634 .