5,389
edits
OBD:TSGA: Difference between revisions
m
there there
m (wording; linking to OBD:Text encoding) |
m (there there) |
||
| Line 4: | Line 4: | ||
Every TSGA file contains 256 elements of 20 bytes each, thus taking up 5,120 bytes without the header. Together with the 8-byte header and 32-byte padding, each TSGA takes up 5,152 bytes in a .dat (another 20 bytes are taken up in the instance descriptor array). | Every TSGA file contains 256 elements of 20 bytes each, thus taking up 5,120 bytes without the header. Together with the 8-byte header and 32-byte padding, each TSGA takes up 5,152 bytes in a .dat (another 20 bytes are taken up in the instance descriptor array). | ||
For Western languages, a TSFT has only one TSGA which corresponds to an ASCII- | For Western languages, a TSFT has only one TSGA which corresponds to an ASCII-based [[wp:code page|code page]]: | ||
*the first 32 symbols (0 to 31) are non-printable control characters, so these elements are always all | *the first 32 symbols (0 to 31) are non-printable control characters, so these elements are always all zero; | ||
*the next 96 symbols (32 to 127) correspond to standard ASCII | *the next 96 symbols (32 to 127) correspond to standard US-ASCII (except that 127 is usually non-printable); | ||
*the upper half of the table (128 to 255) is | *the upper half of the table (128 to 255) contains additional punctuations and ligatures, Latin characters with diacritics and, in the case of the Russian version, Cyrillic script. | ||
The code page is not the same for all Western Oni versions. | |||
Asian localizations of Oni use their own extended encoding system and glyph data either in place of Oni's (Chinese), or in combination with it (Japanese). | |||
See [[OBD:Text encoding]] for details on the encoding systems, a list of the available characters in each language version, and a review of known issues. | |||
---- | ---- | ||
| Line 35: | Line 39: | ||
The pixels stored in TSFT (packed 4-by-4 as little-Endian unsigned int32s) are treated as a scanline, row major, top to bottom and left to right. The width of a glyph is not always a multiple of 4 pixels, so the scanline can wrap around, i.e. a new row of pixels can start in the middle of a 4-byte element. The start of a glyph, however, is always aligned on a 4-byte element of the TSFT array. The end of a glyph is padded with 0xDEAD. | The pixels stored in TSFT (packed 4-by-4 as little-Endian unsigned int32s) are treated as a scanline, row major, top to bottom and left to right. The width of a glyph is not always a multiple of 4 pixels, so the scanline can wrap around, i.e. a new row of pixels can start in the middle of a 4-byte element. The start of a glyph, however, is always aligned on a 4-byte element of the TSFT array. The end of a glyph is padded with 0xDEAD. | ||
---- | |||
;Difference in the PS2 implementation | |||
{{Table}} | |||
|- ALIGN=CENTER VALIGN=TOP | |||
{{OBDtr| 0x0C | int32 |FFC800| 00 00 00 00 |unused| position of the pixel glyph data in the .raw part of the [[OBD:TSFT|TSFT]] file, in quarter-bytes }} | |||
{{OBDtr| 0x10 | int32 |C800C8| 00 00 00 00 |unused| runtime only? }} | |||
|} | |||
In the PS2 implementation, glyphs are also rectangular grayscale bitmaps, but the storage is much more compact, with only 2 bits per pixel (i.e., 4 pixels per byte), and the scanline is stored continuously for the whole font, without padding/aligning the beginning of a glyph to whole bytes or 4-byte blocks. The scanline is stored in the .raw part of the TSFT file (as opposed to the PC and Mac implementation, which uses a variable array in the .dat). Within a byte, the pixel order is low-to-high (see the TSFT page for an example). | |||
It is not 100% clear why the template checksum is different for PS2, even though the TSGA structure is essentially the same; the field at 0x0C seems to be an (unsigned) int32 in both cases. The runtime field at 0x10 is also an unsigned int32, rather than a bunch of flags. | |||