minetest-mapper-cpp/README.rst

347 lines
9.6 KiB
ReStructuredText
Raw Normal View History

2012-09-02 10:46:12 -07:00
Minetest Mapper C++
===================
2013-08-14 12:44:03 -07:00
A port of minetestmapper.py to C++ from https://github.com/minetest/minetest/tree/master/util
2012-09-02 10:46:12 -07:00
Requirements
------------
* libgd
* sqlite3 (enabled by default, set ENABLE_SQLITE3=0 in CMake to disable)
* leveldb (optional, set ENABLE_LEVELDB=1 in CMake to enable leveldb support)
* hiredis (optional, set ENABLE_REDIS=1 in CMake to enable redis support)
2012-09-02 10:46:12 -07:00
Compilation
-----------
Plain:
2012-09-02 10:50:28 -07:00
::
2012-09-02 10:52:12 -07:00
2012-09-02 10:46:12 -07:00
cmake .
make
With levelDB and Redis support:
::
cmake -DENABLE_LEVELDB=true -DENABLE_REDIS=true .
make
Cmake variables:
^^^^^^^^^^^^^^^^
ENABLE_SQLITE3:
Enable sqlite3 backend support (on by default)
ENABLE_LEVELDB:
Enable leveldb backend support (off by default)
ENABLE_REDIS:
Enable redis backend support (off by default)
ENABLE_ALL_DATABASES:
Enable support for all backends (off by default)
CMAKE_BUILD_TYPE:
Type of build: 'Release' or 'Debug'. Defaults to 'Release'.
2012-09-02 10:46:12 -07:00
Usage
-----
2013-08-14 12:44:03 -07:00
Binary `minetestmapper` has two mandatory paremeters, `-i` (input world path)
2012-09-02 10:46:12 -07:00
and `-o` (output image path).
2012-09-02 10:50:28 -07:00
::
2012-09-02 10:52:12 -07:00
2013-08-14 12:44:03 -07:00
./minetestmapper -i ~/.minetest/worlds/my_world/ -o ~/map.png
2012-09-02 10:46:12 -07:00
Parameters
^^^^^^^^^^
version:
Print version ID of minetestmapper.
colors <file>:
Filename of the color definition file to use.
By default, a file 'colors.txt' is used, which may be located:
* In the directory of the world being mapped
* In the directory two levels up from the directory of the world being mapped,
provided that directory contains a file 'minetest.conf'
* In the user's private directory ($HOME/.minetest)
* For compatibility, in the current directory as a last resort.
This causes a warning message to be printed.
If the colors file contains duplicate entries for the same node,
one with alpha = 255, or absent, and one with alpha < 255, the former
is used without 'drawalpha', and the latter is used with 'drawalpha':
::
# Entry that is used without 'drawalpha':
default:water-source 39 66 106
# Entry that is used with 'drawalpha':
default:water-source 78 132 212 64 224
2012-09-02 10:46:12 -07:00
bgcolor:
Background color of image, `--bgcolor #ffffff`
scalecolor:
Color of scale, `--scalecolor #000000`
playercolor:
Color of player indicators, `--playercolor #ff0000`
An alpha value can be specified, but due to a bug in the
drawing library, it will not have the desired effect.
2012-09-02 10:46:12 -07:00
origincolor:
Color of origin indicator, `--origincolor #ff0000`
An alpha value can be specified, but due to a bug in the
drawing library, it will not have the desired effect.
2012-09-02 10:46:12 -07:00
drawscale:
Draw tick marks, `--drawscale`
drawplayers:
Draw player indicators, `--drawplayers`
draworigin:
Draw origin indicator, `--draworigin`
drawalpha:
Allow blocks to be drawn with transparency, `--drawalpha`
2014-03-05 09:06:05 -08:00
noshading:
Don't draw shading on nodes, `--noshading`
min-y:
Don't draw nodes below this y value, `--min-y -25`
max-y:
Don't draw nodes above this y value, `--max-y 75`
2014-03-05 12:41:27 -08:00
backend:
Use specific map backend, supported: auto, sqlite3, leveldb, redis, `--backend leveldb`
By default, the backend is 'auto', i.e. it is determined from the backend
setting in the world's world.mt file (if found).
2014-03-05 12:41:27 -08:00
centergeometry <geometry>:
(see below, under 'geometry')
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
cornergeometry <geometry>:
(see below, under 'geometry')
geometry <geometry>:
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
Limit the part of the world that is included in the map.
2012-11-24 10:25:13 -08:00
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
<geometry> has one of the formats:
<width>x<height>[<+|-xoffset><+|-yoffset>] (dimensions & corner)
<xoffset>,<yoffset>+width+height (corner & dimensions)
<xcenter>,<ycenter>:widthxheight (center & dimensions)
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
<xcorner1>,<ycorner1>:<xcorner2>,<ycorner2>
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
The old/original format is also supported:
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
<xoffset>:<yoffset>+width+height (corner & dimensions)
For 'cornergeometry', the offsets ([xy]offset or [xy]center) will
be at the lower-left corner of the image (offsets increase from left
to right, and from bottom to top).
For 'centergeometry', the offsets ([xy]offset or [xy]center) will be
in the center of the image.
For plain 'geometry', the offsets will be at the corner, or in
the center, depending on the geometry format.
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
If the offsets are not specified (with the first format),
the map is centered on the center of the world.
By default, the geometry has pixel granularity, and a map of
exactly the requested size is generated.
*Compatibility mode*:
If the *first* geometry-related option on the command-line
is `--geometry`, *and* if the old format is used, then for
compatibility, the old behavior is default instead (i.e.
block granularity, and a smaller map if possible). Block
granularity is also enabled when the obsolete (and otherwise
undocumented) option '--forcegeometry' is found first.
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
Examples:
`--geometry 10x10-5-5`
`--geometry 100,100:500,1000`
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
`--cornergeometry 50x50+100+100`
`--centergeometry 1100x1300+1000-500`
`--geometry 1100x1300`
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
geometrymode pixel,block,fixed,shrink:
Specify how the geometry should be interpreted. One or
more of the flags may be used, separated by commas or
spaces. In case of conflicts, the last flag takes
precedence.
When using space as a separator, make sure to enclose
the list of flags in quotes!
geometrymode pixel:
Interpret the geometry specification with pixel granularity,
as opposed to block granularity (see below).
A map of exactly the requested size is generated (after
adjustments due to the 'shrink' flag).
geometrymode block:
Interpret the geometry specification with block granularity.
The requested geometry will be extended so that the map does
not contain partial map blocks (of 16x16 nodes each).
At *least* all pixels covered by the geometry will be in the
map, but there may be up to 15 more in every direction.
geometrymode fixed:
Generate a map of the requested geometry, even if part
or all of it would be empty.
*NOTE*: If this flag is used, and no actual geometry is
specified, this would result in a maximum-size map (65536
x 65536), which is currently not possible, and will fail,
due to a bug in the drawing library.
Make the geometry pixel-accurate instead of map-block accurate 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.
2014-04-15 01:46:21 -07:00
geometrymode shrink:
Generate a map of at most the requested geometry. Shrink
it to the smallest possible size that still includes the
same information.
Currently, shrinking is done with block granularity, and
based on which blocks are in the database. If the database
contains empty, or partially empty blocks, there may still
be empty pixels at the edges of the map.
sqlite-cacheworldrow:
When using sqlite, read an entire world row at one, instead of reading
one block at a time.
2014-04-14 07:39:13 -07:00
This may improve performance when a large percentage of the world is mapped.
2014-04-10 03:30:03 -07:00
tiles <tilesize>[+<border>]
Divide the map in square tiles of the requested size. A border of the
requested width (or width 1, of not specfied) is drawn between the tiles.
In order to preserve all map pixels (and to prevent overwriting them with
borders), extra pixel rows and columns for the borders are inserted into
the map.
2014-04-14 07:39:13 -07:00
In order to allow partial world maps to be combined into larger maps, edge
borders of the map are always drawn on the same side (left or top). Other
edges are always border-less.
2014-04-14 07:39:13 -07:00
Examples:
`--tiles 1000`
2014-04-14 07:39:13 -07:00
`--tiles 1000+2`
2014-04-14 07:39:13 -07:00
NOTE: As a consequence of preserving all map pixels:
2014-04-14 07:39:13 -07:00
* tiled maps may look slightly distorted, due to the inserted borders.
2014-04-14 07:39:13 -07:00
* scale markers never align with tile borders, as the borders are
logically *between* pixels, so they have no actual coordinates.
tileorigin x,y
Arrange the tiles so that one tile has its bottom-left (i.e. south-west)
corner at map coordinates x,y.
2014-04-14 07:39:13 -07:00
(see also `tilecenter`)
tilecenter x,y|map|world
Arrange the tiles so that one tile has its center at map coordinates x,y.
If the value 'world' is used, arrange for one tile to have its center
at the center of the world instead. This is the default for tiles.
If the value 'map' is used, arrange for one tile to have its center
at the center of the map instead.
2014-04-14 07:39:13 -07:00
Examples:
`--tilecenter -500,-500`
`--tileorigin 0,0`
2014-04-14 07:39:13 -07:00
`--tilecenter map`
2014-04-14 07:39:13 -07:00
`--tilecenter world`
2014-04-10 03:30:03 -07:00
tilebordercolor
Color of border between tiles, `--tilebordercolor #000000`
draw[map]<figure> "<geometry> <color> [<text>]"
Draw a geometrical figure on the map, using either world or map
coordinates.
NOTE: the quotes around the two or three parameters to these
options are absolutely required.
Possible figures: point, line, circle, ellipse, rectangle, text;
'circle' is an alias for 'ellipse' - it therefore requires
two dimensions, just like an ellipse.
Examples:
`--drawellipse "5x5+2+3 #ff0000"`
`--drawcircle "4,5:5x4 #ff0000"`
`--drawline "5x5+8+8 #80ff0000"`
`--drawline "8,8:12,12 #80ff0000"`
`--drawmapline "3x5+4+6 #ffff0000"`
`--drawtext "0,0 #808080 center of the world"
`--drawmaptext "0,0 #808080 top left of the map"
Note that specifying an alpha value does not have the expected
result when drawing an ellipse.
verbose:
2014-04-14 07:39:13 -07:00
report some useful / interesting information:
* maximum coordinates of the world
2014-04-14 07:39:13 -07:00
* world coordinates included the map being generated
2014-04-14 07:39:13 -07:00
* number of blocks: in the world, and in the map area.
2014-04-14 07:39:13 -07:00
2014-05-19 03:11:14 -07:00
Using `--verbose=2`, report some more statistics, including:
* database access statistics.
verbose-search-colors:
report the location of the colors file that was used.
With `--verbose-search-colors=2`, report all locations that are being
searched as well.