OniGalore

OBD:TSGA: Difference between revisions

OBD Discussion

OBD:TSGA (view source)

Revision as of 01:47, 7 December 2023

1,438 bytes added ,  7 December 2023
m
changed family
mNo edit summary
m (changed family)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{OBD_File_Header | type=TSGA | prev=TSFT | next=TStr | name=Glyph Array | family=Global | align=center}}
{{OBD_File_Header | type=TSGA | prev=TSFT | next=TStr | name=Glyph Array | family=Interface | align=center}}




Every TSGA file contains 256 elements of 20 bytes each, thus takes up 5120 bytes without the header. Together with the 8-byte header and 32-byte padding, each TSGA takes up 5152 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 a more or less standard ASCII encoding table:
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 complete zero.
*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 printable ASCII; these elements all have a glyph (including the nont-quite-printable "Delete" character, 127)  
*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 filled with non-standard punctuation and characters other than basic Latin:
*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.
**in Western European versions (and in some English versions), there are characters with diacritics (extended Latin)
The code page is not the same for all Western Oni versions.
**in Eastern European versions (e.g., Russian), Cyrillic characters are provided instead of extended Latin


[[image:tsga_a.gif]]
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.
 
 
----
[[Image:tsga_a.gif]]




Line 31: Line 36:




A glyph is basically a monochrome bitmap width * height pixels in size. Each pixel is stored in one byte in the [[OBD:TSFT|TSFT]] file (fonts are antialiased so shades of gray are needed rather than storing each pixel in one bit; although for the smallest font size there is no antialiasing and the 8-bit pixels are either fully black or fully white).
A glyph is basically a grayscale bitmap which is (width * height) pixels in size. The [[OBD:TSFT|TSFT]] file stores each pixel as a byte, with 256 degrees of brightness/opacity, which in theory allows for rather subtle antialiasing. In practice, for the smallest font size there is no antialiasing at all (the 8-bit pixels are either fully black or fully white, and are suitable for 1-bit storage), and larger font sizes actually use only 17 degrees of brightness/opacity - from 0xFF to 0x0F, and then 0x00 - which the engine further posterizes to proper 4-bit when rendering.
 
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).


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. intermediate rows of a glyph 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, i.e., the first row of a glyph is necessarily aligned on a 4-byte multiple. The end of a glyph is padded with 0xDEAD.
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 ("cell pointer"), rather than a bunch of flags.




{{OBD_File_Footer | type=TSGA | prev=TSFT | next=TStr | name=Glyph Array | family=Global}}
{{OBD_File_Footer | type=TSGA | prev=TSFT | next=TStr | name=Glyph Array | family=Interface}}


{{OBD}}
{{OBD}}
Retrieved from "https://wiki.oni2.net/Special:MobileDiff/33586...41878"