A long while back, I released a layout organizer library for Flash. The whole project was essentially an experiment-turned-released-code-collection and, as expected, there have been some growing pains going forward. I have been taking the time to rethink portions of the library and try to clean up and extend its functionality. One big push forward was the introduction of 3d layouts — however, it did not quite fit in with the prior structure. Well, I am very close to completing a fairly thorough rewrite of the library, which will be released in a less haphazard way. I have come to depend on this library for almost every project I have taken on — it just takes care of so much for you automatically. Read On…
I have really fallen in love with Processing, but I had been had hit a bit of a plateau in terms of progress in the past month or so. I never really have spent too much time with algorithmic motion/drawing. When I jumped into Flash, I went straight towards the Tween class and never spent much time trying to work in the EnterFrame-loop based motion design. Because of this, learning how to work with Processing’s draw() loop has been a bit foreign and one can only find so many ways to implement sine/cosine motion treatments.
Luckily, I ran across the simply stunning work of Robert Hodgin who just happened to offer up his source code. After looking through one of his projects and banging away at it, I ended up learning a quite a bit on how motion can end up looking more organic and sporadic. This particular project used the noise() method as its basis for motion jittering. I had not even known such a method existed. After hacking up Robert’s source, I came up with some really interesting form experiments using Robert’s general motion concepts.
I have been playing with different layout configurations lately and, after seeing the advantages/disadvantages of Flex layouts, I decided to work on this experiment. Flex layouts are great because they allow easy visual organization of elements in containers. The problem with that is once an element is in a container, it cannot easily and flexibly change its layout position. For instance, a grid cannot really turn into a HBox and definitely cannot turn into more alternative layouts (such as a circular or random layout). I decided to make some Actionscript classes that would virtually mangage layouts – no containers, just managers. Meaning you subscribe an element to a layout (or multiple layouts) and they can be put into their correct layout position (or taken away) since they act independently.
The example above is a simple example of 50 sprites – all subscribed to different layouts. Clicking each layout button applies those elements to that particular layout. That layout can be changed, which in turn changes the elements subscribed to it. Those elements can also be broken down into sub layout organizers – allowing for some pretty cool stuff. This method is pretty lightweight as well since there are no actual containers for any of these objects. The objects can be tweened (as per the example above) by defining a tween function or just directly set to their respective positions. In addition, each layout is pretty small – meaning large amounts of layouts can be created with little hit on memory. This still has a while to go, but so far it has allowed me to do some fairly interesting things pretty quickly and reliably.
If you have not been to the Big Spaceship Blog yet, you should. They have all sorts of great tips and thoughts ripe for the taking. Their most recent article is the second post in a series of Flash performance tips. I was aware of a few, but others were completely new to me. Performance optimization may seem like a nerdy thing to some, but the process allow things to be done in Flash that otherwise would be too costly to the average processor or be a memory hog.
One of the pieces I especially enjoyed were links to resources on advanced collision detection. There has been some really good work in this area and I found is really helpful as my experience in that subject is extremely low. Really though, all the tips are very helpful and any Actionscripter should take a few minutes out of the day to read this article.
I have found quite a few people run into this problem from time to time and there’s actually quite an easy solution to take care of such an issue:
Essentially, Flash will think that the file is a different URL each time it loads the file and the psuedo parameter (‘?+Math.random()’) will be ignored for the file request. Clever and effective.