• Previous message: Adam Fedor: "Non manhattan geometry behavior"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Dear Adam,

> Reading the attached magic file into magic and writing it out again 
> creates a magic file with about 8000 shapes (as opposed to the original 
> 2). I could look at this if someone gave me and idea where this 
> happens. Thanks.

  ...
> tri 26856 6431 28964 8539 ne
> tri 25088 6431 28964 10306 sw
  ...


This is an artifact of the way I coerced non-manhattan geometry to fit
into magic's existing corner-stitched database representation.  The
layout is still made of rectangles "stitched together" at the corners.
Triangles are simply rectangles that are split in half, with one tile
type on one side, and another tile type on the other side.

Long diagonal wires do not work very well in this format.  Triangles
which meet along the diagonal (as in your case) do not do very well,
either.  In your case, a roundoff error (maybe?) gives you a non-
square box for the second triangle (3876 lambda x 3875 lambda).
Change the last number from 10306 to 10307, and you get what you're
expecting to get.

Note that by being off the 45-degree angle by such a tiny amount
results in a worst-case scenario for the tile splitting, which is
trying very hard to satisfy the request.

Another way to get around problems of this sort is to put each triangle
in a separate subcell, so that each gets its own tile plane and they
don't interact with each other in unfortunate ways.

					Regards,
					Tim

• Next message: Stefan Robert: "Re: Autoconf problem on MacOS X"
• Previous message: Adam Fedor: "Non manhattan geometry behavior"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]