From Wiki of ZZT
Revision as of 19:20, 13 February 2021 by The Green Herring (talk | contribs) (byte)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
Text can display any character, but color choices are limited
Internal IDMultiple, used to encode background color:
  • 47 (0x2F): Blue
  • 48 (0x30): Green
  • 49 (0x31): Cyan
  • 50 (0x32): Red
  • 51 (0x33): Purple
  • 52 (0x34): Brown
  • 53 (0x35): Black
CharacterAny (determined by tile's color byte)
Default colorWhite foreground; element ID determines background
Other traits
Effect on movementwall
Uses ZZT-OOP color names?N/A

Text is a terrain type that can have any of the 256 characters. Its intended use is for putting text labels on a board's terrain.

Text is the only element that can display any character without the overhead of using a stat, which makes them useful for ZZT art. However, artistic usage is somewhat hampered by the fact that text can only use a fixed set of color combinations: if you want to write a sentence on the screen in a custom color (e.g., black on light gray), the only way to do it is to use objects.

Text is also the only element supported by the built-in editor that has no ZZT-OOP name: e.g., there is no way to change all text tiles to another element type.

Usage of terrain color byte

Text is stored differently than any other element. Internally, ZZT repurposes the element's color byte to store character data instead: this allows the full range of characters to be encoded without having to allocate extra space (in the form of stats) for each tile. Since the color byte is occupied with other data, the actual color info is encoded by having different element IDs for each color. The result is that text is technically not just one element, but several.

Side effects from this roundabout encoding are apparent in a couple of places:

  • Overwriting text (using #put or #become) will sometimes result in STK-colored elements. This is because those commands always interpret the color byte as a color: if you #put a gem onto a blue text "Z" (ASCII code 0x5A), you will get a green-on-dark-purple gem (color code 0x5A).
  • Unlike most elements, it is impossible to get arbitrary text colors from toolkits or external editors. This is not a matter of ZZT's internal editor being restrictive, but rather a limit imposed by the file format and the in-memory representation.

Text is also the only element supported by the built-in editor that has no ZZT-OOP name: e.g., there is no way to change all text tiles to another element type. This may also be a side effect of text having a unique encoding.

Unassigned element IDs

ZZT only officially supports the seven text colors which have assigned element IDs. However, it is possible to get a few additional colors by using IDs beyond the assigned range, as ZZT interprets all element IDs greater than 0x2E as text. The problem is that all these IDs are buggy because they cause ZZT to read past the end of its table of elements. Touching tiles with these IDs will crash ZZT, and many unassigned IDs will crash ZZT immediately, on the first tick.

Some known unassigned IDs and their text colors:

  • 54 (0x36): blinking white on black (0x8F)
  • 55 (0x37): blinking white on dark blue (0x9F)
  • 56 (0x38): blinking white on dark green (0xAF)
  • 57 (0x39): blinking white on dark cyan (0xBF)
  • 58 (0x3A): blinking white on dark red (0xCF)
  • 59 (0x3B): blinking white on dark purple (0xDF)
  • 60 (0x3C): blinking white on dark brown (0xEF)
  • 61 (0x3D): blinking white on light gray (0xFF)
  • 69 (0x45): white on light gray (0x7F)

It is impossible to choose the text foreground color because ZZT hard-codes it to be white. This means there are only 16 possible color combinations: the 7 text colors built into ZZT, and the 9 produced by the unassigned IDs above.