Monthly Archive for November, 2006

ffk06: the demo

I announced some weeks ago that I am currently working on a demo. It is done. Finally.

Some demo features:

The demo has been optimized to work in the stand-alone player. So you can download also the lectues of the ffk06 which include the demo.swf and a program that allows you to view the demo in fullscreen!

Lectures online

Lectures are now online. The archive includes the demo plus source-codes of irc client, imageprocessing and some more.

ffk06

The FlashForum Konferenz 2006 is over now and I had a very nice stay in Germany. Thanks again to Sascha Wolter and Marc Thiele for organizing this event.

Persons from other countries might be interested in source-codes as well. I will post the stuff on my blog and inside the Flashforum. Actually first I have to get some sleep now. But it is hard to do so because my nice, new, stylish, uber-fast ALIENWARE notebook just arrived while I was away :o)

The framerate hack

976 fpsDo you worry about your frames-per-second? At least I do. So in general you can do something like this:

[SWF(frameRate='1000',width='800',height='600',backgroundColor='0xCCCCCC')]

This results for me in a constant framerate of 250. It seems to me that there is a limit that Flash puts on the framerate. But 250 is lame to me. Why not go for the 1000? It was a lucky find because I used stage.frameRate = 25; at one point and then wanted to switch back to 1000. But the result was not a constant framerate of 250 but… 976. Seems to me that Flash is not using a limit at this point. Sweet :o)

Update:
You can try using [SWF(frameRate='1000')] and -default-frame-rate 1000 as a compiler argument. Both will result in the same if you do trace( stage.frameRate ). The maximum that you can set is 0xff so Adobe is using a byte here. But inside the Flash player you are allowed to use more than a byte.

Creating an interface based event system

While programming an own event system for a user-interface I came up with nice way that handels all events based on interfaces. The good thing about this is that a window or UI object like a button is only typed as an interface and automatically registered to an event dispatcher.

First of all why not use the built-in event system? The reason to develop an own system was that Flash is very overdosed if you are creating a complex application that uses drag & drop, multiple windows and so on. There are a lot of references that you would have to use, a lot of listeners you would have to add and of course to remove because of the garbage collection.

Why not use the components? Personally I do not like the whole components architecture. They are also not fast enough for my purpose. And I do not want to include a 200kb swc if you think about bandwidth optimization. Maybe there is a way to include not the whole swc but as far as I do not want to use the Flex components anyway here is my solution.

The interface idea:
Every object you want to register to the event dispatcher needs only an interface. So for instance if I create a button I only use
[as]public class Button extends Bitmap implements IClickable[/as]

The button is now automatically registered to the event system. The event system is doing the following (pseudocode):

[code]event dispatcher on click
{

objects = stage.getObjectsUnderPoint( mouse );

loop through objects from top to bottom
{
if ( object is IHitable )
{
if ( object.isHit( mouse ) )
{
if ( object is IClickable )
{
object.onClick();
}

stop loop because there was an intersection
}
}
}
}[/code]

There is one base interface that every interface has to extend because you want to be able to check if there was an intersection or not. This interface is IHitable. Now I am able to do the same for nearly all interfaces. If a window shoule be dragable I just have to create an interface for a dragable window which is handled inside the event dispatcher that is also able to move the window. So it is more than only a event dispatcher but more a UI manager. The window implements only the interface and does not have to care about focus, movement or whatever.

The power and problems of DisplayObject.getObjectsUnderPoint():
The function DisplayObject.getObjectsUnderPoint() returns an array of objects that are currently under a given point. If you have a button on a window it would return something like [ Window, Button ]. Now the problem is that your button could be a Sprite and you added some Bitmap object onto it (because you can not use the handcursor with a Bitmap). So the function returns [ Window, Bitmap ] in this case but you implemented the interface for the button not for the Bitmap. The way to get arround this problem is walking the displaylist upwards until you hit the interface you are searching for.

The whole system seems to work pretty well and is also very fast. The idea of using interfaces to regiser your class to an event system is nice because you do not have to care about a lot of stuff. Registering your object to the event dispatcher is done by creating it and removing it from the dispatcher is done by removing it.