OBD:TSGA: Difference between revisions

OBD:TSGA (view source)

Revision as of 19:37, 19 February 2022

54 bytes removed , 19 February 2022

m

wording; linking to OBD:Text encoding

Iritscen

Bureaucrats, Interface administrators, Administrators

18,700

edits

@@ Line 2: / Line 2: @@
-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-style encoding table:
-*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; each of these elements has a glyph (including the not-quite-printable "Delete" character, 127)
+*the next 96 symbols (32 to 127) correspond to standard ASCII
-*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) is filled with non-standard punctuation and non-Latin characters
-**in Western European versions (and in some English versions), there are characters with diacritics (extended Latin)
-**in Eastern European versions (e.g., Russian), Cyrillic characters are provided instead of extended Latin
+"Non-Latin" refers to European characters which use diacritics or to Cyrillic characters; the exact character set varies by language version of the game. Asian localizations of Oni use their own extended encoding system and glyph data in place of Oni's. See [[OBD:Text encoding]] for details on the encoding systems and the available characters in each language version.
+----
 [[image:tsga_a.gif]]
@@ Line 31: / Line 32: @@
-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. 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 in use and the 8-bit pixels are either fully black or fully white).
-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.
+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.