地図のピクセルは1バイト、そのうち2ビットが明るさ
61の基本色 × 4つの濃淡 = 16,384バイトの配列から生まれる244色。4つの濃淡のうち色本来の値は1つだけで、残り3つは86%、71%、53%に暗くされている。配列は128×128ピクセル分で、実際の最大バイト値は247です。
Minecraftの完成した地図は、ディスク上ではどれも同じ大きさです。すなわち、ちょうど16,384個の要素を持つcolorsバイト配列で、これは128 × 128にあたります。128ブロックを覆う大きさ0の地図でも、2,048ブロックを覆う大きさ4の地図でも同じです。ピクセル数が変わることはありません。地図アートに関するそれ以外のことは、すべてこの1つの事実から導かれます。
バイトは2つに分かれる
16,384個のバイトは、それぞれが色ではありません。基本色と濃淡が1つに詰め込まれたものです。
baseColorId = colorId >> 2 // 0–63
shadeIndex = colorId & 3 // 0–3つまり下位2ビットが明るさで、残りがどのブロックを見ているかを表します。基本色は61種類定義されており（id 0は透明／未探索の枠）、実際の地図が保持する最大のバイト値は61 × 4 + 3 = 247です。
61 × 4 = 244色。これが地図アートで使えるパレットのすべてです。61でも256でもありません。
色本来の値を持つ濃淡は1つだけ
4つの倍率は等間隔ではなく、そのうち1つは1.0です。
| 濃淡インデックス | 倍率 | パーセント表記 |
|---|---|---|
| 0 | 180 / 255 | 70.6% |
| 1 | 220 / 255 | 86.3% |
| 2 | 255 / 255 | 100% |
| 3 | 135 / 255 | 52.9% |
濃淡2は地図色そのもののRGBで、スケーリングされていません。色idごとに固定の値であり、ブロックのテクスチャからサンプリングされたものではありません。残り3つはそれを暗くしたもので、最も暗い濃淡3は明るさが半分をわずかに超える程度です。
階段状の地図アートが平坦なものとこれほど違って見えるのは、このためです。平坦な建築物は通常の濃淡（86%）しか生み出さないので、平坦な地図で使える色は61色です。高さを変えることで、あらゆるブロックの明るい濃淡と暗い濃淡が解放され、183色になります。パレットが広くなるわけではありません。新しい色相は手に入りません。値の深さが3倍になるのです。これはまさにディザリングが必要としているものです。4つ目の濃淡（53%）はブロックからは決して生み出されません。バイト形式の中に存在し、編集された地図ファイルだけが使います。
また、濃淡の並びは単調ではないことにも注意してください。インデックス3が最も暗く、最も明るいわけではありません。インデックスで並べ替えてグラデーションを期待すると、71%、86%、100%、53%となります。
大きさは面積を掛け算するが、解像度は決して変えない
scaleフィールドは0～4の値を取り、覆う範囲は一辺128 × 2^scaleブロックです。
| 大きさ | 覆うブロック数 | 地図の1ピクセル |
|---|---|---|
| 0 | 128 × 128 | 1ブロック |
| 1 | 256 × 256 | 2 × 2ブロック |
| 2 | 512 × 512 | 4 × 4ブロック |
| 3 | 1,024 × 1,024 | 8 × 8ブロック |
| 4 | 2,048 × 2,048 | 16 × 16ブロック — ちょうど1チャンク |
大きさ4の地図は、同じ16,384バイトを使いながら、大きさ0の地図の256倍の面積を覆います。地図アートを大きさ0で作らなければならない理由はまさにこれです。他のズーム倍率では、1ピクセルが複数ブロックの平均になり、丹念に配置した画像はリサンプリングされて消えてしまいます。
大きさ4の行は別の理由でも覚えておく価値があります。1ピクセルがちょうど1チャンクなので、最大ズームの地図は実用的なチャンクグリッドになります。
壊れたファイルにとってこれが意味するもの
地図ファイル（ワールドフォルダ内のdata/minecraft/maps/<id>.dat）のcolors配列が16,384バイトでない場合、それはピクセルが欠けた地図ではありません。ゲームは地図を読み込みますがピクセルを捨ててしまい、真っ白に表示します。中途半端な長さという形式は存在しません。配列は常にフルサイズで、未探索の領域は省略されるのではなく色id 0として保存されます。