eu2 » TBL Files » lightmap.tbl

// C#
for ( int i=0; i<idCount; ++i ) {
	if ( idTable[i] <= Province.MaxID ) continue;

	ushort id = idTable[((idTable[i]>>9) & 63)-4];
	if( id > Province.MaxID )
		id = install.Provinces.TerraIncognita.ID;
	else {
		int river = (idTable[i]>>5) & 15;
		if ( river != InvalidAdjacency ) id = install.Provinces[id].GetNeighbor( river ).ID;

		idTable[i] = id;
	}
}

The processing of the special entries is done after the full list is read in.

Quadtree nodes
This part contains a tree representing the map image data. It is a list of bits specifying a quadtree structure, which is maximum 5 levels deep (not coincidentally, as 32 = 2^5).

The algorithm is actually very simple. It starts off at block level (level = 5, block size 32 pixels). It checks the first bit (and moves the bit pointer to the next one). If it's a 1, the block is divided into 4 smaller blocks, each half the size of the current block (thus 16 pixels). Recursively, the subblocks are processed too (in a bottomright » bottomleft » topright » topleft manner) by doing the same process on each of them. The level is decreased by 1 (as we're one level deeper). This process stops at level 1 (NOT level 0), which means that we're a 2-pixel resolution. At that level, 4 leafs are created (without a bit in the tree stream).
When the bit read is a 0, processing of the (sub)tree stops, and 1 leaf is registered.

In pseudo code, I'd describe it like this:

Proc ReadTree( level )
	bit = readNodeBit()
	moveToNextNodeBit()

	If bit is set Then
		If level > 1 Then
			addBranch()

			ReadTree( level - 1 )
			ReadTree( level - 1 )
			ReadTree( level - 1 )
			ReadTree( level - 1 )
		Else
			add4Leaves()
		End If
	Else
		addLeaf()
	End If
End Proc

This just reads in the tree. In effect, you have a tree structure with leafs at the bottom. The values in the parts below are ordered in a breath-first traversal (go as deep as you can in the tree, and start reading there, moving "from left to right" as you go).

Using this date to draw it to a surface is another matter. I'll do a seperate document about that!

Leaf Ownership entries
For each leaf in the quadtree, this part contains an ownership index into the id list at the beginning of the block. This is to identify each leaf with a province, which is necessary because the engine needs to know how to color each part of the map (for example, the different terrain types give each province a different color). Since the map data is just greyscale values (see the next part), the coloring must be applicable on a per province base.
Depending on the number of entries in the ID list, this part is formatted differently. As said before, each entry in this part is actually an index into the ID list, and it does not contain actual province values.

Leaf Color Entries
This is the simplest part of the whole block.
For each leaf in the quadtree, this part contains a 6-bit color value. These are encoded in sets of 4 entries, totaling 3 bytes each: 4x6 bits = 24 bits = 3x8 bits = 3 bytes.

The color values stored are greyscale values: they are actually offsets into a table generated from the colorscales.csv file, which is used to color the map accordingly. This allows the enging to use the same map data for the different views, by combining "lighting" values (hence the name, lightmap) with coloring.
The greyscale values are 6-bit, this means there are 64 variations of each color possible. This also explains the "63" index used in the colorscales.csv.

Some observations
The leaf count will always be a multiple of 4.
The upper limit of provinces is 256 (due to encoding in the leaf ownership part).