OBD:TSFT: Difference between revisions

← Older edit

OBD:TSFT (view source)

Revision as of 19:58, 16 April 2026

45 bytes removed , Thursday at 19:58

m

PC = Win/Mac, consistent with rest of wiki; gave PC and PS2 sections their own subheaders

Iritscen

Bureaucrats, Interface administrators, Suppressors, Administrators

20,503

edits

@@ Line 1: / Line 1: @@
 {{OBD_File_Header | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Interface | align=center}}
+==PC implementation==
 [[Image:tsft_a.gif]]
@@ Line 40: / Line 40: @@
 {{OBDtr| 0x41C | offset   |FF00FF| 20 00 00 00 | 0x00000020 | offset of the pixel data in the .raw file }}
 |}
-;Differences between PS2 storage and PC/Mac storage
-*The PC and Mac TSFTs store pixel data in a variable-size array (number of elements announced at 0x41C, then 4 bytes per element). PS2 TSFTs instead store the pixel data in the .raw file, using the field at 0x41C to store the offset.
+==PS2 implementation==
-*PC and Mac TSFTs use a whole byte for every pixel, i.e. 256 shades of gray, which in theory allows for subtle antialiasing. (In practice the antialiasing of Oni's fonts is anything but subtle, and the engine further posterizes them from 8-bit to 4-bit when rendering text.) PS2 fonts use only 2 bits per pixel, i.e., only 4 degrees of brightness/opacity.
+*The PC TSFTs store pixel data in a variable-size array (number of elements announced at 0x41C, then 4 bytes per element). PS2 TSFTs instead store the pixel data in the .raw file, using the field at 0x41C to store the offset.
-*PC and Mac use a "black-on-white" representation of the font, with blank areas stored as 0xFF and fully opaque pixels as 0x00. PS2 uses "white-on-black", so a single opaque pixel in a row of four will be stored as 0x03, 0x0C, 0x30 or 0xC0.
+*PC TSFTs use a whole byte for every pixel, i.e. 256 shades of gray, which in theory allows for subtle antialiasing. (In practice the antialiasing of Oni's fonts is anything but subtle, and the engine further posterizes them from 8-bit to 4-bit when rendering text.) PS2 fonts use only 2 bits per pixel, i.e., only 4 degrees of brightness/opacity.
-*On PC and Mac, the pixel rows for a given glyph can span across several 4-byte array elements, but pixel data for a new glyph must always start at the first byte of an array element (glyph data in a PC or Mac TSGA is indexed by TSFT array element, not by pixel). Therefore, on PC or Mac, if a glyph has, say, 33 8-bit pixels, then there will be 33 bytes of actual storage, spanning 4 whole array elements and 1 byte of a 5th element, and the rest of the 5th element (3 bytes) will be padded (typically with "DE AD" bytes). Inside the PS2 .raw file, the storage is not padded or aligned in any way, and the indexation for each glyph (from TSGA) is by pixel, i.e. by quarter-of-a-byte.
+*The PC engine uses a "black-on-white" representation of the font, with blank areas stored as 0xFF and fully opaque pixels as 0x00. PS2 uses "white-on-black", so a single opaque pixel in a row of four will be stored as 0x03, 0x0C, 0x30 or 0xC0.
-*Same as on PC and Mac, pixel rows are stored top-to-bottom, and each row is stored left-to-right, using lower bits first. For example, the 4x11 bitmap for a 7pt regular double-quote character ("), would be encoded as the following 11 bytes if it was byte-aligned:
+*In PC Oni, the pixel rows for a given glyph can span across several 4-byte array elements, but pixel data for a new glyph must always start at the first byte of an array element (glyph data in a PC TSGA is indexed by TSFT array element, not by pixel). Therefore, on PC, if a glyph has, say, 33 8-bit pixels, then there will be 33 bytes of actual storage, spanning 4 whole array elements and 1 byte of a 5th element, and the rest of the 5th element (3 bytes) will be padded (typically with "DE AD" bytes). Inside the PS2 .raw file, the storage is not padded or aligned in any way, and the indexation for each glyph (from TSGA) is by pixel, i.e. by quarter-of-a-byte.
+*Same as on PC, pixel rows are stored top-to-bottom, and each row is stored left-to-right, using lower bits first. For example, the 4x11 bitmap for a 7pt regular double-quote character ("), would be encoded as the following 11 bytes if it was byte-aligned:
   byte 0x00 (00000000 low-to-high)
   byte 0x33 (11001100 low-to-high)