Most of the content of README.rst was moved to a separate
user manual, and to a build manual.
The README was simplified to provide just the most important
information.
The user manual was extensively reworked, and beautified with images.
--heightmap: generate the height map, in colors
--heightmap-grey: use shades of grey instead of colors
--sealevel <n>: define the sea level (below sea level is drawn in blue)
--heightmap-scale <f>: scale the heights by f (for the purpose of
color selection)
When generating a heightmap, a special colors file is needed,
that defines just the blocks that should be considered part
of the ground. That means that normally, any plants, special
nodes and water should not be included.
The option --tiles has two new possible values: 'block' and 'chunk'
'block' creates tiles corresponding to map blocks
'chunk' creates tiles corresponding to map chunks
(chunks are the unit of map generation).
An option --chunksize was added to manually override the chunk size.
As the best color for water depends on the rendering parameters
(i.e. the --drawalpha mode: none, average or cumulative), two
additional colors files are provided for these alternatives.
This new mode averages the colors of all transparent blocks, instead of
making the colors progressively darker and more opaque.
This 'average' mode is now the default when using --drawalpha. It can be
explicitly selected using --drawalpha=average. The old modes can be selected
using --drawalpha=cumulative[-darken].
It is recommended to change the colors of water as well. These are in a
separate patch.
As this comes with a significant performance penalty, this
feature must be enabled using the command-line option --drawair
For best results, the color of air should be fully transparent,
so that underlying nodes will override it.
This is useful to show invisible ('air' or 'invalid') nodes in blocks
that are in the database using a different color than blocks that are
not in the database (which will have no color at all, causing the
background color to show).
Minetestmapper can now be installed into a proper directory hierarchy
(instead of all files being dumped into /usr/local/. for instance.)
Non-hierarchical installation (or creation of a non-hierarchical archive)
is also still supported, and remains the default, for backwards compatibility.
Packaging on windows remains unchanged, due to lack of infrastructure :-)
A colors file can now specify other colors files, from which
additional node color specifications will be read. This allows, for
instance, using system-installed colors file for most colors,
and only overriding some of its colors in a custom colors file.
As a purpose of using a custom colors file may be to leave the colors
for some nodes undefined, it is now also possible to undefine a
previously defined node color (i.e. after reading another colors file
which defines a color for the node).
- Continue processing if libraries are not found (so that all missing
libraries are reported)
- Set compiler flags correctly if CMAKE_BUILD_TYPE is not set (fixes bug #0)
- Make CMAKE_BUILD_TYPE=Release the default
- Increase optimisation level for Release
Supported figures are points, lines, ellipses, rectangles
and text.
The figures' locations can be specified using either world
coordinates, or map coordinates.
In preparation for future changes.
New geometry and new coordinate syntax has been added as well:
Additional node coordinate formats:
<block>#[<node>]
<block>.[<node>]
Additional geometry formats:
<x1>,<y1>:<x2>,<y2>
<x>,<y>:<w>x<h>
Also: the old geometry behavior (block granularity and map shrinking)
is now enabled only if the old geometry format is used (for compatibility)
Values: 0: fully transparent, 255: fully opaque.
Note that this doesn't yield the expected color blending just
yet, due to libgd messing it up. (Seemingly, the libgd arc
drawing function draws some pixels repeatedly, resulting in a
more opaque circle than desired)
The colors.txt file can now be located:
- in the directory of the world being mapped
- in the user's private minetest directory ($HOME/.minetest)
- in the current directory as a last resort
The location can also be specified using a command-line option
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.
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 ]
[ | | | | ]
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).
adrido
Rogier
adrido
est31
Rogier-5
Sfan5
ShadowNinja
ShadowNinja
Miroslav Bendík