search

udoprog / c10t

A minecraft cartography tool
Other
225 stars 50 forks source link

Wrong offset/image is not centered #212

Closed Sworddragon closed 12 years ago

Sworddragon commented 12 years ago

I have tested the newest version after the bugfixes and it seems that a new bug was introduced. A few pixel on the left side will be missing in the image:

/usr/local/bin/c10t -o /tmp/world.png -w /srv/minecraft/world -R 1

If the splitting is activated the image isn't even centered anymore:

/usr/local/bin/c10t -o /tmp/%d:%d_%d.png -p 336 -w /srv/minecraft/world -R 1

uap-universe commented 12 years ago

Hey, I did notice that the rendering is not a nice circle anymore, but that seems to be a side effect of putting squares into circles ;) As of the correct usage of the pythagoras here I tend to say that this is not a new bug, but an additional bug fix. I can work on some smoothing (by adding some constants to one side of the pythagoras inequality stated above) anyway.

Sworddragon commented 12 years ago

At least the wrong offset should be a bug. Here is an example image (I colored the background black so that the non-existent centering anymore can be seen): http://img46.imageshack.us/img46/5959/000ug.png

uap-universe commented 12 years ago

What offset? Why should it be centered? The only thing the split option does is to split the things. And as far as i can see this is done. I think I miss your point here. Could you please upload an image that shows the result that you expect?

Sworddragon commented 12 years ago

The point is that the left part of the image is missing.

Edit: After zooming in with GIMP and looking at the image I see that more things are broken. The image should be splitted in 5 main parts. The center is 16x16 pixel (a correct chunk). The top is 17 x 16 pixel, the right is 15 x 16 pixel, the bottom is 16 x 17 pixel and the left is 1 x 16 pixel (here are 15 pixel cut off (an offset of x = -15 for the image)).

4 of 5 chunks are incorrect drawn. On -R 1 shouldn't the image contain 5 chunks of 16 x 16 pixel? Just zoom in and look at the image (I zoomed in ~2000%) and you will maybe understand what is wrong.

Edit2: Here is the solution for the offset:

image limits: 15x0 to 47x48 will be the cropped image (32x48)

But why is this done?

uap-universe commented 12 years ago

(My fault... I tested it with isometric renderings only and everything is fine there^^)

I will find out why the crop algorithm kills too much. Thanks for the analysis.

EDIT: I figured out, that the algorithm computes wrong x values. They are all one less than they should be. So the algorithm checks e.g.

15x32 vs limits -1x16 vs limits

But because the pos_t is unsigned, the -1 is some really big value and the minimum stays at 15 though it should be 0. A workaround is to add the value 1 to the x, but I want to figure out why it is missing and fix it - that's much cleaner than just readding it ;)

uap-universe commented 12 years ago

For now I used the workaround. The top-projection subtracts 1 here, but this is necessary for any other projections (if I remove the -1 there, white stripes are rendered at the borders of each part). But for computing the image limits this is not good, scince 0-0-1=-1 and -1 is not a valid pixel position in an image.

udoprog and me should work on that thing in future and eliminate any -1. The other things you figured out seem to be side effects of this inconsequent usage of the -1. But I currently don't understand why the -1 is there, I just see that it must be there for some reason. I can't figure it out without udoprog's help.

This ticket is closed, as the original bug is fixed but I see, that there still is some work to do.