MAGIC Magic Mailing List
 
 
From: Jeff W. Sondeen (sondeen AT rcf-fs DOT usc.edu)
Date: Thu Oct 26 2000 - 20:43:23 EDT

  • Next message: Rajit Manohar: "Re: Non-manhattan geometry in magic" 

    but those 'diagonal' tiles will surely complicate traversing them,
since you have to consider both x and y all the time (ie. given a
certain xcoordinate, the code can't just look nearby for any other
tiles, but must consider far smaller x-coord 'diagonal' tiles whose
positive slope may be enough to intersect, as well as far larger
x-coord 'diagonal' tiles whose negative slope may intersect, etc).

if you only want to allow 45 degrees (as opposed to any angle), why
not maintain another set of (orthogonal) tiles in "rotated space" (ie.
any tiles here appear on the screen etc at 45 degrees) and then you
would "switch" your drawing "modes" between orthog and rotated, so all
the usual magic commands work in each mode.  there would be plenty of
kludging tho to merge the results of both "sets" of planes for drc and
layout (cif) generation, of course, as for the diagonal tiles (and
some of the semantics for layer bloats are hard enough as it is).

perhaps you could forget (corner-stitch) tiling of this "rotated"
space altogether and just store "paint" as any-angle objects that are
linearly searched. going full circle, maybe the 'diagonal' tiles could
occupy a separate set of planes, and so not affect the 'orthog' tiles.

/jeff

R. Timothy Edwards writes:
 > Dear James,
 >    Both Philippe Pouliquen and I independently came up with roughly the
 > same idea to implement (fairly easily, we think) non-manhattan geometry
 > into magic.  The idea consists of "splitting" one of magic's rectangular
 > tiles diagonally, with the tile type of each of the two split sections
 > being determined by the surrounding layers.  DRC for such a case should
 > require barely more effort than for regular manhattan geometry, and the
 > resulting magic file should be able to exactly match any non-manhattan
 > geometry in which the corners of the non-manhattan polygons land on the
 > lambda grid.  As far as I've noticed, this takes care of over 99% of
 > the non-manhattan geometery that exists, and the rest can be approximated
 > much more closely than the current stair-stepping algorithm, perhaps
 > within the limit of DRC rules.
 >    But. . . we haven't implemented it yet.  This is a high priority for
 > me, so if enough people are demanding it, I'll work on it harder.
 > 
 > 						Regards,
 > 						Tim

    •  
     
    Questions? Contact Rajit Manohar     		cornell logo