tr1/text: improve text handling in TR1 #1933
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Download the built assets for this pull request: |
rr-
force-pushed
the
glyphs
branch
2 times, most recently
from
c76de3f to
441aa28
Compare
rr-
changed the title
rr-
requested review from
lahm86,
walkawayy and
aredfan
and removed request for
a team
|
Overall LGTM. The only issue I found is the TRUB gameflow doesn't point to the font.bin file, which causes this issue.
|
The time-consuming O(n^2) loop that compared user string characters with all possible glyphs has been replaced by `uthash` lookups for improved glyph lookup speed. This requires precise glyph size knowledge, which involves some additional parsing. An added benefit is improved handling of unknown Unicode glyphs: by moving through entire codepoints rather than incrementing the pointer by 1 byte, the process avoids ending in the middle of an incomplete UTF-8 codepoint.
|
@aredfan fixed and made sure that we do not attempt to draw unavailable sprites. |
walkawayy
reviewed
Nov 24, 2024
walkawayy
approved these changes
Nov 24, 2024
aredfan
approved these changes
Nov 24, 2024
lahm86
approved these changes
Nov 24, 2024
This was
linked to
issues
Nov 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Checklist
Description
This pull request extends the named sequences support we have introduced in 4.6 to also support Unicode strings. I have confirmed the following languages to have full coverage:
Asian and Arabic languages remain unsupported at the moment. While Arabic is still far away due to the RTL rendering order, we're much closer to supporting CJK.
The sprites for the characters come from Arsunt's extended font posted in Tomb Raider Forums.
Pivotal for this feature is a textfile containing manual Unicode codepoint mappings. Although I initially experimented with JSON, YAML, and CSV, I discovered through testing that using a DSL (domain-specific language) designed specifically for this purpose offers the best readability.
The mapping file is used by the tooling in the tools/glyphs/ directory and serves two roles:
It generates C macros that map Unicode code points and escaped sequences to O_ALPHABET's sprite indices, specify glyph dimensions, and instruct how to compose compound characters - all getting hardcoded into the executable.
It directs the injector tool in creating the font.bin file that contains O_ALPHABET sprite bitmaps, along with additional positional information.
Some sprite indices are fixed. This is for compatibility with the original game to retains original text format even if font.bin goes missing.
Creating sprites for all possible accented characters is a challenging and resource-intensive task. Instead, the mapping allows us to combine certain characters so that the game overlays one glyph on another. However, we only support one accent per glyph. Consequently, Vietnamese, despite using the Latin alphabet, is currently unsupported due to its extensive use of diacritics.
As we now have many more glyphs to compare, the time-consuming O(n^2) loop that matched user string characters with all possible glyphs has been replaced by
uthashlookups for faster glyph retrieval. This approach requires precise knowledge of glyph sizes, necessitating some additional parsing, but it benefits from eliminating ambiguity in glyph matches. An additional benefit is improved handling of Unicode codepoints without declared mappings: by traversing entire codepoints rather than incrementing the pointer by 1 byte, the process avoids ending up in the middle of an incomplete UTF-8 codepoint, preventing garbled text.