Line is drawn twice

[Sworddragon]

This is related to the second problem of ticket #212 (to secure that this problem don't get forgotten).

The last line of an image is drawn twice (so the image is one pixel higher than it should be):

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

The image is 48 x 49 pixel high. Row 49 is the same as row 48 (is it normal that 9 chunks are rendered and not 5 with this command?).

[uap-universe]

I, again, don't get your point. My image is 48x48. But you are right that there still is work to do according to the "-1"-problem.

And yes, it is intentional that alle chunks are rendered to have a smoother image. With a very sharp rule this would be the result (I think you have expected this):

0x0
xxx
0x0

But this would be a vaste of memory, scince during rendering the transparent pixels in the corners are allocated anyway. And - as i said - it is much smoother this way and looks nicer.

[Sworddragon]

It seems I have posted the wrong command (because it will give me an image of 48 x 48 pixel too). This is the command which will double the last line (so that the image is 48 x 49 pixel):

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

[uap-universe]

We definately should ensure, that @udoprog never uses any -1 again :D Yeah, that's a side effect of the "-1 issue". Unfortunately I still don't understand it. Some parts of the algorithm like this small shift by 1 pixel and others don't.

In general:

• for the visual result the -1 is important (there are vertical white stripes in the output if the -1 is missing).
• for the "computational" (can't find a better word^^) result the -1 must not be there (scine the minimum-x-value will be negative then and any other value isn't a power of 2 anymore).

[Sworddragon]

The bug does still exist in the current master.