Tiles are used for text and maps. Tiles are dimensioned in units of cells. Each cell is 14x8 pixels.

• standard size fonts are 1x1 cells, or 14x8 pixels
• standard map tiles are 2x2 cells, or 28x16 pixels

Conditional assembly controls availability of some tile related commands.

Command	_pics=1	_pics=2
&AUX	✔	✔
&TILE	✔	✔
&CLEAR	✔	✔
&BANK		✔
&MAP		✔

The tile pixels are stored just as they are in the screen buffer. In particular, the high bit is not used. As a result, there is a 12.5% waste factor in the tile storage. This is tolerated in exchange for faster screen transfers. This also explains why cells are a multiple of seven pixels.

The tiler program TILE allows you to create tile sets. Starting with v0.1.0, the format of the file is

Offset	Value	Bytes
0	H = horizontal cells	1
1	V = vertical cells	1
2	tile 1 auxiliary page	H⨉V⨉8
2+H⨉V⨉8	tile 1 main page	H⨉V⨉8
2+2⨉H⨉V⨉8	tile 2 auxiliary page	H⨉V⨉8
2+3⨉H⨉V⨉8	tile 2 main page	H⨉V⨉8
etc.

The page data consists of the screen bytes for the tile in reverse memory order. The number of tiles can be worked out using N = (L-2)/(H*V*16), where L is the length of the file.

The v0.0.0 tiles can be converted using scripts/dev/upgradeTiles.py. This requires Python and a2kit.

Standard text is rendered by redirecting the normal print command to the DHGR screen. The redirection is done using &pr# with no argument (note ampersand). The redirection is undone using normal ProDOS methods (e.g. print chr$(4);"pr#3").

• This facility is specialized for fonts that are 1x1 tile sets.
• Issuing &pr# in immediate mode leads to a confusing interaction, not recommended.
• See the &aux ampersand for how to stash a font in auxiliary memory.
• Larger fonts can be created and rendered using &tile, but they cannot be used with print.

The mapper program MAP allows you to create an uncompressed map composed of tiles. Only 2⨉2 tiles are allowed in maps. The &map ampersand can display a sub-region of the map. DHRLIB does not deal with map compression. The idea is that higher level code will extract a submap from a large, possibly compressed map, in its own way. The submap can then be passed to DHRLIB for rendering. The uncompressed map format is as follows:

Offset	Value	Bytes
0	H = horizontal tiles	1
1	V = vertical tiles	1
2	N = north terrain	1
3	S = south terrain	1
4	E = east terrain	1
5	W = west terrain	1
6	interior terrain	H⨉V

The N,S,E,W values are the tile to display if the viewing window is outside the map data in the given direction. The interior terrain is stored as a sequence of rows, with one byte per tile. The byte value identifies the tile.

See the &bank ampersand for how to stash a tile set in bank switched memory for use by &map.

The MAP program provides for multi-level maps. The format is nothing more than the concatenation of single-level maps (including header). MAP assumes every level has the same dimensions, although nothing in DHRLIB requires this. In fact, there is no notion of multi-level maps in DHRLIB at all. To change levels you simply change the map pointer.

Map denizens are tiles that sit "on top" of a terrain tile. If the terrain code is negative DHRLIB will search the denizen buffer for a record with the given location. This record tells DHRLIB which tile to render in place of the terrain tile.

The denizen buffer consists of sorted denizen records. The record corresponding to denizen n (0-63 inclusive) is:

Offset	Value	Bytes
n*4+0	offset lo-byte	1
n*4+1	offset hi-byte	1
n*4+2	tile index	1
n*4+3	auxiliary data	1

The tile index gives the index to the tile that represents this denizen. The auxiliary data can be used for any other information about this denizen (likely an index into other records).

The offset idenitifes the location of the denizen as a byte-offset relative to the beginning of the map file. Denizen records must be sorted by offset in order for the denizen search to succeed.

The mapper will save any map with denizens in the following extended format:

Offset	Value	Bytes	Notes
0	0	1
1	version (1)	1
2	levels (L)	1
3	auxiliary count (A)	1	4-byte units
4	denizen count (D)	1	4-byte records
5	reserved (0)	3
8	packed levels	M=(H⨉V+6)⨉L
8+M	auxiliary buffer	A⨉4
8+M+A⨉4	denizens	D⨉4

This is easily distinguished from an ordinary map file by the leading 0. MAP does not create any auxiliary data, but will preserve it if it already exists.

DHRLIB will automatically maintain the denizen count, but other than that, it never parses the extended map. Instead, your BASIC code calculates addresses within it to be passed into DHRLIB.

There is a &scroll ampersand that can scroll an arbitrary screen window. It operates on cells. It is not recommended to use this for map scrolling. In fact, MAPLIB does not include it. Maps are scrolled by simply repainting the map window. While it is possible to make this operation faster and smoother by copying screen cells, the added complexity has, so far, not been worth it.