When requesting, for instance, a 75x85 map, the mapper will
now create a 75x85 map, instead of an 80x96 (or even 96x108)
map as it did before.
This new behavior is the default when using one of the options
--centergeometry or --cornergeometry.
In addition, both of these options will no longer shrink the
map, to remove rows or columns of empty blocks at the edges.
Previously, this behavior was enabled with --forcegeometry.
An option --geometrymode has been added as well, to tune
the interpretation of the geometry. It supports 4 flags:
- pixel: the requested geometry is interpreted with pixel
granularity. The map is not enlarged to include
entire map blocks.
- block: the requested geometry is interpreted with block
granularity. The map is enlarged with at most 15
nodes at each of the four edges, so that it
includes entire map blocks only.
- fixed: a map of the requested geometry is created (after
adjustmens for 'block' mode). Empty rows or
columns at the edges are not removed.
- shrink: Empty rows and columns at the map edges are
removed to generate the smallest picture possible.
Lastly, a new geometry syntax has been added, which is more
compatible with known syntax (i.e. X-Windows), and which
allows the offset to be optional. If the offset is omitted,
the picture defaults to be centered around 0,0.
`<width>x<height>[+|-<xoffset>+|-<yoffset>]`
For compatibility, the behavior of the option --geometry
was not changed. If (and only if) used before --geometrymode,
it enables block granularity and shrink.
The old option --forcegeometry is no longer documented,
but still recognised for compatibility.
Color mixing using alpha channel now spans map blocks.
So for instance, water is partly translucent to great depths.
Water (or other translucent material) now also becomes darker
with depth.
This is necessary, because libgd may fail, or print some
unintelligible message when these limits are reached.
Known limitations:
- libgd refuses to create images larger than approx INT_MAX (2^31-1)
pixels (a little over 46300x46300), even on 64-bit systems.
- on a 32-bit system, in practise, the largest size that can be
generated is a little over 24100x24100 pixels.
The colors file is now parsed line by line, which means
that parse failures on one line will not carry over to the next line.
When a line fails to parse, the rest of the file is no longer silently
ignored, but the error is reported, and just the failed line is ignored.
The net effect of making an image tiled, is that a grid is added
to the image, *without* obscuring part of the image with
grid lines: all pixel information is preserved. The lines
(aka borders) are added in-between the pixels of the image.
As a result, the image dimensions increase, and the image
may look slightly distorted. (a straight slanted line crossing
a tile border, will not look straight at the crossing).
Example:
Picture:
[ ]
[ H H III TTTTT H H EEEEE RRRR EEEEE ]
[ H H I T H H E R R E ]
[ HHHHH I T HHHHH EEE RRRR EEE ]
[ H H I T H H E R R E ]
[ H H III T H H EEEEE R R EEEEE ]
[ ]
Same picture with 10x5 tiles:
[ | | | | ]
[ H H II|I TTTT|T H H |EEEEE RRR|R EEEEE ]
[ H H I| T | H H |E R | R E ]
[ HHHHH I| T | HHHHH |EEE RRR|R EEE ]
[ H H I| T | H H |E R | R E ]
[----------|----------|----------|----------|----------]
[ H H II|I T | H H |EEEEE R | R EEEEE ]
[ | | | | ]
For a 100x100 map, the w and h parameters would have to be
specified as +99+99. This is not intuitive. Changed this,
so that +100+100 results in a 100x100 map.
Added the option to bulk load and cache entire world rows at
a time when using sqlite. Caching is implemented in the
database class this time around.
Enabled using --sqlite-cacheworldrow on the command line.
This is essentially re-introduces the database access strategy
that was used originally, but as an option.
Currently, one block is read at a time from the database.
The original behavior was to read and cache one entire world
row at a time, irrespective of whether or not only a (small)
subsection of the world was being mapped.
Under some circumstances, in particular if the entire world is
mapped or a relatively large percentage of it (blocks-wise), the
bulk loading and caching may outperform the one-by-one strategy,
even though it usually loads many more blocks than are actually
needed.
It seems that leveldb won't benefit from any kind of caching or
bulk loading of blocks, so none was implemented.
Leveldb does compile now. Still not tested on a database :-(
Improved the database statistics (printed with --verbose).
Node and map-block coordinates were mixed up, causing the min/max
vertical coordinate limitation to be broken.
The confusion was removed, and --min-y and --max-y now work as they
should.
