Bermuda Triangle 'Pyramid Menu' test version 0.0.2
LATE BREAKING NEWS:
A second version of the 'Pyramid Menu' test version is available for any
of you who like to play around with it. Go here.
Ok, so it's not much faster, but has a bit different look and finally has at
least some support for mouse-clicks :-)
This is the alpha test version of the menu system for the Bermuda
Triangle Flash site. As you can see the menu is a bit slow, so I fear I need to
spend quite some time improving the graphics and ActionScript as each eats about
50% of the total time spent in this Flash animation.
All right, the pyramid structure is large (7 levels of pyramids, good for
= 113 (n=7) pyramid elements and 'texts on the radar' stored in an array, Of
course, quite a few are invisible, but they all do exist.
Caveat Emptor
The caveats I ran into while creating this menu:
swapDepths() is nice, but if you want attachMovie()d MCs to overlay MCs
already in your FLA, you'd better make sure they're attached to an empty MC
in a higher layer in the FLA. Yes, I know it works if you don't do this, but
things don't work out, if you start to swapDepths() that existing MC too. No
matter what depth you assign your MC (the one that was in the FLA) when
applying swapDepths(), it'll end up overlaying the attachMovie()d MCs if
those were attached to an empty MC which was on a lower layer originally.
More swapDepths() caveats: when you attachMovie() two sets of MCs to the
same empty MC and still think one set can overlay an existing MC while the
others don't, you're in for some disappointment. I resolved this by having
two empty MCs in the FLA, one on a layer below the 'radar screen' MC and one
in a layer over it: the pyramid elements are attached to the empty MC below
the 'radar screen' while the 'radar texts' are attached to the empty MC over
the 'radar screen'. The 'radar screen' is then swapDepths()ed to a level in
between. But swapDepths()ing it to level 1 works too, while that level is
under the pyramid elements. Apparently somehow layers in the FLA influence
the layering once swapDepths() and attachMovie() depths have been applied to
all MCs on the layers.
The standard Array.Sort() is slow as a snail. This is no new knowledge (Branden
Hall of Flashcoders already knew this a along time) but I've been
experimenting with various Z-order sorting algorithms (as I need Z ordering
for my pyramid elements) and lo and behold: Insertion Sort is the fastest
beast, though Three Way Partitioning QuickSort (including the extra
'duplicate key' improvement) from Sedgewick comes bloody close. For those of
you who are interested, the various sorting algorithms (AS functions) are
included in the downloadable AS source code for this menu.
with(...) is nice too. But you cannot 'create' object attributes inside
'with': if your object 'Obj' should have an extra attrib 'attr' added, you
still have to write
Obj.attr = ...;
outside the with() statement before you can access the new attribute
using
with(Obj) { trace(attr); }
I.e. with(...) allows you to access existing object attributes and
functions. This knowledge could've been derived from the MM manual, but the
'with(...)' was a bit vague to me. It read like a UNIX man page: once you know
how it works, you can grok the man page too.
MAX + Illustrate are a fine team, but sometimes I import rendered SWFs
into the Flash development environment (import into FLA) loosing some
surfaces. This appears to happen only when some other tiny (invisible)
surface is perpendicular to the face just lost in the import void. I can't
yet find why Flash errs here during import, as the SWF produced by
Illustrate is flawless itself. This item needs some more research, I fear,
as quite a few SWFs I created suffer from this 'lossy import' behaviour of
Flash. Hmm, grab the OpenSWF SDK and debug the SWF layout? Might be feasible...
(No, I can't resolve this using loadMovie() - I often need to 'enhance'
those SWFs with AS.)
Yes, there's a speed tweak in there: I rendered one pyramid element (360
frames for 360 degrees rotation). I rendered the pyramid element as it
would appear on level 2 of the pyramid to reduce the 'saw tooth' effect at
the sides of the pyramid when using a large number of levels. The real-tie
projection is truly perspective, yet I do not render each triangle of the
menu in real-time: the 'anchor points' of the pyramid elements are
rendered in real-time, while the element is gotoAndStop()-jumped to the
proper rotation in real-time. So purists may argue the menu is not 100%
real-time rendered. That would simply be too time-consuming. And so what
if it's not 100% rela-time rendered. It works and it looks great. That's
what counts. I could render the pyramid element for each level, but that
would increase the file size of the published SWF dramatically. The
current SWF is twice the size it could be as two different styles of
pyramid element are included in the SWF, while only one style is actually
shown.
= 113 (n=7) pyramid elements and 'texts on the radar' stored in an array, Of
course, quite a few are invisible, but they all do exist.