Wie gehen Spiele mit dem Rendern von asiatischem Unicode-Text um?

Ich bin gerade dabei, das Text-Rendering in meiner Spiel-Engine zu implementieren. Ich habe mich entschieden, AngelCodes BMfont zum Generieren von Schrifttexturen zu verwenden und dann OpenGL strukturierte Quads für jeden Charakter rendern zu lassen. Dies funktionierte hervorragend, selbst wenn alle von FreeFont unterstützten Glyphen (insbesondere FreeMono) gerendert wurden, bis ich versuchte, Japanisch zu rendern (meine bevorzugte japanische Schriftart ist Noto, bereitgestellt von Google).

Das Rendern jeder einzelnen von FreeMono unterstützten Glyphe mit 16 Pixel führte zu einer einzelnen 8-Bit-Textur von 1024 x 1024, was angesichts der Anzahl der Sprachen, die davon abgedeckt werden, durchaus sinnvoll ist. Das Rendern aller von Noto Japanese unterstützten Elemente in derselben Größe führte zu 13-mal so vielen Texturen, und bei dieser Größe sind die meisten Glyphen zu eng, um lesbar zu sein (ich kann kein Japanisch lesen, aber wenn ich könnte, würde ich es mir vorstellen habe immer noch große Probleme beim Lesen dieses Textes).

Meine Frage ist zweifach:

1) Wie gehen Spiele oder mobile Apps mit kleinen japanischen Texten um? Halten sie sich an eine Teilmenge des Kanji, verwenden sie eine spezielle Schriftart oder gibt es eine Mindestschriftgröße?

2) Wie gehen Spiele normalerweise mit der absurd großen Anzahl von Glyphen um, die für Japanisch, Chinesisch, Koreanisch und andere Sprachen erforderlich sind? Verwenden sie FreeType (oder ähnliches), um den Text im laufenden Betrieb zu rendern?

Hinweis: Ich habe Meiryo ausprobiert (für das ich keine Lizenz für mein Spiel habe) und das Ergebnis war bei 16px weitaus besser lesbar (obwohl es immer noch eng ist), benötigte aber immer noch 14 Texturen, um alles zu passen.

Ich verwende die Freetype-Bibliothek ( http://www.freetype.org/ ), um Glyphen aus Freetype-Schriftarten zu laden, und verwende dann Bin Packing, um zur Laufzeit eine Glyphentextur / einen Glyphenatlas zu generieren, ähnlich wie dies bei Freetype-Gl der Fall ist ( https) : //code.google.com/p/freetype-gl/ ).

Wenn das Spiel initialisiert wird, erstelle ich einen Glyphenatlas mit den druckbaren Zeichen aus dem ASCII-Bereich. Dieser Atlas ändert sich während des Spiels nicht. Ein zusätzlicher Atlas wird für Nicht-ASCII-Zeichen verwendet.

Immer wenn eine Zeichenfolge zum Zeichnen in die Warteschlange gestellt wird, überprüfe ich, ob eine Glyphe vorhanden ist, die noch nicht geladen wurde. Wenn eine solche Glyphe auftritt, markiere ich den Glyphenatlas als verschmutzt und regeneriere den Glyphenatlas vor dem Rendern. Wenn der Atlas voll ist, werden Nicht-ASCII-Glyphen gelöscht, wenn sie für eine bestimmte Zeit / Frames nicht verwendet wurden.

Es gibt einen gewissen Overhead, der durch das Laden von Glyphen im laufenden Betrieb und das Wiederherstellen des Glyphenatlas verursacht wird. Andererseits können mit diesem System alle von der Schriftart unterstützten Glyphen verwendet werden.

Andererseits zeichne ich außer Text noch nicht viel ...

In den Spielen, an denen ich gearbeitet habe, haben wir die Teilmenge der für Chinesisch, Japanisch und Koreanisch verwendeten Zeichen (zusammen als CJK bezeichnet) auf diejenigen beschränkt, die zum Anzeigen des Textes im Spiel erforderlich sind.

Mit anderen Worten, wir haben nicht versucht, jeden möglichen Charakter zu stopfen. Wir haben gerade die Datenbank mit CJK-Text von unseren Lokalisierungsteams genommen, sie durchlaufen, um alle Unicode-Codepunkte zu finden, die mindestens einmal im Text vorkamen, und eine BMFont-Konfigurationsdatei generiert, um einen Atlas für genau diese Zeichen zu erstellen. (Es wurde alles automatisiert, sodass wir jedes Mal, wenn wir einen neuen Loc-Drop erhielten, die Liste der Zeichen und die Schriftarten nach Bedarf neu generieren konnten.)

Wie Sie sich vorstellen können, reduziert dies die Anzahl der erforderlichen Zeichen erheblich. Wir haben auch die Schriftarten-Bitmaps mit DXT1 komprimiert, was für Text (auch für Antialiasing) recht gut funktioniert. BMFont hat auch die Option, alle vier Farbkanäle eines Bildes als separate Seiten zu verwenden (wodurch die vierfache Anzahl von Zeichen pro Seite erreicht wird). Dies funktioniert jedoch nicht so gut mit der Komprimierung, sodass wir es nicht verwendet haben.

Bei den Schriftgrößen bin ich mir jedoch nicht sicher. Wenn Sie keine CJK-lesenden Freunde haben, die einen Blick darauf werfen und Ihnen sagen können, ob es zu klein ist, können Sie sich Filme mit CJK-Untertiteln ansehen, um eine Vorstellung davon zu bekommen, wie groß der Text dort ist.