1,079
edits
Difference between revisions of "SCUMM/Technical Reference/Charset resources"
Jump to navigation
Jump to search
SCUMM/Technical Reference/Charset resources (view source)
Revision as of 15:16, 26 May 2005
, 15:16, 26 May 2005→V4 charset format
| Line 12: | Line 12: | ||
=== V4 charset format === | === V4 charset format === | ||
The header looks as follows: | |||
{| border="1" cellpadding="2" cellspacing="0" | |||
!Size !! Type !! Description | |||
|- | |||
|2 || || unknown | |||
|- | |||
|15 || bytes || colour map | |||
|- | |||
|1 || byte || number of bits per pixel | |||
|- | |||
|1 || byte || height of the font | |||
|- | |||
|2 || short (LE) || number of characters | |||
|- | |||
|1024 || 256*quad LE || character data offsets | |||
|} | |||
Character glyphs may be 1, 2, 4 or 8 bits per pixel, and can be masked. | |||
The colour map contains the colours each pixel of the character glyph | |||
is drawn as. Pixel value 0 is used for transparency; the other values are | |||
mapped using the color map in the header. | |||
The character data pointers contain the offset, relative to the byte | |||
after the end of the colour map (byte 29), of the character data. | |||
This can be 0 if that particular character is not encoded in the character | |||
set. The character data itself is formatted as follows: | |||
{| border="1" cellpadding="2" cellspacing="0" | |||
!Size !! Type !! Description | |||
|- | |||
|1 || byte || width of character | |||
|- | |||
|1 || byte || height of character | |||
|- | |||
|1 || byte || X offset | |||
|- | |||
|1 || byte || Y offset | |||
|- | |||
|many || bytes... || glyph data bitstream | |||
|} | |||
The X and Y offsets are added to the screen coordinates of the top-left | |||
corner of the glyph before drawing. This is useful for, say, shadowed | |||
text. Needless to say, glyphs don't all have to be the same size, | |||
although in all the examples I have they are the same height. | |||
The data bitstream encodes the pixels in the glyph in left-to-right, | |||
top-to-bottom order. Multiple pixels are encoded per byte. The pixels | |||
are arranged in big-endian format; so, the first pixel in the stream | |||
is in the top bits of the first data byte; then the bits below that; | |||
and so on. For example, at one bit per pixel: | |||
<pre> | |||
Bit position: 7 0 7 0 ... | |||
Words of data: 01234567 89ABCDEF | |||
</pre> | |||
At two bits per pixel: | |||
<pre> | |||
Bit position: 7 0 7 0 ... | |||
Words of data: 00112233 44556677 | |||
</pre> | |||
And at four bits per pixel: | |||
<pre> | |||
Bit position: 7 0 7 1 ... | |||
Words of data: 00001111 22223333 | |||
</pre> | |||
=== V5/V6 charset format === | === V5/V6 charset format === | ||
Like all other resources in V5 and later, the charset data is stored in a chunk, in this case a 'CHAR' chunk. | Like all other resources in V5 and later, the charset data is stored in a chunk, in this case a 'CHAR' chunk. The header looks as follows: | ||
{| border="1" cellpadding="2" cellspacing="0" | {| border="1" cellpadding="2" cellspacing="0" | ||
!Size !! Type !! Description | !Size !! Type !! Description | ||
| Line 22: | Line 94: | ||
|8 || chunk tag || CHAR chunk tag | |8 || chunk tag || CHAR chunk tag | ||
|- | |- | ||
| | |6 || || unknown | ||
|- | |- | ||
|15 || bytes || colour map | |15 || bytes || colour map | ||
| Line 35: | Line 105: | ||
|} | |} | ||
The | Character glyphs may be 1, 2, 4 or 8 bits per pixel, and can be masked. | ||
The colour map contains the colours each pixel of the character glyph | |||
is drawn as. Pixel value 0 is used for transparency; the other values are | |||
mapped using the color map in the header. | |||
The character data pointers contain the offset, relative to the byte | |||
after the end of the colour map (byte 29), of the character data. | |||
This can be 0 if that particular character is not encoded in the character | |||
set. The character data itself is formatted as follows: | |||
{| border="1" cellpadding="2" cellspacing="0" | |||
!Size !! Type !! Description | |||
|- | |||
|1 || byte || width of character | |||
|- | |||
|1 || byte || height of character | |||
|- | |||
|1 || byte || X offset | |||
|- | |||
|1 || byte || Y offset | |||
|- | |||
|many || bytes... || glyph data bitstream | |||
|} | |||
The X and Y offsets are added to the screen coordinates of the top-left | |||
corner of the glyph before drawing. This is useful for, say, shadowed | |||
text. Needless to say, glyphs don't all have to be the same size, | |||
although in all the examples I have they are the same height. | |||
The data bitstream encodes the pixels in the glyph in left-to-right, | |||
top-to-bottom order. Multiple pixels are encoded per byte. The pixels | |||
are arranged in big-endian format; so, the first pixel in the stream | |||
is in the top bits of the first data byte; then the bits below that; | |||
and so on. For example, at one bit per pixel: | |||
<pre> | |||
Bit position: 7 0 7 0 ... | |||
Words of data: 01234567 89ABCDEF | |||
</pre> | |||
At two bits per pixel: | |||
<pre> | |||
Bit position: 7 0 7 0 ... | |||
Words of data: 00112233 44556677 | |||
</pre> | |||
And at four bits per pixel: | |||
<pre> | |||
Bit position: 7 0 7 1 ... | |||
Words of data: 00001111 22223333 | |||
</pre> | |||
=== NUT (V7 & V8) charset format === | === NUT (V7 & V8) charset format === | ||
TODO | TODO | ||