Difference between revisions of "Text compression"

From Nesdev wiki
Jump to: navigation, search
(Bisqwit's ppu_read_buffer test (NES): Forms a DAFSA; also the implementation I made for RFK)
(change Wikipedia links to use interwiki syntax; add Huffword and disadvantages of LZ)
Line 6: Line 6:
 
reserved to denote references to a "dictionary". If the byte falls into this range,
 
reserved to denote references to a "dictionary". If the byte falls into this range,
 
a string is copied from the dictionary rather than the byte being copied verbatim.
 
a string is copied from the dictionary rather than the byte being copied verbatim.
 +
It could be considered the textual equivalent of metatiles in scrolling maps.
 
As this compression technique does not require knowledge of past data,
 
As this compression technique does not require knowledge of past data,
 
it is very easy to implement on machines having little memory like the NES.
 
it is very easy to implement on machines having little memory like the NES.
Line 12: Line 13:
 
itself may contain references to other dictionary strings.
 
itself may contain references to other dictionary strings.
  
Dual-tile encoding, or DTE for short, is a special case of dictionary compression. It is also known as [https://en.wikipedia.org/wiki/Byte_pair_encoding byte-pair encoding], or digram coding.
+
Dual-tile encoding, or DTE for short, is a special case of dictionary compression. It is also known as [[wikipedia:Byte pair encoding|byte-pair encoding]], or digram coding.
 
In this case, the dictionary strings are all two bytes long.
 
In this case, the dictionary strings are all two bytes long.
  
Line 137: Line 138:
 
==== Huffman coding ====
 
==== Huffman coding ====
  
A special case of variable-bit encodings is [https://en.wikipedia.org/wiki/Huffman_coding Huffman coding].  
+
A special case of variable-bit encodings is [[wikipedia:Huffman coding|Huffman coding]].
 +
Huffman coding defines the optimal coding for a given set of symbols based on a table of frequencies that each symbol is used.
  
Huffman coding defines the optimal coding for a given character set based on a table of frequencies that each character is used.
+
When combined with static dictionary coding, the technique is called [https://pineight.com/mw/?title=Huffword Huffword].
  
 
==== Arithmetic coding ====
 
==== Arithmetic coding ====
Line 146: Line 148:
 
is represented by a range of binary fractions rather than a particular number of bits.
 
is represented by a range of binary fractions rather than a particular number of bits.
 
As arithmetic coding was covered by a number of patents up to 1993, and it is calculation intensive,
 
As arithmetic coding was covered by a number of patents up to 1993, and it is calculation intensive,
chances are no game uses it, unless part of e.g. LZMA compression, which was released in 1999.
+
chances are no NES game uses it.
 +
However, on the Super NES, the S-DD1 and SPC7110 coprocessors implement a mathematical model that approximates arithmetic coding under license.
 +
And by 1999, a design-around called "range coding" was discovered, leading to LZMA compression.
  
 
== LZ based methods ==
 
== LZ based methods ==
 +
LZ77 operates based on references to previous decompressed data.
 +
Decompression requires that either the previous decompressed data be readable
 +
or that a sliding window of previous data be kept in RAM.
 +
This isn't very efficient on the NES for two reasons:
 +
the CPU is connected to only 2K of RAM (plus whatever is in the cartridge),
 +
and VRAM can be accessed only during vblank.
 +
 +
Lempel-Ziv methods are incapable of efficient random access on a low-RAM system.
 +
Random access to an LZ77 or LZ78 stream works in one of three ways:
 +
* Decompress from the beginning to retrieve a substring. This is time-inefficient for the decompressor.
 +
* Compress each substring independently. As LZ77 relies on correlation within a string, this makes the compressed data larger.
 +
* Buffer the entire decompressed data in RAM. This requires more memory in the decompressor, but the tradeoff may work well on a platform with more RAM, such as the Commodore 64, Genesis, Super NES, or Game Boy Color.
 +
 +
:''See also: [[Tile compression#LZSS]]''

Revision as of 11:09, 29 April 2016

Text compression refers to techniques that allow fitting more text data into a smaller space.

Dictionary compression and DTE

Dictionary compression is a technique where part of the character set is reserved to denote references to a "dictionary". If the byte falls into this range, a string is copied from the dictionary rather than the byte being copied verbatim. It could be considered the textual equivalent of metatiles in scrolling maps. As this compression technique does not require knowledge of past data, it is very easy to implement on machines having little memory like the NES.

Sometimes the compression may be applied recursively, where the dictionary string itself may contain references to other dictionary strings.

Dual-tile encoding, or DTE for short, is a special case of dictionary compression. It is also known as byte-pair encoding, or digram coding. In this case, the dictionary strings are all two bytes long.

Example implementations:

Simon's Quest (NES)

In Simon's Quest (NES) (all versions), the font is 252 symbols long, although only a small part of that is actual text symbols used in dialog text.

Value Meaning
00–FB Print this symbol.
FC Denotes the end of a substring. Restores the string pointer saved by opcode FD.
FD Save current string pointer. The next byte determines the string number; this number will be used to calculate the new string pointer. Interpreting will continue from that address.
FE Newline.
FF End of text. If used in a substring, will not return to the main string. A string that ends in FD can omit the trailing FF, if the substring ends in FF.

Dictionary strings are arbitrary length. There is room for only one saved string pointer, so substrings can not refer to other substrings, unless it is to terminate the entire string. The substring mechanism is used in the Japanese diskette version of the game. The cartridge versions of the game also support this mechanism, even though the actual text data does not utilize it.

Chrono Trigger (SNES)

In Chrono Trigger (SNES) (all versions), the font is 768 symbols long, but a significant number of those symbols can not be printed.

Value Meaning
00 End of string.
01 Read next byte; print symbol byte+0x100.
02 Read next byte; print symbol byte+0x200.
03–20 Various text effects, references to item tables, and references to party member names.
21–xx Reference to a dictionary string. xx is a compile-time constant that determines the length of the dictionary. This number is 0x9F in the USA version and 0x3F in the Japanese version.
xx+1–FF Print this symbol.

Dictionary strings have a length limit of 255 bytes. They are not applied recursively. The dictionary strings are stored in length-data format without an end delimiter.

Bisqwit's ppu_read_buffer test (NES)

In Bisqwit's emulator test ROM ppu_read_buffer ([1]) the font is 128 symbols long, and in addition to the alphabet it includes some pre-rendered substrings in variable-width font. The ROM uses a combination of DTE and dictionary for text compression. For DTE, the compression is applied recursively, in both DTE bytes. Additionally the string may contain a jump label to another string, which forms a DAFSA that allows the reuse of the same string suffix in different test descriptions.

Value Meaning
00 End of string.
01–80 Print this symbol. After printing, if the stack pointer is wrong, pop a byte and interpret it rather than loading the next byte from the string.
81–FE Push DTE_TABLE1[n-0x81] in stack, and interpret DTE_TABLE0[n-0x81].
FF A 16-bit word follows. This word is loaded as a new string pointer and loading continues from that address. The old string pointer is not saved.

Damian Yerrick's robotfindskitten (NES)

This implementation of wikipedia:robotfindskitten contains a compressor written in Python and a 6502 decompressor. Comments in the compressor (dte.py) refer to the method as "digram tree encoding" for two reasons: to emphasize its recursive nature and because code units aren't "tiles", especially when displayed with a proportional font. It stores its stack separately from the machine stack so that in theory, a string can be decompressed a character at a time. The overall format (to be described) is similar to Bisqwit's but without the suffix reuse capability.

Bitrate reduction methods

Fixed-bit encoding

When the character set is small, such as 64 characters at most, strings could be encoded in a bitstream that packs 6 bits per character rather than 8 bits per character. This results in 20 % reduction of data size.

Main article: Fixed Bit Length Encoding

Variable-bit encodings

In variable-bit encodings different symbols are stored in different number of bits.

Example code in C for storing and retrieving variable-bit length integers:

#include <limits.h> // CHAR_BIT

void PutBits(void* memory, unsigned* bitpos, unsigned long V, unsigned nbits)
{
    unsigned char* buffer = (unsigned char*)(memory);
    while(nbits > 0)
    {
        unsigned bytepos = *bitpos/CHAR_BIT, bits_remain = CHAR_BIT-*bitpos%CHAR_BIT, bits_taken = CHAR_BIT-bits_remain;
        unsigned bits_to_write = std::min(nbits, bits_remain);
        unsigned value_mask     = (1 << bits_to_write)-1;
        unsigned value_to_write = V & value_mask;
        buffer[bytepos] = (buffer[bytepos] & ~(value_mask << bits_taken)) | (value_to_write << bits_taken);
        V >>= bits_to_write;
        nbits  -= bits_to_write;
        *bitpos += bits_to_write;
    }
}

unsigned long GetBits(const void* memory, unsigned* bitpos, unsigned nbits)
{
    const unsigned char* buffer = (const unsigned char*)(memory);
    unsigned long result = 0, shift=0;
    while(nbits > 0)
    {
        unsigned bytepos = *bitpos/CHAR_BIT, bits_remain = CHAR_BIT-*bitpos%CHAR_BIT, bits_taken = CHAR_BIT-bits_remain;
        unsigned bits_to_take = std::min(nbits, bits_remain);
        unsigned v = (buffer[bytepos] >> bits_taken) & ((1 << bits_to_take)-1);
        result |= v << shift;
        shift += bits_to_take;
        nbits -= bits_to_take;
        *bitpos += bits_to_take;
    }
    return result;
}

Ideally, you would store common symbols using few bits and infrequent symbols using more bits. Which brings us to…

Huffman coding

A special case of variable-bit encodings is Huffman coding. Huffman coding defines the optimal coding for a given set of symbols based on a table of frequencies that each symbol is used.

When combined with static dictionary coding, the technique is called Huffword.

Arithmetic coding

Huffman coding is also a special case of arithmetic coding. In arithmetic coding, each symbol is represented by a range of binary fractions rather than a particular number of bits. As arithmetic coding was covered by a number of patents up to 1993, and it is calculation intensive, chances are no NES game uses it. However, on the Super NES, the S-DD1 and SPC7110 coprocessors implement a mathematical model that approximates arithmetic coding under license. And by 1999, a design-around called "range coding" was discovered, leading to LZMA compression.

LZ based methods

LZ77 operates based on references to previous decompressed data. Decompression requires that either the previous decompressed data be readable or that a sliding window of previous data be kept in RAM. This isn't very efficient on the NES for two reasons: the CPU is connected to only 2K of RAM (plus whatever is in the cartridge), and VRAM can be accessed only during vblank.

Lempel-Ziv methods are incapable of efficient random access on a low-RAM system. Random access to an LZ77 or LZ78 stream works in one of three ways:

  • Decompress from the beginning to retrieve a substring. This is time-inefficient for the decompressor.
  • Compress each substring independently. As LZ77 relies on correlation within a string, this makes the compressed data larger.
  • Buffer the entire decompressed data in RAM. This requires more memory in the decompressor, but the tradeoff may work well on a platform with more RAM, such as the Commodore 64, Genesis, Super NES, or Game Boy Color.
See also: Tile compression#LZSS