Inlining the function allows the compiler to optimize away the
function completely. Clang 3.7.1 does exactly that.
This leads to an error, if the library is used with python:
% ./overviewer.py
Traceback (most recent call last):
File "/tmp/minecraft/Minecraft-Overviewer/overviewer_core/__init__.py", line 20, in check_c_overviewer
import c_overviewer
ImportError: /tmp/minecraft/Minecraft-Overviewer/overviewer_core/c_overviewer.so: undefined symbol: estimate_blocklevel
Something has gone wrong importing the c_overviewer extension. Please
make sure it is up-to-date (clean and rebuild)
On Windows with mingw-w64, Pillow includes windows.h, and thus
including Imaging.h would result in a name conflict of "TRANSPARENT",
which windows.h #defines but overviewer.h wants to use as enum.
For the record, this used to not be broken back when I initially
fixed Pillow for mingw-w64, so the change got somewhere introduced
between then and now.
A usecase to demonstrate a possible application of the extended functionality:
**"Rails Overlay that draws only the rails that are on Cobblestone for a subway map."**
With this patch it is very easy to achive that:
```python
MineralOverlay(minerals=[(((0, 0, 0, 66), (0, -1, 0, 4)), (255, 0, 0, 255)),
(((0, 0, 0, 27), (0, -1, 0, 4)), (0, 255, 0, 255))])
```
In this case the overlay will be red for rails on cobblestone and green for powerrails on cobblestone.
The syntax is `(<tuple of conditions>, <target color>)`
* where `<target color>` is a 4 tuple with a `(r, g, b, a)` color
* and `<tuple of conditions>` is a tuple with an arbitrary number of conditions with the following syntax:
`((relx, rely, relz, blkid), ...)` where the `rel<>` parameters specify the relative coordinates to the block that is checked if it matches bklid.
In the example the fist tuple `(0,0,0,66)` checks if at the current position is a
rail while `(0,-1,0,4)` checks if at one below the current position is a cobblestone.
If both are true then the color `(255, 0, 0, 255)` is used.
A Sample Config file exploiting the capabilities:
``` python
worlds['My World'] = "~/.minecraft/saves/test/"
outputdir = "/tmp/test_render"
rendermode = "lighting"
renders["render1"] = {
'world': 'My World',
'title': 'A regular render',
}
renders["render_overlay_dafault_rails"] = {
'world': 'My World',
'title': 'Default Rails',
'rendermode': [ClearBase(), StructureOverlay()],
'overlay': ['render1'],
}
renders["render_overlay_cust_rails"] = {
'world': 'My World',
'title': 'Custom Rails',
#relative coordinates [[(relx, rely, relz, mineral)], (red, green, blue, alpha)]
'rendermode': [ClearBase(), StructureOverlay(structures=[(((0, 0, 0, 66), (0, -1, 0, 4)), (255, 0, 0, 255)),
(((0, 0, 0, 27), (0, -1, 0, 4)), (0, 255, 0, 255))])],
'overlay': ['render1'],
}
```
The "Default Rails" overlay uses default coloring of the structures overlay. "Custom Rails" uses some custom coloring.
fixesoverviewer/Minecraft-Overviewer#556 and fixesoverviewer/Minecraft-Overviewer#787
Note that this commit changes the pseudo-ancil-data type from unsigned
int to an unsigned short. Our pseudoancil code creates 5 bits of data
to store adjacency information for glass. Glass also has 4 bits for
color info. This means we need a total of 9 bits to render these (thus
int --> short)
is_transparent returns 1 for every unknown block because that's an easy way to
make them ignore lighting, however, this makes cave render useless with a map
containing unknown ores.
The definition is_known_transparent checks whether a block is transparent and is known.
This is a workaround, a proper fix would be to have unknown blocks be neither transparent nor
solid. Or make them both. But don't prefer one of the two.
The new nether quartz ore block was not recognized and was causing "pillars"
of netherrock to be rendered (with a quartz ore on top). the same
seemed to be happened with Lava, so included taht as well
Fix for Ender Portal Frame, w/eye of ender, in all orientations
Minor fix for Comparator back torches
Update to lighting on Quartz stairs
Added Quartz Half Slabs
The nether rendering mode was not properly handling x and z values
outside of the range 0 to 15. This was causing an out-of-bounds
segfault when accessing the remove_block array.
Fixes#881Fixes#851Fixes#852
