Open o-p-a opened 4 months ago
I like this intent, thank you! Can we get this to be tested out by folks in the forums, hopefully even folks who'd use East Asian characters? I'm away for a few weeks, so I really won't be able to test this (well, I also wouldn't be using the character set for it), but I appreciate putting this together as it is indeed an issue for such character sets.
Thanks.
Thank you for reply! I have created this thread on the forum. I hope it will be merged once it is confirmed as OK.
Thanks. Let me know how it goes, otherwise I'll ping this in September and we'll take it from there.
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 oneVertexList
holding the vertices and textureId. This is constructed byFont::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 incrementingi
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.