udoprog / c10t

A minecraft cartography tool
Other
225 stars 50 forks source link

warps rendered too far south in isometric #152

Closed frymaster closed 12 years ago

frymaster commented 13 years ago

c10t - a cartography tool for minecraft version: git e6fdc7cbaf2cb0694b5c3556d52a8dc4d4fe9729, built on Apr 8 2011

command line: ./c10t -z -n --show-warps=hmod/bin/warps.txt --warp-color 255,255,255,255 -w hmod/bin/NE-2011 -o output.png

If you take the top of the image as north in a non-isometric image, then on the isometric image, all the warp point signs are being written FAR too far to the south (by about 2 thousand pixels). If I take the above commandline and remove the -z to make an overhead view, the signs are in the correct place.

the isometric is at http://www.nervousenergy.co.uk/minecraft/current.png and the overhead is http://www.nervousenergy.co.uk/minecraft/current-overhead.png

I haven't tried with other kinds of in-image marker, like signs.

frymaster commented 13 years ago

This is still happening - I can't display my map in isometric any more (too big) but the json markers created for the google api have everything too far "south" in isometric. I got around this by manually subtracing 350 from each x, and 115 from each y coordinate like so:

var point = new google.maps.Point(m.x / factor -350, m.y / factor-115);

obviously this workaround isn't available if you're wanting the markers written directly onto the image

insanity54 commented 13 years ago

try using c10t option "--isometric" instead of "-z". Doing this fixed incorrect offsets of player names & signs for me when using isometric view.

EDIT:

I think the fix I listed is for a separate issue which is where the markers of a previously top-down view map transfer to the isometric view map and do not line up at all. However, since fixing that issue, I do believe I am having your issue: http://imgur.com/2c0e4

I modified and applied your fix, mine needed a smaller adjustment:

var point = new google.maps.Point(m.x / factor -4, m.y / factor -9);

For newbs like me, this fix was applied on line 196 of libc10t.google.js in c10t version 1.9

Also, did you leave out a space or is it supposed to be like that: "factor -115)" instead of "factor-115)" ?

EdGruberman commented 13 years ago

I believe the same thing is happening me for me now with the latest version: version: git 8078a2a, built on May 26 2011

My markers look off, and I've noticed a top-down render produces a 7664x4720 sized image, but the json output has: "world":{"cx":2367,"cy":2528,"dx":7664,"dy":128,"dz":4736,"mn_x":-2528,"mn_z":-2368,"mode":0,"mx_x":5120,"mx_z":2352,"split":0,"split_base":0}

Where dz looks to be off by 16 (4736 instead of expected 4720). mn_z and mx_z seem to add up according to the actual output image though...

Of note, the json output has the correct x, y, and z for the signs and players, I spot checked a few manually. So it's something with the projection calculations I'm almost sure. Since the formulas I'm assuming shouldn't have changed, I'm still guessing it's something in the json output related to the world node and it's attributes.

EdGruberman commented 13 years ago

More testing on this revealed some more discrepancies that might help you troubleshoot:

version: git 8078a2a, built on May 26 2011 c10t.exe -w C:\Cache\Worlds\World1 -o c10t.png -R 10 --write-json info.json

Command line output contains: --- RENDERING --- ...... 305 parts 100% image limits: 15x0 to 303x304 will be the cropped image

info.json contains:

but it actually produces a 288x304 image which looks like it's left side is trimmed off.

udoprog commented 12 years ago

Please include a link to the world and add to the description (if possible), then reopen the issue.