OBD:TSFT: Difference between revisions

From OniGalore
Jump to navigation Jump to search
m (wording, much better definition links)
m (changed family)
 
(3 intermediate revisions by one other user not shown)
Line 1: Line 1:
{{OBD_File_Header | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Global | align=center}}
{{OBD_File_Header | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Interface | align=center}}




[[image:tsft_a.gif]]
[[Image:tsft_a.gif]]




[[image:tsft_m.gif]]
[[Image:tsft_m.gif]]




[[image:tsft_e.gif]]
[[Image:tsft_e.gif]]




Line 37: Line 37:
{{OBDtr| 0x420 | int32    |C0C0C0| FF FF FF FF | 255,255,255,255 | the first 4 pixels (all white) of the first used glyph }}
{{OBDtr| 0x420 | int32    |C0C0C0| FF FF FF FF | 255,255,255,255 | the first 4 pixels (all white) of the first used glyph }}
{{OBDtr| ...  | ...      |C0C0C0|    ...    | ...  | the rest of the pixel data }}
{{OBDtr| ...  | ...      |C0C0C0|    ...    | ...  | the rest of the pixel data }}
{{OBDtrBK|Alternative pixel storage used by PS2 implementation}}
{{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.
*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.
*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.
*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.
*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:
byte 0x00 (00000000 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
However, the actually stored pixel data for (") is shifted by half a byte because of the previous two glyphs, which are both 3x11 and take up 33 quarter-bytes each. Therefore the actual storage for (") looks like this:
byte 0x?0 (....0000 low-to-high, lower 4 bits belong to previous glyph)
byte 0x30 (00001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x03 (11000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x0? (0000.... low-to-high, upper 4 bits belong to next glyph)




{{OBD_File_Footer | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Global}}
 
{{OBD_File_Footer | type=TSFT | prev=TSFL | next=TSGA | name=Font | family=Interface}}


{{OBD}}
{{OBD}}

Latest revision as of 01:46, 7 December 2023

ONI BINARY DATA
TSFL << Other file types >> TSGA
TSFT : Font
switch to XML:TSFT page
Overview @ Oni Stuff
OBD.png


Tsft a.gif


Tsft m.gif


Tsft e.gif


Offset Type Raw Hex Value Description
0x000 res_id 01 03 00 00 3 00003-.TSFT
0x004 lev_id 01 00 00 00 0 level 0
0x008 dead[6] AD DE dead not used
0x00E int16 07 00 7 font size in points
0x010 int32 01 00 00 00 1 font option; the following options are possible:
0 - normal font
1 - bold font
2 - italic font
0x014 int16 09 00 9 ascender height
0x016 int16 02 00 2 descender height
0x018 int16 02 00 2 leading height
0x01a int16 02 00 2 ignored
Room for 256 TSGA links (only the first one is typically used for Western languages)
0x01C link 01 04 00 00 4 link to 00004-.TSGA (glyph array for character codes 0-255)
0x020 link 00 00 00 00 0 unused
... ... ... ... ...
0x418 link 00 00 00 00 0 unused
Pixel data for the glyphs (8-bit intensities for four pixels at a time, stored as 32-bit integers)
0x41C int32 4F 0E 00 00 3663 array size (one element has a length of 4 bytes)
0x420 int32 FF FF FF FF 255,255,255,255 the first 4 pixels (all white) of the first used glyph
... ... ... ... the rest of the pixel data
Alternative pixel storage used by PS2 implementation
0x41C offset 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.
  • 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.
  • 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.
  • 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.
  • 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:
byte 0x00 (00000000 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)

However, the actually stored pixel data for (") is shifted by half a byte because of the previous two glyphs, which are both 3x11 and take up 33 quarter-bytes each. Therefore the actual storage for (") looks like this: 

byte 0x?0 (....0000 low-to-high, lower 4 bits belong to previous glyph)
byte 0x30 (00001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x33 (11001100 low-to-high)
byte 0x03 (11000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x00 (00000000 low-to-high)
byte 0x0? (0000.... low-to-high, upper 4 bits belong to next glyph)


ONI BINARY DATA
TSFL << Other file types >> TSGA
TSFT : Font
Interface file
Retrieved from "https://wiki.oni2.net/w/index.php?title=OBD:TSFT&oldid=41877"