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.
When ES renders characters on the screen, it first uploads the glyphs to a texture and caches them.
The size of each texture is 2048x512, and when one is used up, allocate another texture and used.
If you are an alphabetic region, you probably won't need multiple textures.
For example users East Asian countries who use Chinese characters, one texture is often not enough.
(This is even more noticeable on high-resolution displays, where one character has more pixels.)
When this happens, ES will not work properly. This PR will fix this.
In
TextComponent
, the text to be drawn is stored in theTextCache
.If the glyphs used in the text span multiple textures for the reasons mentioned above, there will be more than one
VertexList
holding the vertices and textureId.This is constructed by
Font::buildTextCache()
, and the result of the calculation is set to cache->vertexLists at the end of the function, but the increment ofi
is forgotten and it is only stored in the first element.As a result, ES will abort. I will correct this by incrementing
i
appropriately.However, this alone will not result in correct drawing.
Because, when (reasons mentioned above) a new texture is pushed back into
mTextures
, reallocation occurs when thestd::vector
is resized elements, and the texture is destroyed even if it is in use.FontTexture
has a default copy ctor and dtor, so they are called when reallocate.The ctor simply copies the members, and the dtor destroys the associated texture.
...Oh, I just wanted to reallocate it, but it destroyed the texture!
I considered defining an appropriate copy constructor to fix this, but unfortunately
mTextures[].textureId
is referenced by pointer from theTextCache
'svertexLists
, so even if I did that, it would be necessary to update theTextCache
's pointer every timemTextures
is reallocated.It's a bit of a hasty job, but I reserved 10 elements when generating the
Font
to prevent rearrangement. I think 10 is a sufficient number even in kanji-using countries.I also set up a guard to prevent any attempt to exceed 10.