|
|
Magic Mailing List |
|
From: R. Timothy Edwards (tim AT stravinsky DOT jhuapl.edu) Date: Thu Mar 29 2001 - 15:44:16 EST
And now, the moment you've all been waiting for
(drum roll, please. . .)
Non-manhattan geometry has been implemented in basic form. This includes
the following:
1) Two new commands exist for manipulating non-manhattan
geometry, "split" and "spliterase". These commands work
basically like "paint" and "erase".
-- "split" takes two parameters, a direction and a layer.
The direction is "nw", "sw", "ne", and "se" and declares
which corner of the select rectangle becomes the right-
angle corner of the split tile, painted with "layer".
An optional third parameter declares the type to paint
in the opposite corner.
-- "spliterase" takes one parameter, a direction, declaring
which corner of the select rectangle to erase paint from.
An optional second parameter declares the type of paint
to erase.
2) A method exists for saving split tiles to magic files and reading
them back again. The type 't' for triangle has been added to the
type 'r' for rectangle.
3) A method exists for reading non-manhattan geometry from CIF and
calma files. This method entirely replaces the manhattan
stair-step conversion routine. It is an incredibly complicated
algorithm but will read any polygon thrown at it, no matter how
convoluted.
4) Methods have been added for selecting, moving, copying, and
stretching split tiles.
5) Undo and redo functions work correctly with split tiles.
6) Split tiles flip and rotate correctly in subcells, clip
correctly at window boundaries, and split the tiling planes
correctly when overlapping other geometry, including other
split tiles (this is NOT a trivial process!).
7) Diagonal tiles are correctly implemented in the X11 and OpenGL
interfaces. Currently, the config script does not flag an
error if NONMANHATTAN is defined in conjunction with any other
graphics formats.
Mostly implemented:
8) CIF and Calma write. Everything has been completed except for the
"bloat" function, which only works for simple cases. This is the
next item on my "to-do" list.
Partially implemented:
9) DRC. "Basic" DRC should be fairly easy to implement, where "basic
DRC" means that edge-based rules get interpreted for whichever
type borders the edge of interest in the split tile. Rules will
need to be added which account for width reduction in a split
tile. Hopefully there won't be any major "gotchas" here.
Not yet implemented:
10) Extract (ugh.) I'll think about it when I get to it.
Wish list:
11) I'm thinking about a method which would allow triangular select
boxes, so that non-manhattan geometry can be drawn with mouse
events rather than having to be entered entirely from the
keyboard.
Caveats:
12) Split-tile geometry has its limits. It is always possible to
cut a diagonal at a non-integer lambda point, which causes the
diagonal to shift to the nearest integer position. So far, I
have not found this to be too annoying in practice. The effect
is minimal if only 45-degree geometry is used. I have not yet
found a CIF or calma file that gets altered by the read
process, but I'm sure some exist. Let me know if you find any.
13) Until I finish the CIF bloat function, CIF output can be incorrect
around areas where bloats occur, such as selects around transistors
if the transistors have been made non-manhattan. Other CIF
behavior includes no handling of contacts on split tiles, which
are left empty of contacts.
14) I believe I have implemented everything correctly, but segmentation
faults are always possible. Let me know immediately if you
encounter a crash, preferably with a list of minimum steps necessary
to generate the error.
------------------------------------------------------------------------
Also in this set of corrections:
My last two "enhancements" BOTH contained errors; in my calma read fix,
I missed one change when copying from my working directory to my
distribution directory. My fixes on the macro capabilities were all
screwed up; now I have gone even further in hacking it up. The problem
was that magic supports two input interfaces, one from the calling
terminal and one from the magic window. In X11, the keycodes are all
different from the ASCII values returned by the terminal for the same
keys. What I have done is to put most of the work into the X11Handler
process, letting it receive the keycodes from the X key event, then
attempt to cast the keycode into ASCII where possible. If not possible,
then it returns an integer including bits for all modifier keys in
effect plus the X11 keysym for the key.
------------------------------------------------------------------------
---Tim
|
|
|
|