How do games handle rendering Asian unicode text?

Question

I'm currently in the process of implementing text rendering in my game engine, and I decided to utilize AngelCode's BMfont to generate font textures, and then have OpenGL render textured quads for each character. This worked great, even when rendering every single glyph supported by FreeFont (FreeMono in particular), until I tried to render Japanese (My Japanese font of choice is Noto, provided by Google).

Rendering every single glyph supported by FreeMono at 16px resulted in a single 1024x1024 8bit texture, perfectly reasonable considering how many languages are covered by it. Rendering everything supported by Noto Japanese, at the same size, resulted in 13 times as many textures, and at this size most of the glyphs are too cramped to be readable (I can't read Japanese, but if I could I think I would still have a lot of trouble reading this text).

My question is twofold:

1) How do games, or mobile apps, handle small Japanese text? Do they stick to a subset of the kanji, use a special font, or is there a minimum font size?

2) How do games typically handle the absurdly massive number of glyphs required by Japanese, Chinese, Korean, and other languages? Do they use FreeType (or something similar) to render the text on-the-fly?

Note: I tried Meiryo (which I do not have the license to use in my game) and the result was far more readable at 16px (still cramped though), but still required 14 textures to fit everything.

Answer 1

I'm using the freetype library (http://www.freetype.org/) to load glyphs from freetype fonts and then use bin packing to generate a glyph texture/atlas during runtime, similar to how freetype-gl does it (https://code.google.com/p/freetype-gl/).

When the game is initialized, I generate a glyph atlas with the printable characters from the ASCII range. This atlas won't change during the game. An additional atlas is used for non-ascii characters.

Whenever a string is enqueued for drawing, I check if there is a glyph which has not been loaded yet. If such a glyph is encountered, I mark the glyph atlas as dirty and regenerate the glyph atlas before rendering. If the atlas is full, non-ascii glyphs are dropped if they have not been in use for a certain amount of time/frames.

There's a certain overhead induced by loading glyphs on the fly and rebuilding the glyph atlas, but on the other hand, any glyphs supported by the font can be used with this system.

Then again, I'm not drawing a lot of stuff besides text yet...

Answer 2

In the games I've worked on, we restricted the subset of characters used for Chinese, Japanese, and Korean (together referred to as CJK) to only those required to display the text in the game.

In other words, we didn't attempt to cram in every possible character; we just took the database of CJK text from our localization teams, did a pass over it to find all the Unicode code points that occurred at least once in the text, and generated a BMFont configuration file to lay out an atlas for exactly those characters. (It was all automated, so every time we got a new loc drop, we could regenerate the list of characters and the fonts as needed.)

As you can imagine, this vastly reduces the number of characters required. We also compressed the font bitmaps with DXT1, which works quite well for text (even antialiased). BMFont also has an option to use all four color channels of an image as separate pages (thus getting 4x the number of characters per page), but this doesn't play as nicely with compression, so we didn't end up using it.

I'm not sure about font sizes, though. If you haven't got any CJK-reading friends who can take a look and tell you if it's too small, you could try looking at CJK-subtitled movies to get an idea of how big the text is there.