Làm thế nào để trò chơi xử lý kết xuất văn bản unicode châu Á?

Tôi hiện đang trong quá trình triển khai kết xuất văn bản trong công cụ trò chơi của mình và tôi đã quyết định sử dụng BMfont của AngelCode để tạo họa tiết phông chữ, và sau đó có các hình tứ giác kết cấu OpenGL cho mỗi nhân vật. Điều này hoạt động rất tốt, ngay cả khi kết xuất mọi glyph duy nhất được FreeFont hỗ trợ (cụ thể là FreeMono), cho đến khi tôi cố gắng kết xuất tiếng Nhật (Phông chữ tiếng Nhật của tôi là Noto, do Google cung cấp).

Kết xuất mọi glyph duy nhất được FreeMono hỗ trợ ở 16px dẫn đến kết cấu 8 bit 1024x1024, hoàn toàn hợp lý khi xem xét có bao nhiêu ngôn ngữ được bao phủ bởi nó. Kết xuất mọi thứ được hỗ trợ bởi Noto Nhật Bản, ở cùng kích thước, dẫn đến số lượng kết cấu gấp 13 lần và ở kích thước này, hầu hết các glyphs quá chật chội không thể đọc được (tôi không thể đọc được tiếng Nhật, nhưng nếu tôi có thể nghĩ thì tôi sẽ vẫn còn nhiều rắc rối khi đọc văn bản này).

Câu hỏi của tôi có hai mặt:

1) Làm thế nào để trò chơi, hoặc ứng dụng di động, xử lý văn bản tiếng Nhật nhỏ? Họ có dính vào một tập hợp con của chữ Hán, sử dụng một phông chữ đặc biệt hoặc có kích thước phông chữ tối thiểu không?

2) Làm thế nào để các trò chơi thường xử lý số lượng glyphs khổng lồ theo yêu cầu của tiếng Nhật, tiếng Trung, tiếng Hàn và các ngôn ngữ khác? Họ có sử dụng FreeType (hoặc một cái gì đó tương tự) để hiển thị văn bản đang hoạt động không?

Lưu ý: Tôi cố gắng Meiryo (mà tôi không có giấy phép sử dụng trong trò chơi của tôi) và kết quả là xa hơn có thể đọc được ở 16px (vẫn còn chật chội dù), nhưng vẫn yêu cầu 14 textures để phù hợp với tất cả mọi thứ.

Tôi đang sử dụng thư viện freetype ( http://www.freetype.org/ ) để tải glyphs từ phông chữ freetype và sau đó sử dụng bin pack để tạo kết cấu / bản đồ glyph trong thời gian chạy, tương tự như cách freetype-gl thực hiện ( https : //code.google.com.vn/p/freetype-gl/ ).

Khi trò chơi được khởi tạo, tôi tạo một tập bản đồ glyph với các ký tự có thể in từ phạm vi ASCII. Bản đồ này sẽ không thay đổi trong trò chơi. Một tập bản đồ bổ sung được sử dụng cho các ký tự không phải ascii.

Bất cứ khi nào một chuỗi được vẽ để vẽ, tôi kiểm tra xem có một glyph nào chưa được tải không. Nếu gặp phải glyph như vậy, tôi đánh dấu tập bản đồ glyph là bẩn và tái tạo tập bản đồ glyph trước khi kết xuất. Nếu tập bản đồ đầy, glyphs không ascii sẽ bị hủy nếu chúng chưa được sử dụng trong một khoảng thời gian / khung nhất định.

Có một chi phí nhất định gây ra bằng cách tải glyphs khi đang bay và xây dựng lại tập bản đồ glyph, nhưng mặt khác, bất kỳ glyph nào được hỗ trợ bởi phông chữ đều có thể được sử dụng với hệ thống này.

Sau đó, một lần nữa, tôi không vẽ nhiều thứ ngoài văn bản ...

Trong các trò chơi tôi đã làm việc, chúng tôi đã giới hạn tập hợp các ký tự được sử dụng cho tiếng Trung, tiếng Nhật và tiếng Hàn (gọi chung là CJK) chỉ cho những người được yêu cầu hiển thị văn bản trong trò chơi.

Nói cách khác, chúng tôi đã không cố gắng nhồi nhét mọi nhân vật có thể; chúng tôi vừa lấy cơ sở dữ liệu của văn bản CJK từ các nhóm bản địa hóa của mình, đã vượt qua nó để tìm tất cả các điểm mã Unicode xảy ra ít nhất một lần trong văn bản và tạo tệp cấu hình BMFont để đặt một tập bản đồ cho chính xác các ký tự đó. (Tất cả đều được tự động hóa, vì vậy mỗi khi chúng tôi có một lần thả cục bộ mới, chúng tôi có thể tạo lại danh sách các ký tự và phông chữ khi cần.)

Như bạn có thể tưởng tượng, điều này làm giảm đáng kể số lượng ký tự cần thiết. Chúng tôi cũng nén bitmap phông chữ với DXT1, hoạt động khá tốt cho văn bản (thậm chí là khử răng cưa). BMFont cũng có một tùy chọn để sử dụng tất cả bốn kênh màu của một hình ảnh dưới dạng các trang riêng biệt (do đó nhận được gấp 4 số lượng ký tự trên mỗi trang), nhưng điều này không phát huy tốt khi nén, vì vậy chúng tôi đã không sử dụng nó.

Tôi không chắc chắn về kích thước phông chữ, mặc dù. Nếu bạn chưa có bất kỳ người bạn đọc CJK nào có thể xem và nói với bạn nếu nó quá nhỏ, bạn có thể thử xem các phim có phụ đề của CJK để có ý tưởng về văn bản lớn như thế nào.