Archive for the ‘Actionscript’ Category

AS3 MOUSE_LEAVE no longer reliable

Wednesday, December 8th, 2010

Looks like certain browsers have updated mouse events so that MOUSE_MOVE works outside of the bounds of an swf on a page. This is really nice, but other mouse events do not seem to function properly. MOUSE_UP for example does not seem to get called in safari, and only gets called in chrome after an additional movement of the mouse. This becomes a kind of sticky situation for something like a scrollbar or object that you are using MOUSE_DOWN to gain focus and then looking at the stage to stop the mouse updates based on MOUSE_UP. The solution used to be to resign focus on MOUSE_LEAVE, but this does not appear to be firing. The only 2 things I could think of to do in these situations were to use javascript mouse events (which may not be a possibility based on the project) or 2 to force resignation of the mouse when leaving the stage.

In the mouse move handler I put:
if(mouseX > stage.stageWidth || mouseX < 0 || mouseY > stage.stageHeight || mouseY < 0){
// stop mouse move action

It does work, but it seems like a crappy approach. I will need to look and see if there's any documentation on this *feature* to see if there's another alternate approach to get a global mouse up event when the mouse is outside of the swf.

Texture Atlas Creator

Monday, November 1st, 2010

Daniel over at Sparrow wrote up an article on how to use the flash based texture atlas creator I built. I figured I would at least put a public link in here so that folks can find it. Here’s the link

Flash frameworks

Thursday, April 9th, 2009

Been spending some time really digging into some of the popular frameworks and libraries lately. Seems like a lot of companies are putting out their own MVC flavor frameworks. Seems like there are a couple of winners in this arena: Cairngorm and PureMVC. Looking through the docs on these I think I would personally pick pureMVC for projects just because of the fact that they have it available in other languages. Both of them look really great for projects that require teams of developers to focus on building out an application with the objects so loosely coupled that it won’t barf when you try to add in some nice features later. That said a lot of projects make frameworks like these counter intuitive. Design oriented website projects in particular.
Another big framework right now is GAIA. This one addresses many of the issues of developing a site. It handles deep linking, navigation and preloading of assets. If you have a website that is not using a lot of the same functionality between pages this thing is really geared to rip out projects fast. Event hijacking lets you do the things you need to do in between an event sequence. It is something I would love to see more of in animation driven applications. GAIA is dependent on the project. If you are walking outside the “flash way” of doing things you are doing it can start getting in your way. For instance on small projects where a lot of external assets are not needed it becomes overkill.

Event Mediator

Friday, March 6th, 2009

Most people are getting pretty hyped on design patterns and frameworks these days. Most of what I have seen floating around though is the use of MVC. MVC is a really nice pattern, and I wish I had known about it when I was doing a lot of php work as it would have saved me at least 100 huge headaches. When I looked at rails I was really impressed with how easy it made it to change the application view and data as 2 very isolated entities. Now there are tons of frameworks available for flash that use this pattern. PureMVC and Cairngorm are both really nice options that encourage loose coupling. If your project is big, or has multiple developers involved than using one of these frameworks is going to be the way to go. Your app will be scalable and multiple people can pick out their own parts to work on without messing with the others. This is flash though, and a lot of times you are not building something this big.

I first started trying to figure out how to decouple objects when I first started using AS3. Immediately I was getting bugs and compiler errors because I was trying to remove objects that had a reference in some other object that needed info and not knowing to clean it up. I also found the event model started to look like the nasty parent child rats nest that I have always tried to avoid. I started by setting up a static member in my application that was an event dispatcher, passing notifications and adding listeners to it. it worked ok, but one thing that I immediately noticed was the fact that I was not getting back any info about the object that sent the event. was coming from the event dispatcher. In order to get info about the objects in question I needed to create custom events that had a variable that was required to be set in order to see any info about the original object target. I generally needed to make an extra function to handle the original event and pass it to the dispatcher which is kinda a hassle. Thirdly as my application grew, the objects started to have a lot of dependencies as they were all referencing the main app. This was fine for working within a single project, but if I wanted to shift a lot of the classes out for usage in a different environment I was essentially screwed. I also was right back where I started with dependencies.

The next thing I tried was getting in tune with event bubbling. Event bubbling is pretty cool and achieved a lot of the effect I was looking for, but I did start to notice an issue with it that became a gotcha pretty quickly. The main thing with event bubbling is that it works off the display list. This seems like a pretty necessary feature to keep it under control, but assuming that any object that is interested is in the same display tree can feel pretty limiting pretty quick. I was finding myself making helper classes sprites just so that I could get them to receive events and be tied to the stage. If they were in a different hierarchy they were useless. Frameworks like papervision3D or APE also cannot take advantage of this feature.

I then started reading about design patterns in a little more depth. Went and got the book by the gang of 4 and started going through it. The patterns that immediatly stuck out to me were observer and mediator. Observer seemed to be tuned a little more towards what flash is already doing with events, but mediator seemed like exactly what I was trying to do. The problem was that the smalltalk examples didn’t exactly translate to what I was looking for so I started going to forums for a little advice.

The only real advice from the forums that I got is that asking about design patterns is the equivalent of starting a flame war. Ask what you think is a simple question and you will immediately see 2-10 other people get into a heated discussion about “proper” implementation. Some of the insults I have not seen since looking at the World of Warcraft forums. Looking at examples of people using patterns I started to realize that the implementation seemed relevant more to the language. It also seemed to me that perhaps you could use a pattern to describe what you were trying to do.

I built out a few various event mediators, and finally came up with one that I am happy with. It takes care of a lot of the things I need in smaller projects that change a lot. It is not what a typical mediator looks like. Most of the examples I found contained a lot more knowledge of the objects associated with them. This does not assume any of that knowledge. You can just add and remove objects to/from it.

1. Any remotely loaded swf files can communicate with the host application by going through the mediator. This removes dependence on classes and and files that you do not need in a loaded module. If you redo functionality in the main app you do not need to recompile any of the loaded modules. It also removes the need to tie events to a module on load that may or may not actually be relevant.
2. Project structure can change rapidly without having too many adverse effects, and classes can be reused a lot more easily since they are not tied to each other. This really helps at an ad agency where things can change on you really quickly.

1. If your app is going to get big this will start to become a burden. It is designed for small nimble things where a lot of stuff is happening visually. Something that uses a lot of data would be better handled with something like PureMVC.
2. You have to be pretty careful about event names. Since the event types are just strings, naming something the same in a different event will cause conflicts.
3. Using with common events such as mouse events is a good way to spell trouble. This means you really need to create a specific event to send out to the mediator.

You can grab the file here:


Tuesday, January 20th, 2009

Just got CS4 Installed at work and started playing around with it a good deal. They really went to town with the animation. The ability to really tweak the easing and parameters of each object makes it so much more flexible than older versions. It surprises me that it took them 7 versions to add something new here as it is an “animation” program by default, but the new changes are welcome and will be able to generate nice results without having to rely so much on scripting.
The project pane has been updated to make management of a project much more detailed but alas the Actionscript editor does not seem to have moved much further forward from what I can tell. There is nothing that helps along with using big 3rd party packages code hinting or otherwise. This keeps other editors (such as Flex) the choice for editing Actionscript. One thing that does seem nice though is that Flash will now use the Flex sdk some so that you can finally use features such as [Embed]. This for me may make projects where I am working with other people more portable between the 2 editors. I will have to run some tests to see how well this works.
All in all it really looks like Adobe has really spiced up Flash for the design side this time around. I am looking forward to digging deeper.