minetest-mapper-cpp/TileGenerator.cpp

1133 lines
30 KiB
C++
Raw Normal View History

2012-08-23 03:46:22 -07:00
/*
* =====================================================================
* Version: 1.0
* Created: 23.08.2012 12:35:53
* Author: Miroslav Bendík
* Company: LinuxOS.sk
* =====================================================================
*/
2012-08-23 05:21:34 -07:00
#include <cstdio>
#include <cstdlib>
#include <climits>
#include <fstream>
2012-08-25 06:06:11 -07:00
#include <gdfontmb.h>
#include <iostream>
#include <iomanip>
2012-08-24 00:46:14 -07:00
#include <sstream>
2014-03-09 04:32:13 -07:00
#include <stdexcept>
#include <cerrno>
#include <cstring>
2012-09-01 04:01:31 -07:00
#include "config.h"
#include "PlayerAttributes.h"
2012-08-23 03:46:22 -07:00
#include "TileGenerator.h"
2012-09-18 01:43:34 -07:00
#include "ZlibDecompressor.h"
2014-03-05 12:41:27 -08:00
#include "db-sqlite3.h"
#if USE_LEVELDB
#include "db-leveldb.h"
#endif
2012-08-23 03:46:22 -07:00
using namespace std;
2014-03-05 12:41:27 -08:00
static inline int64_t pythonmodulo(int64_t i, int64_t mod)
{
if (i >= 0) {
return i % mod;
}
else {
return mod - ((-i) % mod);
}
}
static inline int unsignedToSigned(long i, long max_positive)
{
if (i < max_positive) {
return i;
}
else {
return i - 2l * max_positive;
}
}
2012-09-18 01:15:50 -07:00
static inline uint16_t readU16(const unsigned char *data)
{
2012-09-18 01:15:50 -07:00
return data[0] << 8 | data[1];
}
static inline int readBlockContent(const unsigned char *mapData, int version, int datapos)
{
if (version >= 24) {
size_t index = datapos << 1;
return (mapData[index] << 8) | mapData[index + 1];
}
else if (version >= 20) {
if (mapData[datapos] <= 0x80) {
return mapData[datapos];
}
else {
return (int(mapData[datapos]) << 4) | (int(mapData[datapos + 0x2000]) >> 4);
}
}
else {
std::ostringstream oss;
oss << "Unsupported map version " << version;
throw std::runtime_error(oss.str());
}
}
2012-08-23 03:46:22 -07:00
TileGenerator::TileGenerator():
verboseCoordinates(0),
verboseStatistics(false),
progressIndicator(false),
2012-08-24 00:46:14 -07:00
m_bgColor(255, 255, 255),
m_scaleColor(0, 0, 0),
m_originColor(255, 0, 0),
m_playerColor(255, 0, 0),
m_tileBorderColor(0, 0, 0),
2012-08-23 03:46:22 -07:00
m_drawOrigin(false),
m_drawPlayers(false),
m_drawScale(false),
m_drawAlpha(false),
m_shading(true),
2012-08-25 05:11:55 -07:00
m_border(0),
2014-03-05 12:41:27 -08:00
m_backend("sqlite3"),
m_shrinkGeometry(true),
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
m_blockGeometry(false),
m_sqliteCacheWorldRow(false),
2012-08-23 05:21:34 -07:00
m_image(0),
m_xMin(INT_MAX/16-1),
m_xMax(INT_MIN/16+1),
m_zMin(INT_MAX/16-1),
m_zMax(INT_MIN/16+1),
m_yMin(INT_MAX/16-1),
m_yMax(INT_MIN/16+1),
m_reqXMin(MAPBLOCK_MIN),
m_reqXMax(MAPBLOCK_MAX),
m_reqYMin(MAPBLOCK_MIN),
m_reqYMax(MAPBLOCK_MAX),
m_reqZMin(MAPBLOCK_MIN),
m_reqZMax(MAPBLOCK_MAX),
m_reqYMinNode(0),
m_reqYMaxNode(15),
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
m_mapXStartNodeOffset(0),
m_mapYStartNodeOffset(0),
m_mapXEndNodeOffset(0),
m_mapYEndNodeOffset(0),
m_nextStoredYCoord(0),
m_tileXOrigin(TILECENTER_IS_WORLDCENTER),
m_tileZOrigin(TILECENTER_IS_WORLDCENTER),
m_tileWidth(0),
m_tileHeight(0),
m_tileBorderSize(1),
m_tileMapXOffset(0),
m_tileMapYOffset(0)
2012-08-23 03:46:22 -07:00
{
}
TileGenerator::~TileGenerator()
{
}
void TileGenerator::setBgColor(const Color &bgColor)
2012-08-23 03:46:22 -07:00
{
m_bgColor = bgColor;
2012-08-23 03:46:22 -07: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
void TileGenerator::setShrinkGeometry(bool shrink)
{
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
m_shrinkGeometry = shrink;
}
void TileGenerator::setBlockGeometry(bool block)
{
m_blockGeometry = block;
}
void TileGenerator::setSqliteCacheWorldRow(bool cacheWorldRow)
{
m_sqliteCacheWorldRow = cacheWorldRow;
}
void TileGenerator::setScaleColor(const Color &scaleColor)
2012-08-23 03:46:22 -07:00
{
m_scaleColor = scaleColor;
2012-08-23 03:46:22 -07:00
}
void TileGenerator::setOriginColor(const Color &originColor)
2012-08-23 03:46:22 -07:00
{
m_originColor = originColor;
2012-08-23 03:46:22 -07:00
}
void TileGenerator::setPlayerColor(const Color &playerColor)
2012-08-23 03:46:22 -07:00
{
m_playerColor = playerColor;
2012-08-23 05:43:11 -07:00
}
void TileGenerator::setTileBorderColor(const Color &tileBorderColor)
{
m_tileBorderColor = tileBorderColor;
}
void TileGenerator::setTileBorderSize(int size)
{
m_tileBorderSize = size;
}
void TileGenerator::setTileSize(int width, int heigth)
{
m_tileWidth = width;
m_tileHeight = heigth;
}
void TileGenerator::setTileOrigin(int x, int y)
{
m_tileXOrigin = x;
m_tileZOrigin = y;
}
2012-08-23 03:46:22 -07:00
void TileGenerator::setDrawOrigin(bool drawOrigin)
{
m_drawOrigin = drawOrigin;
}
void TileGenerator::setDrawPlayers(bool drawPlayers)
{
m_drawPlayers = drawPlayers;
}
void TileGenerator::setDrawScale(bool drawScale)
{
m_drawScale = drawScale;
2012-08-25 05:11:55 -07:00
if (m_drawScale) {
m_border = 40;
}
2012-08-23 03:46:22 -07:00
}
void TileGenerator::setDrawAlpha(bool drawAlpha)
{
m_drawAlpha = drawAlpha;
}
void TileGenerator::setShading(bool shading)
{
m_shading = shading;
}
void TileGenerator::enableProgressIndicator(void)
{
progressIndicator = true;
}
2012-11-24 10:25:13 -08:00
void TileGenerator::setGeometry(int x, int y, int w, int h)
{
if (x > 0) {
m_reqXMin = x / 16;
2012-11-24 10:25:13 -08:00
}
else {
m_reqXMin = (x - 15) / 16;
2012-11-24 10:25:13 -08:00
}
if (y > 0) {
m_reqZMin = y / 16;
2012-11-24 10:25:13 -08:00
}
else {
m_reqZMin = (y - 15) / 16;
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
m_mapXStartNodeOffset = x - m_reqXMin * 16;
m_mapYEndNodeOffset = m_reqZMin * 16 - y;
2012-11-24 10:25:13 -08:00
int x2 = x + w - 1;
int y2 = y + h - 1;
2012-11-24 10:25:13 -08:00
if (x2 > 0) {
m_reqXMax = x2 / 16;
2012-11-24 10:25:13 -08:00
}
else {
m_reqXMax = (x2 - 15) / 16;
2012-11-24 10:25:13 -08:00
}
if (y2 > 0) {
m_reqZMax = y2 / 16;
2012-11-24 10:25:13 -08:00
}
else {
m_reqZMax = (y2 - 15) / 16;
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
m_mapXEndNodeOffset = x2 - (m_reqXMax * 16 + 15);
m_mapYStartNodeOffset = (m_reqZMax * 16 + 15) - y2;
2012-11-24 10:25:13 -08:00
}
2014-03-05 09:06:05 -08:00
void TileGenerator::setMinY(int y)
{
if (y > 0) {
m_reqYMin = y / 16;
}
else {
m_reqYMin = (y - 15) / 16;
}
m_reqYMinNode = y - 16 * m_reqYMin;
2014-03-05 09:06:05 -08:00
}
void TileGenerator::setMaxY(int y)
{
if (y > 0) {
m_reqYMax = y / 16;
}
else {
m_reqYMax = (y - 15) / 16;
}
m_reqYMaxNode = y - 16 * m_reqYMax;
2014-03-05 09:06:05 -08:00
}
void TileGenerator::parseColorsFile(const std::string &fileName)
{
ifstream in;
in.open(fileName.c_str(), ifstream::in);
if (!in.is_open()) {
throw std::runtime_error(std::string("Failed to open colors file '") + fileName + "'");
2012-09-01 06:51:02 -07:00
return;
}
parseColorsStream(in, fileName.c_str());
}
2014-03-05 12:41:27 -08:00
void TileGenerator::setBackend(std::string backend)
{
m_backend = backend;
}
2012-08-23 05:21:34 -07:00
void TileGenerator::generate(const std::string &input, const std::string &output)
2012-08-23 04:32:22 -07:00
{
2012-09-01 04:41:00 -07:00
string input_path = input;
if (input_path[input.length() - 1] != PATH_SEPARATOR) {
input_path += PATH_SEPARATOR;
}
openDb(input_path);
2012-08-23 04:32:22 -07:00
loadBlocks();
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
computeMapParameters();
2012-08-23 05:21:34 -07:00
createImage();
2012-08-23 06:35:00 -07:00
renderMap();
2012-08-25 05:11:55 -07:00
if (m_drawScale) {
renderScale();
}
2012-08-25 06:21:51 -07:00
if (m_drawOrigin) {
renderOrigin();
}
2012-08-25 07:29:41 -07:00
if (m_drawPlayers) {
2012-09-01 04:41:00 -07:00
renderPlayers(input_path);
2012-08-25 07:29:41 -07:00
}
2012-08-23 05:21:34 -07:00
writeImage(output);
2012-08-25 07:41:53 -07:00
printUnknown();
2012-08-23 04:32:22 -07:00
}
void TileGenerator::parseColorsStream(std::istream &in, const std::string &filename)
2012-09-01 06:51:02 -07:00
{
string line;
int linenr = 0;
for (std::getline(in,line); in.good(); std::getline(in,line)) {
linenr++;
istringstream iline;
iline.str(line);
iline >> std::skipws;
2012-09-01 06:51:02 -07:00
string name;
ColorEntry color;
iline >> name;
if (name.length() == 0 || name[0] == '#')
continue;
int r, g, b, a, t;
iline >> r;
iline >> g;
iline >> b;
if (!iline.good() && !iline.eof()) {
std::cerr << filename << ":" << linenr << ": bad line in colors file (" << line << ")" << std::endl;
continue;
2012-09-01 06:51:02 -07:00
}
a = 0xff;
iline >> a;
t = 0;
iline >> t;
color = ColorEntry(r,g,b,a,t);
if ((m_drawAlpha && a == 0xff) || (!m_drawAlpha && a != 0xff)) {
// If drawing alpha, and the colors file contains both
// an opaque entry and a non-opaque entry for a name, prefer
// the non-opaque entry
// If not drawing alpha, and the colors file contains both
// an opaque entry and a non-opaque entry for a name, prefer
// the opaque entry
// Otherwise, any later entry overrides any previous entry
ColorMap::iterator it = m_colors.find(name);
if (it != m_colors.end()) {
if (m_drawAlpha && (a == 0xff && it->second.a != 0xff)) {
// drawing alpha: don't use opaque color to override
// non-opaque color
continue;
}
if (!m_drawAlpha && (a != 0xff && it->second.a == 0xff)) {
// not drawing alpha: don't use non-opaque color to
// override opaque color
continue;
}
}
}
m_colors[name] = color;
}
if (!in.eof()) {
std::cerr << filename << ": error reading colors file after line " << linenr << std::endl;
2012-09-01 06:51:02 -07:00
}
}
2012-08-23 04:32:22 -07:00
void TileGenerator::openDb(const std::string &input)
{
if(m_backend == "sqlite3") {
DBSQLite3 *db;
m_db = db = new DBSQLite3(input);
db->cacheWorldRow = m_sqliteCacheWorldRow;
}
2014-03-05 12:41:27 -08:00
#if USE_LEVELDB
else if(m_backend == "leveldb")
2014-03-05 12:41:27 -08:00
m_db = new DBLevelDB(input);
#endif
else
throw std::runtime_error(((std::string) "Unknown map backend: ") + m_backend);
2012-08-23 04:32:22 -07:00
}
void TileGenerator::loadBlocks()
{
#define MESSAGE_WIDTH 25
int mapXMin, mapXMax;
int mapYMin, mapYMax;
int mapZMin, mapZMax;
int geomYMin, geomYMax;
long long world_blocks;
long long map_blocks;
if (verboseCoordinates >= 2) {
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
bool partialBlocks = (m_mapXStartNodeOffset || m_mapXEndNodeOffset || m_mapYStartNodeOffset || m_mapYEndNodeOffset);
if (partialBlocks || !m_blockGeometry) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< (m_blockGeometry ? "Command-line Geometry:" : "Requested Geometry:")
<< std::right
<< std::setw(7) << m_reqXMin*16+m_mapXStartNodeOffset << ","
<< std::setw(7) << m_reqYMin*16+m_reqYMinNode << ","
<< std::setw(7) << m_reqZMin*16-m_mapYEndNodeOffset
<< " .. "
<< std::setw(7) << m_reqXMax*16+15+m_mapXEndNodeOffset << ","
<< std::setw(7) << m_reqYMax*16+m_reqYMaxNode << ","
<< std::setw(7) << m_reqZMax*16+15-m_mapYStartNodeOffset
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
<< " ("
<< std::setw(6) << m_reqXMin << ","
<< std::setw(6) << m_reqYMin << ","
<< std::setw(6) << m_reqZMin
<< " .. "
<< std::setw(6) << m_reqXMax << ","
<< std::setw(6) << m_reqYMax << ","
<< std::setw(6) << m_reqZMax
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
<< ")\n";
}
if (partialBlocks || m_blockGeometry) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< (m_blockGeometry ? "Requested Geometry:" : "Block-aligned Geometry:")
<< std::right
<< std::setw(7) << m_reqXMin*16 << ","
<< std::setw(7) << m_reqYMin*16+m_reqYMinNode << ","
<< std::setw(7) << m_reqZMin*16 <<
" .. "
<< std::setw(7) << m_reqXMax*16+15 << ","
<< std::setw(7) << m_reqYMax*16+m_reqYMaxNode << ","
<< std::setw(7) << m_reqZMax*16+15
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
<< " ("
<< std::setw(6) << m_reqXMin << ","
<< std::setw(6) << m_reqYMin << ","
<< std::setw(6) << m_reqZMin
<< " .. "
<< std::setw(6) << m_reqXMax << ","
<< std::setw(6) << m_reqYMax << ","
<< std::setw(6) << m_reqZMax
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
<< ")\n";
}
}
if (m_blockGeometry) {
m_mapXStartNodeOffset = 0;
m_mapXEndNodeOffset = 0;
m_mapYStartNodeOffset = 0;
m_mapYEndNodeOffset = 0;
}
mapXMin = INT_MAX/16-1;
mapXMax = -INT_MIN/16+1;
mapYMin = INT_MAX/16-1;
mapYMax = -INT_MIN/16+1;
mapZMin = INT_MAX/16-1;
mapZMax = -INT_MIN/16+1;
geomYMin = INT_MAX/16-1;
geomYMax = -INT_MIN/16+1;
const DB::BlockPosList &blocks = m_db->getBlockPos();
world_blocks = 0;
map_blocks = 0;
for(DB::BlockPosList::const_iterator it = blocks.begin(); it != blocks.end(); ++it) {
world_blocks ++;
BlockPos pos = *it;
if (pos.x < mapXMin) {
mapXMin = pos.x;
}
if (pos.x > mapXMax) {
mapXMax = pos.x;
}
if (pos.y < mapYMin) {
mapYMin = pos.y;
}
if (pos.y > mapYMax) {
mapYMax = pos.y;
}
if (pos.z < mapZMin) {
mapZMin = pos.z;
}
if (pos.z > mapZMax) {
mapZMax = pos.z;
}
if (pos.x < m_reqXMin || pos.x > m_reqXMax || pos.z < m_reqZMin || pos.z > m_reqZMax) {
continue;
}
if (pos.y < geomYMin) {
geomYMin = pos.y;
}
if (pos.y > geomYMax) {
geomYMax = pos.y;
}
if (pos.y < m_reqYMin || pos.y > m_reqYMax) {
2014-03-05 12:41:27 -08:00
continue;
}
map_blocks++;
2014-03-05 12:41:27 -08:00
if (pos.y < m_yMin) {
m_yMin = pos.y;
2014-03-05 12:41:27 -08:00
}
if (pos.y > m_yMax) {
m_yMax = pos.y;
2012-08-23 04:32:22 -07:00
}
2014-03-05 12:41:27 -08:00
if (pos.x < m_xMin) {
m_xMin = pos.x;
}
if (pos.x > m_xMax) {
m_xMax = pos.x;
}
if (pos.z < m_zMin) {
m_zMin = pos.z;
}
if (pos.z > m_zMax) {
m_zMax = pos.z;
}
m_positions.push_back(pos);
2012-08-23 04:32:22 -07:00
}
if (verboseCoordinates >= 1) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< "World Geometry:" << std::right
<< std::setw(7) << mapXMin*16 << ","
<< std::setw(7) << mapYMin*16 << ","
<< std::setw(7) << mapZMin*16
<< " .. "
<< std::setw(7) << mapXMax*16+15 << ","
<< std::setw(7) << mapYMax*16+15 << ","
<< std::setw(7) << mapZMax*16+15
<< " ("
<< std::setw(6) << mapXMin << ","
<< std::setw(6) << mapYMin << ","
<< std::setw(6) << mapZMin
<< " .. "
<< std::setw(6) << mapXMax << ","
<< std::setw(6) << mapYMax << ","
<< std::setw(6) << mapZMax
<< ") blocks: "
<< std::setw(10) << world_blocks << "\n";
}
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 (m_shrinkGeometry) {
if (m_xMin != m_reqXMin) m_mapXStartNodeOffset = 0;
if (m_xMax != m_reqXMax) m_mapXEndNodeOffset = 0;
if (m_zMin != m_reqZMin) m_mapYEndNodeOffset = 0;
if (m_zMax != m_reqZMax) m_mapYStartNodeOffset = 0;
}
else {
if (verboseCoordinates >= 2) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< "Minimal Map Geometry:" << std::right
<< std::setw(7) << m_xMin*16 << ","
<< std::setw(7) << m_yMin*16+m_reqYMinNode << ","
<< std::setw(7) << m_zMin*16
<< " .. "
<< std::setw(7) << m_xMax*16+15 << ","
<< std::setw(7) << m_yMax*16+m_reqYMaxNode << ","
<< std::setw(7) << m_zMax*16+15
<< " ("
<< std::setw(6) << m_xMin << ","
<< std::setw(6) << m_yMin << ","
<< std::setw(6) << m_zMin
<< " .. "
<< std::setw(6) << m_xMax << ","
<< std::setw(6) << m_yMax << ","
<< std::setw(6) << m_zMax
<< ")\n";
}
m_xMin = m_reqXMin;
m_xMax = m_reqXMax;
m_zMin = m_reqZMin;
m_zMax = m_reqZMax;
}
if (verboseCoordinates >= 2) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< "Map Vertical Limits:" << std::right
<< std::setw(7) << "x" << ","
<< std::setw(7) << geomYMin*16 << ","
<< std::setw(7) << "z"
<< " .. "
<< std::setw(7) << "x" << ","
<< std::setw(7) << geomYMax*16+15 << ","
<< std::setw(7) << "z"
<< " ("
<< std::setw(6) << "x" << ","
<< std::setw(6) << geomYMin << ","
<< std::setw(6) << "z"
<< " .. "
<< std::setw(6) << "x" << ","
<< std::setw(6) << geomYMax << ","
<< std::setw(6) << "z"
<< ")\n";
}
if (verboseCoordinates >= 1) {
cout
<< std::setw(MESSAGE_WIDTH) << std::left
<< "Map Output Geometry:" << std::right
<< std::setw(7) << m_xMin*16+m_mapXStartNodeOffset << ","
<< std::setw(7) << m_yMin*16+m_reqYMinNode << ","
<< std::setw(7) << m_zMin*16-m_mapYEndNodeOffset
<< " .. "
<< std::setw(7) << m_xMax*16+15+m_mapXEndNodeOffset << ","
<< std::setw(7) << m_yMax*16+m_reqYMaxNode << ","
<< std::setw(7) << m_zMax*16+15-m_mapYStartNodeOffset
<< " ("
<< std::setw(6) << m_xMin << ","
<< std::setw(6) << m_yMin << ","
<< std::setw(6) << m_zMin
<< " .. "
<< std::setw(6) << m_xMax << ","
<< std::setw(6) << m_yMax << ","
<< std::setw(6) << m_zMax
<< ") blocks: "
<< std::setw(10) << map_blocks << "\n";
}
2014-03-22 01:30:14 -07:00
m_positions.sort();
#undef MESSAGE_WIDTH
2012-08-23 04:32:22 -07:00
}
2014-03-05 12:41:27 -08:00
inline BlockPos TileGenerator::decodeBlockPos(int64_t blockId) const
2012-08-23 04:32:22 -07:00
{
BlockPos pos;
pos.x = unsignedToSigned(pythonmodulo(blockId, 4096), 2048);
2012-08-23 05:06:16 -07:00
blockId = (blockId - pos.x) / 4096;
pos.y = unsignedToSigned(pythonmodulo(blockId, 4096), 2048);
2012-08-23 05:06:16 -07:00
blockId = (blockId - pos.y) / 4096;
pos.z = unsignedToSigned(pythonmodulo(blockId, 4096), 2048);
2012-08-23 04:32:22 -07:00
return pos;
}
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
void TileGenerator::pushPixelRows(int zPosLimit) {
if (m_shading)
m_blockPixelAttributes.renderShading(m_drawAlpha);
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
int y;
for (y = m_nextStoredYCoord; y <= m_blockPixelAttributes.getLastY() && y < worldBlockZ2StoredY(m_zMin - 1) + m_mapYEndNodeOffset; y++) {
for (int x = m_mapXStartNodeOffset; x < worldBlockX2StoredX(m_xMax + 1) + m_mapXEndNodeOffset; x++) {
int mapX = x - m_mapXStartNodeOffset;
int mapY = y - m_mapYStartNodeOffset;
PixelAttribute &pixel = m_blockPixelAttributes.attribute(y, x);
#ifdef DEBUG
{ int ix = mapX2ImageX(mapX); assert(ix - m_border >= 0 && ix - m_border < m_pictWidth); }
{ int iy = mapY2ImageY(mapY); assert(iy - m_border >= 0 && iy - m_border < m_pictHeight); }
#endif
if (pixel.is_valid())
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
m_image->tpixels[mapY2ImageY(mapY)][mapX2ImageX(mapX)] = pixel.color().to_libgd();
}
}
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
int yLimit = worldBlockZ2StoredY(zPosLimit);
if (y <= yLimit) {
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
m_blockPixelAttributes.scroll(yLimit);
m_nextStoredYCoord = yLimit;
}
}
void TileGenerator::computeTileParameters(
// Input parameters
int minPos,
int maxPos,
int mapStartNodeOffset,
int mapEndNodeOffset,
int tileOrigin,
int tileSize,
// Input / Output parameters
int &pictSize,
// Output parameters
int &tileBorderCount,
int &tileMapStartOffset,
int &tileMapEndOffset,
// Behavior selection
bool ascending)
{
int start = minPos * 16 + mapStartNodeOffset - tileOrigin;
int limit = (maxPos+1) * 16 + mapEndNodeOffset - tileOrigin;
int shift;
// shift values, so that start = 0..tileSize-1
// (effect of tileOrigin is identical to (tileOrigin + tileSize)
// so any multiple of tileSize can be safely added)
if (start<0)
shift = - (start + 1) / tileSize + 1;
else
shift = - start / tileSize;
start += shift * tileSize;
limit += shift * tileSize;
int tileBorderStart = 0; // First border to draw
int tileBorderLimit = 0; // Last + 1 border to draw
if (ascending) {
// Prefer tile borders towards negative infinity
// 0 -> 0
// 1..tileSize -> 1
// (tileSize+1)..(2*tileSize) -> 2
// etc.
tileBorderStart = (start + tileSize - 1) / tileSize;
tileBorderLimit = (limit + tileSize - 1) / tileSize;
} else {
// Prefer tile borders towards positive infinity
// 0..(tileSize-1) -> 1
// tileSize..(2*tileSize-1) -> 2
// etc.
tileBorderStart = start / tileSize + 1;
tileBorderLimit = limit / tileSize + 1;
}
tileMapStartOffset = (tileSize - start) % tileSize;
tileMapEndOffset = limit - ((tileBorderLimit-tileBorderStart) * tileSize);
pictSize += (tileBorderLimit - tileBorderStart) * m_tileBorderSize;
tileBorderCount = tileBorderLimit - tileBorderStart;
}
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
void TileGenerator::computeMapParameters()
2012-08-23 05:21:34 -07: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
m_storedWidth = (m_xMax - m_xMin + 1) * 16;
m_storedHeight = (m_zMax - m_zMin + 1) * 16;
int mapWidth = m_storedWidth - m_mapXStartNodeOffset + m_mapXEndNodeOffset;
int mapHeight = m_storedHeight - m_mapYStartNodeOffset + m_mapYEndNodeOffset;
m_blockPixelAttributes.setParameters(m_storedWidth, 16);
// Set special values for origin (which depend on other paramters)
if (m_tileWidth) {
if (m_tileXOrigin == TILECENTER_IS_WORLDCENTER)
m_tileXOrigin = -m_tileWidth/2;
else if (m_tileXOrigin == TILECENTER_IS_MAPCENTER)
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
//m_tileXOrigin = ((m_xMax+1)*2-(m_xMax+1-m_xMin))*8 - m_tileWidth/2;
m_tileXOrigin = m_xMin * 16 + m_mapXStartNodeOffset + mapWidth / 2;
}
if (m_tileHeight) {
if (m_tileZOrigin == TILECENTER_IS_WORLDCENTER)
m_tileZOrigin = -m_tileHeight/2;
else if (m_tileZOrigin == TILECENTER_IS_MAPCENTER)
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
//m_tileZOrigin = ((m_zMax+1)*2-(m_zMax+1-m_zMin))*8 - m_tileHeight/2;
m_tileZOrigin = -m_xMax * 16 + m_mapYStartNodeOffset + mapHeight / 2;
}
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
// Compute adjustments for tiles.
m_pictWidth = mapWidth;
m_pictHeight = mapHeight;
if (m_tileWidth && m_tileBorderSize) {
int tileMapXEndOffset; // Dummy
TileGenerator::computeTileParameters(
// Input parameters
m_xMin,
m_xMax,
m_mapXStartNodeOffset,
m_mapXEndNodeOffset,
m_tileXOrigin,
m_tileWidth,
// Input / Output parameters
m_pictWidth,
// Output parameters
m_tileBorderXCount,
m_tileMapXOffset,
tileMapXEndOffset,
// Behavior selection
true);
}
if (m_tileHeight && m_tileBorderSize) {
int tileMapYEndOffset; // Dummy
TileGenerator::computeTileParameters(
// Input parameters
m_zMin,
m_zMax,
m_mapYEndNodeOffset,
m_mapYStartNodeOffset,
m_tileZOrigin,
m_tileHeight,
// Input / Output parameters
m_pictHeight,
// Output parameters
m_tileBorderYCount,
tileMapYEndOffset,
m_tileMapYOffset,
// Behavior selection
false);
}
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
m_nextStoredYCoord = m_mapYStartNodeOffset;
// Print some useful messages in cases where it may not be possible to generate the image...
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
long long pixels = static_cast<long long>(m_pictWidth + m_border) * (m_pictHeight + m_border);
// Study the libgd code to known why the maximum is the following:
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
long long max_pixels = INT_MAX - INT_MAX % m_pictHeight;
if (pixels > max_pixels) {
cerr << "WARNING: Image will have " << pixels << " pixels; the PNG graphics library will refuse to handle more than approximately " << INT_MAX << std::endl;
}
// Estimated approximate maximum was determined by trial and error...
// (24100x24100 succeeded; 24200x24200 failed)
#define ESTIMATED_MAX_PIXELS_32BIT (24100*24100L)
else if (sizeof(void *) == 4 && pixels > ESTIMATED_MAX_PIXELS_32BIT) {
cerr << "WARNING: Image will have " << pixels << " pixels; The maximum achievable on a 32-bit system is approximately " << ESTIMATED_MAX_PIXELS_32BIT << std::endl;
}
#undef ESTIMATED_MAX_PIXELS_32BIT
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
}
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
void TileGenerator::createImage()
{
m_image = gdImageCreateTrueColor(m_pictWidth + m_border, m_pictHeight + m_border);
if (!m_image) {
ostringstream oss;
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
oss << "Failed to allocate " << m_pictWidth + m_border << "x" << m_pictHeight + m_border << " image";
throw std::runtime_error(oss.str());
}
2012-08-23 05:21:34 -07:00
// Background
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
gdImageFilledRectangle(m_image, 0, 0, m_pictWidth + m_border - 1, m_pictHeight + m_border -1, m_bgColor.to_libgd());
// Draw tile borders
if (m_tileWidth && m_tileBorderSize) {
int borderColor = m_tileBorderColor.to_libgd();
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
for (int i = 0; i < m_tileBorderXCount; i++) {
int xPos = m_tileMapXOffset + i * (m_tileWidth + m_tileBorderSize);
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
#ifdef DEBUG
int xPos2 = mapX2ImageX(m_tileMapXOffset + i * m_tileWidth) - m_border - 1;
assert(xPos == xPos2);
#endif
gdImageFilledRectangle(m_image, xPos + m_border, m_border, xPos + (m_tileBorderSize-1) + m_border, m_pictHeight + m_border - 1, borderColor);
}
}
if (m_tileHeight && m_tileBorderSize) {
int borderColor = m_tileBorderColor.to_libgd();
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
for (int i = 0; i < m_tileBorderYCount; i++) {
int yPos = m_tileMapYOffset + i * (m_tileHeight + m_tileBorderSize);
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
#ifdef DEBUG
int yPos2 = mapY2ImageY(m_tileMapYOffset + i * m_tileHeight) - m_border - 1;
assert(yPos == yPos2);
#endif
gdImageFilledRectangle(m_image, m_border, yPos + m_border, m_pictWidth + m_border - 1, yPos + (m_tileBorderSize-1) + m_border, borderColor);
}
}
2012-08-23 05:21:34 -07:00
}
2014-03-05 12:41:27 -08:00
void TileGenerator::renderMap()
{
int blocks_rendered = 0;
int area_rendered = 0;
BlockPos currentPos;
currentPos.x = INT_MIN;
currentPos.y = 0;
currentPos.z = INT_MIN;
bool allReaded = false;
for (std::list<BlockPos>::const_iterator position = m_positions.begin(); position != m_positions.end(); ++position) {
const BlockPos &pos = *position;
if (currentPos.x != pos.x || currentPos.z != pos.z) {
area_rendered++;
if (currentPos.z != pos.z) {
pushPixelRows(pos.z);
m_blockPixelAttributes.setLastY((m_zMax - pos.z) * 16 + 15);
if (progressIndicator)
cout << "Processing Z-coordinate: " << std::setw(5) << pos.z*16 << "\r" << std::flush;
}
2012-08-24 13:51:17 -07:00
for (int i = 0; i < 16; ++i) {
m_readedPixels[i] = 0;
}
allReaded = false;
currentPos = pos;
}
else if (allReaded) {
continue;
}
DB::Block block = m_db->getBlockOnPos(pos);
if (!block.second.empty()) {
const unsigned char *data = block.second.c_str();
size_t length = block.second.length();
uint8_t version = data[0];
//uint8_t flags = data[1];
size_t dataOffset = 0;
if (version >= 22) {
dataOffset = 4;
}
else {
dataOffset = 2;
}
2012-08-24 13:51:17 -07:00
ZlibDecompressor decompressor(data, length);
decompressor.setSeekPos(dataOffset);
ustring mapData = decompressor.decompress();
ustring mapMetadata = decompressor.decompress();
dataOffset = decompressor.seekPos();
2012-08-24 03:10:26 -07:00
// Skip unused data
if (version <= 21) {
dataOffset += 2;
}
if (version == 23) {
dataOffset += 1;
}
if (version == 24) {
uint8_t ver = data[dataOffset++];
if (ver == 1) {
uint16_t num = readU16(data + dataOffset);
2012-08-24 03:10:26 -07:00
dataOffset += 2;
dataOffset += 10 * num;
2012-08-24 03:10:26 -07:00
}
}
2012-08-24 05:13:46 -07:00
// Skip unused static objects
dataOffset++; // Skip static object version
int staticObjectCount = readU16(data + dataOffset);
dataOffset += 2;
for (int i = 0; i < staticObjectCount; ++i) {
dataOffset += 13;
uint16_t dataSize = readU16(data + dataOffset);
dataOffset += dataSize + 2;
}
dataOffset += 4; // Skip timestamp
m_blockAirId = -1;
m_blockIgnoreId = -1;
// Read mapping
if (version >= 22) {
dataOffset++; // mapping version
uint16_t numMappings = readU16(data + dataOffset);
2012-08-24 05:13:46 -07:00
dataOffset += 2;
for (int i = 0; i < numMappings; ++i) {
uint16_t nodeId = readU16(data + dataOffset);
2012-08-24 05:13:46 -07:00
dataOffset += 2;
uint16_t nameLen = readU16(data + dataOffset);
dataOffset += 2;
string name = string(reinterpret_cast<const char *>(data) + dataOffset, nameLen);
name = name.c_str(); // Truncate any trailing NUL bytes
if (name == "air") {
m_blockAirId = nodeId;
}
else if (name == "ignore") {
m_blockIgnoreId = nodeId;
2012-08-24 03:10:26 -07:00
}
else {
m_nameMap[nodeId] = name;
}
dataOffset += nameLen;
2012-08-24 03:10:26 -07:00
}
}
2012-08-24 05:48:55 -07:00
// Node timers
if (version >= 25) {
dataOffset++;
uint16_t numTimers = readU16(data + dataOffset);
dataOffset += 2;
dataOffset += numTimers * 10;
}
2012-08-24 13:51:17 -07:00
renderMapBlock(mapData, pos, version);
blocks_rendered++;
2012-08-24 13:51:17 -07:00
allReaded = true;
for (int i = 0; i < 16; ++i) {
if (m_readedPixels[i] != 0xffff) {
allReaded = false;
2012-08-24 13:51:17 -07:00
}
}
}
}
if (currentPos.z != INT_MIN)
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
pushPixelRows(currentPos.z - 1);
if (verboseStatistics)
cout << "Statistics"
<< ": blocks read: " << m_db->getBlocksReadCount()
<< " (" << m_db->getBlocksCachedCount() << " cached + "
<< m_db->getBlocksUnCachedCount() << " uncached)"
<< "; blocks rendered: " << blocks_rendered
<< "; area rendered: " << area_rendered
<< "/" << (m_xMax-m_xMin+1) * (m_zMax-m_zMin+1)
<< " (" << (long long)area_rendered*16*16 << " nodes)"
<< std::endl;
else if (progressIndicator)
cout << std::setw(40) << "" << "\r";
2012-08-24 13:51:17 -07:00
}
inline void TileGenerator::renderMapBlock(const ustring &mapBlock, const BlockPos &pos, int version)
2012-08-24 13:51:17 -07: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
int xBegin = worldBlockX2StoredX(pos.x);
int zBegin = worldBlockZ2StoredY(pos.z);
2012-09-18 01:43:34 -07:00
const unsigned char *mapData = mapBlock.c_str();
int minY = (pos.y < m_reqYMin) ? 16 : (pos.y > m_reqYMin) ? 0 : m_reqYMinNode;
int maxY = (pos.y > m_reqYMax) ? -1 : (pos.y < m_reqYMax) ? 15 : m_reqYMaxNode;
2012-08-24 13:51:17 -07:00
for (int z = 0; z < 16; ++z) {
for (int x = 0; x < 16; ++x) {
if (m_readedPixels[z] & (1 << x)) {
continue;
}
2014-03-05 09:06:05 -08:00
for (int y = maxY; y >= minY; --y) {
2012-08-24 13:51:17 -07:00
int position = x + (y << 4) + (z << 8);
int content = readBlockContent(mapData, version, position);
if (content == m_blockIgnoreId || content == m_blockAirId) {
continue;
}
NodeID2NameMap::iterator blockName = m_nameMap.find(content);
if (blockName == m_nameMap.end())
2014-04-03 11:38:09 -07:00
continue;
const string &name = blockName->second;
ColorMap::const_iterator color = m_colors.find(name);
if (color != m_colors.end()) {
PixelAttribute pixel = PixelAttribute(color->second, pos.y * 16 + y);
if (m_drawAlpha) {
m_blockPixelAttributes.attribute(zBegin + 15 - z,xBegin + x).mixUnder(pixel);
if(pixel.alpha() == 0xff) {
m_readedPixels[z] |= (1 << x);
break;
}
} else {
m_blockPixelAttributes.attribute(zBegin + 15 - z, xBegin + x) = pixel;
m_readedPixels[z] |= (1 << x);
break;
}
} else {
m_unknownNodes.insert(name);
2012-08-24 13:51:17 -07:00
}
2012-08-24 02:01:48 -07:00
}
}
2012-08-24 00:46:14 -07:00
}
}
2012-08-23 06:35:00 -07:00
2012-08-25 05:11:55 -07:00
void TileGenerator::renderScale()
{
int color = m_scaleColor.to_libgd();
2012-08-25 06:06:11 -07:00
gdImageString(m_image, gdFontGetMediumBold(), 24, 0, reinterpret_cast<unsigned char *>(const_cast<char *>("X")), color);
gdImageString(m_image, gdFontGetMediumBold(), 2, 24, reinterpret_cast<unsigned char *>(const_cast<char *>("Z")), color);
string scaleText;
for (int i = (m_xMin / 4) * 4; i <= m_xMax; i += 4) {
stringstream buf;
buf << i * 16;
scaleText = buf.str();
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
int xPos = worldX2ImageX(i * 16);
2012-08-25 06:06:11 -07:00
gdImageString(m_image, gdFontGetMediumBold(), xPos + 2, 0, reinterpret_cast<unsigned char *>(const_cast<char *>(scaleText.c_str())), color);
gdImageLine(m_image, xPos, 0, xPos, m_border - 1, color);
}
for (int i = (m_zMax / 4) * 4; i >= m_zMin; i -= 4) {
stringstream buf;
buf << i * 16;
scaleText = buf.str();
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
int yPos = worldZ2ImageY(i * 16);
2012-08-25 06:06:11 -07:00
gdImageString(m_image, gdFontGetMediumBold(), 2, yPos, reinterpret_cast<unsigned char *>(const_cast<char *>(scaleText.c_str())), color);
gdImageLine(m_image, 0, yPos, m_border - 1, yPos, color);
}
2012-08-25 05:11:55 -07:00
}
2012-08-25 06:21:51 -07:00
void TileGenerator::renderOrigin()
{
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
int imageX = worldX2ImageX(0);
int imageY = worldZ2ImageY(0);
gdImageArc(m_image, imageX, imageY, 12, 12, 0, 360, m_originColor.to_libgd());
2012-08-25 06:21:51 -07:00
}
2012-08-25 07:29:41 -07:00
void TileGenerator::renderPlayers(const std::string &inputPath)
{
int color = m_playerColor.to_libgd();
2012-08-25 07:29:41 -07:00
PlayerAttributes players(inputPath);
for (PlayerAttributes::Players::iterator player = players.begin(); player != players.end(); ++player) {
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
int imageX = worldX2ImageX(player->x / 10);
int imageY = worldZ2ImageY(player->z / 10);
2012-09-01 04:01:31 -07:00
gdImageArc(m_image, imageX, imageY, 5, 5, 0, 360, color);
gdImageString(m_image, gdFontGetMediumBold(), imageX + 2, imageY + 2, reinterpret_cast<unsigned char *>(const_cast<char *>(player->name.c_str())), color);
2012-09-01 04:01:31 -07:00
}
2012-08-25 07:29:41 -07:00
}
2012-08-24 00:46:14 -07:00
inline std::list<int> TileGenerator::getZValueList() const
{
std::list<int> zlist;
for (std::list<BlockPos>::const_iterator position = m_positions.begin(); position != m_positions.end(); ++position) {
zlist.push_back(position->z);
2012-08-24 00:46:14 -07:00
}
zlist.sort();
zlist.unique();
2012-09-01 04:34:27 -07:00
zlist.reverse();
2012-08-24 00:46:14 -07:00
return zlist;
}
2012-08-23 05:21:34 -07:00
void TileGenerator::writeImage(const std::string &output)
{
FILE *out;
2012-08-28 02:27:51 -07:00
out = fopen(output.c_str(), "wb");
if (!out) {
std::ostringstream oss;
oss << "Error opening '" << output.c_str() << "': " << std::strerror(errno);
throw std::runtime_error(oss.str());
}
2012-08-23 05:21:34 -07:00
gdImagePng(m_image, out);
fclose(out);
gdImageDestroy(m_image);
}
2012-08-25 07:41:53 -07:00
void TileGenerator::printUnknown()
{
if (m_unknownNodes.size() > 0) {
std::cerr << "Unknown nodes:" << std::endl;
for (std::set<std::string>::iterator node = m_unknownNodes.begin(); node != m_unknownNodes.end(); ++node) {
std::cerr << *node << std::endl;
}
}
}
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
// Adjust map coordinate for tiles and border
inline int TileGenerator::mapX2ImageX(int val) const
2012-08-25 05:11:55 -07:00
{
if (m_tileWidth && m_tileBorderSize)
val += ((val - m_tileMapXOffset + m_tileWidth) / m_tileWidth) * m_tileBorderSize + m_border;
else
val += m_border;
return val;
2012-08-25 05:11:55 -07: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
// Adjust map coordinate for tiles and border
inline int TileGenerator::mapY2ImageY(int val) const
2012-08-25 05:11:55 -07:00
{
if (m_tileHeight && m_tileBorderSize)
val += ((val - m_tileMapYOffset + m_tileHeight) / m_tileHeight) * m_tileBorderSize + m_border;
else
val += m_border;
return val;
2012-08-25 05:11:55 -07: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
// Convert world coordinate to image coordinate
inline int TileGenerator::worldX2ImageX(int val) const
{
val = (val - m_xMin * 16) - m_mapXStartNodeOffset;
return mapX2ImageX(val);
}
// Convert world coordinate to image coordinate
inline int TileGenerator::worldZ2ImageY(int val) const
{
val = (m_zMax * 16 + 15 - val) - m_mapYStartNodeOffset;
return mapY2ImageY(val);
}