Category: Flash

  • Huge MC’s vs. Dynamically Built

    2 times in my life have I run into a conund…er, no that word sux. *ahem* …have I run into a challenge of whether to build a movie large movie clip or dynamically build it, showing only pieces at a time.

    The first time was dealing with a timeline at work displaying a 24 hour period which fit on a grid. It was scalable, and as such, if you “zoomed” in your view of an hour, it could easily be 4000px + wide. Since it was dynamically drawn, this was cake to build, but we were unsure of the best way to display. Flash still “deals” with things not being displayed or offscreen with the exception of _visible. If you make something _visible = false, it helps a little, but you still have a lot more overhead when something is “there” and you wish to make a change, either moving something or modifying data. On the other hand, constantly rebuilding pieces of a movie clip constantly via minimal user interaction is resource costly as well.

    It depends though; there’s a sweetspot as I’ve found in my tests throughout the last year from dynamic graphs to tile-based games. So, to prevent you from spending the time that I did, here are some results followed by some conclusions (hypothesis) on the best ways to get the most of out of your dynamic Flash movie clips’ performance.

    <b>Results</b>
    – dynamically drawing strokes vs a movie clip were significantly slower; even just one movie clip with a ton of stokes was significantly slower than one movie clip holding hundreds of instances. Additionally, building a “stroke” via a fill, helped a lot, but the optimal perceived performance by both my manager and I were a fill within a movie clip, which you then attach dyanically as needed.
    – with the above, you lose resolution, even if your fills are on a positive (integer) pixel (x = 5 vs x = 5.68). Strokes are just drawing better regardless of their position while fills, if not exactly on a pixel and not exactly a certain pixel width will anti-alias themselves to the next pixel to emulate half-a-pixel, which looks blurry and non-exact.
    – there’s always a number of movie clips on stage where things start to decline. By this, if your using many of the same components at once, things can potentially start to decline in performance at a certain number, and then quickly go downhill. This number – 1 is what I call the “sweetspot”. It’s where you get the best performance with the most instances. This is different for form type apps, or where you have many different types of movie clips/components on stage, and is more applicable to games and/or animation/transition intensive apps with non-stagnant interactivity.

    <b>Hypothesis'</b>
    – Fills are faster than strokes. Strokes display correctly more often than not while on a non-integer pixel coordinate while fills do not. If you have a choice of using fills or strokes, then use fills.
    – If you can consolidate an interface element into a movie clip, then put it in one, then attach many instances of it dynamically rather than dynamically draw it. This is even faster than just drawing fills.
    – If your doing simple benchmark testing on your own and experience a decline in performance, then mark the number of instances in which performance isn’t adversly unusable. If the maximum instances you’ll ever have is less or equal to that number, then your app can benefit from possibly having them already on the stage to prevent the needless attaching/removing of the movie clips.
    – However, if the maximum number of instances is equal to and beyond what you’ll actually have in your app, then a progressive building/destroying mechnism is better because you can display an infinite number of instances and still have the same processor usage. At this point, it’s all about optimizing that solution.

    A simple example of the former is the Accordion component in Flash Pro; it puts your contents on the pane, and keeps it there, regardless of how many panes you have.

    The List however, draws the same amount movie clips regardless of the amount of data inputted, and simply cycles through the data, moving just it as necessary.

    Both have pros and cons, but hopefully the loose guidelines above can help you save time in choosing an archetecture path.

  • Compile Whore: FLA on a Tab Corner

    Dude, for real, that’s all a FLA is now. Got deep into Flash last night redoing some of my tile-based game tests. If your designing strictly an app, or a seriously dynamic one, all I have been using the FLA for is compiling, or putting a single breakpoint to start the debugging trail. I pretty much toggle to my class files, and then just hit the FLA to run it. Granted, for the smaller stuff, you really don’t have much on _root, but for bigger projects you would probably use _root extensively; SOMEONE has to start it off, and for me, _root’s usually the controller, even if just attaching a master component.

    However, some things that need improvments:
    – because I’m coding in the IDE, I should be able to put a breakpoint in my AS file; doesn’t have to be saved, but the IDE should know this (worked with Director’s external ls files)
    – having to toggle back to the FLA to compile blows; anyone know a keyboard shortcut mod?
    – rebuilding classes over and over again blows; when is someone gonna make an XUL window using JSAPI that mirrors VB 6’s Class builder?

    I guess for that last one, it’s gonna be me if no one else does, but I got too much going on… come on… someone?

  • I Miss My PuppetSprite & Show Peter Sydney @ MXDU

    Dude, I swear, I keep hearing dynamic animation through code like DynTween, and some of Flash 7’s stuff calling my name, but always cross the line somewhere. The current interface I’m implementing at work now I could definately see parts of it greatly benefitting from such a system, but as a whole, I personally think it wouldn’t work. There are just some complexities that wouldn’t be realistic to code, even with the heartache I had yesterday.

    Interface is made up of 2 parts, and for some reason, the 2nd part wasn’t moving out (think assembly interface). I traced the Output window the _currentframe, and yes it was on the right frame, but it seemed to be ignoring the timeline. I tried updateAfterEvent, and even toggling the _visible property of the movie clip, all to no avail; the freak wouldn’t move. Got <a href=”http://www.erikbianchi.com/”>Erik</a> involved, and he reminded me that setting some properties of tweened movie clip’s will stop them dead in their tracks. “Aw shhhhiiiiiii…..” I replied. Looking through my code, commenting out some of the _alpha settings I was making, and poof, it worked again. SO, I just gave the movie clip’s I was setting 2 states internally using frame 1 and frame 2, rather than affecting it’s _alpha. Granted, I could of wrapped the mc in another movie clip wrapper, but it was already deep enough, and using 2 states works great; very little code had to be added to switch it; just changed _alpha = 50 to gotoAndStop(“disabled”).

    Still, it’d be nice in the Flash 8 player if we had a command similiar to the puppetSprite command in Director. You know they are gonna have to update the internals of the Flash 8 Player anyway because all these frikin’ programmers are gonna want their classes to really compile to classes and their private variables to really work… of course, what I’m asking is a screen rendering thing be modified, so that’s not really fair, but hey… yeah, that’s it, just hey.

    *ahem*

    Basically, puppetSprite said, “Hey Director, Lingo is controlling this now, so ignore whatever the timeline says.” You can toggle this. In Flash, many people have seen what happens when you drag a movie clip to a positive depth, only to return the keyframe, and the sprite is duplicated or other “weird” things happen. Regardless, I know a lot of developers are probably using a lot of their own animation engines for simple transitions, etc., but for the custom interfaces I work with, I honestly don’t think it’s realistic in the long run, and I KNOW I’m not the only one doing this kind of work. I’m definately not the first hybrid to blend code and complex interfaces… that’s what Flash is all about.

    At any rate, <a href=”http://www.macromedia.com/support/email/wishform/”>wish-list</a> it with me!

    Also, talked to <a href=”http://www.peterjoel.com/blog/”>Peter Joel</a> yesterday. He wanted to know what is there to do in Sydney and see if we could hook up during the <a href=”http://www.mxdu.com/”>MXDU 2004 conference</a>. Like <a href=”http://www.darronschall.com/”>Darron</a>, it broke my heart but I had to let him know I couldn’t go because of no vacation time left and wanting to save dough since I’m buying a new house. It’d be nice to hang with fellow Flash peeps that I’ve never met personally but known for awhile online, especially in Sydney. Anyway, he was a little disappointed because I wouldn’t be able to entertain him for a week after the conference (I was more than happy to do so, that country’s tons of fun!), so since I can’t, I recommended tons of things. Don’t know how useful they were, but mainly:
    – get with the peeps at Daemon; Geof, his wife, and crew all are cool and know of fun things to do. Or, I guess you could just talk shop with Andrew for hours…
    – contact a local travel agent. In my limited experience, Australia was a country that was cool with non-Bush loving tourists, and I’m sure the UK has the same slant in plenty of travel packages
    – Get with Steve, Brian, (peeps that I hung with when I was there), or Scott Barnes (since he works for the government there).

    Regardless, if your at the conference, show my boy around town (cept for Red Cross).

  • EULA BS: There has GOT to be a comprimise…

    Reading Grant’s blog about the EULA stuff (<a href=”http://www.gskinner.com/blog/archives/000034.html”>original</a>, <a href=”http://www.gskinner.com/blog/archives/000036.html”>new findings</a>). Man, what a crock. Most of my clients, however, have custom written solutions. The scope of the projects are changing added with what I can now do in 7, resulting in more and more hybrid solutions because of time constraints; custom solutions take time, where as hybrid ones (using some Macromedia framework combined with my own components) are very cost efficient. I’ll admit there are some projects that where I’ve used existing components in MX, but the source code was included in those components, in the new ones, it’s against the law if I have modified them in anyway, which I do sometimes do to meet project requirements.

    I’m not sure how much of this applies to the whole “dual” versions of Flash. Like, if you don’t own Flash Pro, you can still modify the base classes to get what you want to happen… I guess, not sure how it works, but sounds like sound reasoning on a way to protect the Flash Pro assets Flash normal users aren’t supposed to have.

    Not having the ability to give out projects for those clients that require the “source” will be a problem for me, I’m sure in the future. Currently, most don’t know what the “source” really is anyway cause they don’t understand it, and if they ask can they modify the Accordion pane, and I say no because that’s the way Macromedia made it, but I can “suggest” how they themselves can modify it because if I do it myself and then give that modified code to them, it violates the EULA agreement.

    Uh…no. Good to know, though, that Grant and Nigel are chatting about it. When the big, mature boys get together, I’m sure a comprimise will emerge.